0.5-bob: Brauzer qanday ishlaydi (rendering va JavaScript engine)

0-QISM — TAYYORGARLIK · 5-mavzu

1. Kirish va motivatsiya

Oldingi bobda 0.4-bob brauzer serverdan HTML, CSS va JS fayllarini olib keldi. Lekin bu fayllar — shunchaki matn (0.1: matn ham baytlar). Siz ekranda ko'rayotgan chiroyli tugmalar, rasmlar, animatsiyalar — bu matn qandaydir rangli piksellarga aylangan. Mana shu "matn piksel" sehri brauzerning ichida sodir bo'ladi.

Frontend dasturchi sifatida bu jarayonni bilish — shunchaki "qiziqarli" emas, zarur:

• Tezlik (performance). Saytni tez qilish — bu, aslida, brauzerning rendering jarayonini tushunib, unga xalaqit bermaslik. "Nega saytim sekin yuklanadi?" degan savolning javobi shu bobda.
• Uncaught ReferenceError: ... is not defined kabi xatolar — ko'pincha JS DOM tayyor bo'lmasdan ishga tushganidan. Buni faqat rendering tartibini bilgan odam tushunadi.
• React, Next.js (11, 13-QISM) — bularning hammasi brauzer DOM va rendering ustiga qurilgan. "Virtual DOM nega kerak?", "re-render nima?" — javobi shu yerda.
• JavaScript nega bir thread'li (0.1, 0.2) va event loop nima — bu bobda poydevorini qo'yamiz (5.1-bobda to'liq ochamiz).

Bu bob — frontend (11-QISM) va performance optimizatsiya 11.11-bob uchun majburiy poydevor.

2. Nazariya — chuqur tushuntirish

2.1. Brauzerning ichki qismlari

Brauzer — bitta dastur emas, balki bir nechta moduldan iborat tizim:

   ┌──────────────────────────────────────────┐
   │  Foydalanuvchi interfeysi (UI)             │  manzil paneli, tugmalar
   ├──────────────────────────────────────────┤
   │  Brauzer dvigateli (browser engine)        │  UI va rendering'ni bog'laydi
   ├──────────────────────────────────────────┤
   │  RENDERING engine (Blink/WebKit/Gecko)     │  HTML/CSS'ni pikselga 2.3-bob
   │     ┌──────────────────────────────────┐  │
   │     │  JS ENGINE (V8/SpiderMonkey)       │  │  JS kodni bajaradi 2.4-bob
   │     └──────────────────────────────────┘  │
   ├──────────────────────────────────────────┤
   │  Tarmoq (networking) │ Ma'lumot saqlash    │  so'rovlar 0.4-bob │ localStorage
   └──────────────────────────────────────────┘

Asosiy brauzerlar va ularning dvigatellari:

Muhim bog'lanish: Node.js ham aynan V8 (Chrome'ning JS engine'i) ustiga qurilgan (5.1-bob). Ya'ni brauzerda JS qanday bajarilsa, Node'da ham xuddi shu dvigatel ishlaydi — faqat atrof-muhit (DOM yo'q, fayl tizimi bor) farq qiladi.

2.2. JS engine ichida: kod qanday bajariladi (V8 misolida)

JavaScript — "interpretatsiya qilinadigan til" deyishadi, lekin haqiqat murakkabroq va qiziqroq. V8 (v8.dev rasmiy hujjatlariga ko'ra) JS kodni bir necha bosqichda qayta ishlaydi:

  Sizning JS kodingiz (matn)
        │
        ▼
  1. PARSER    AST (Abstract Syntax Tree)
        │        kodning "grammatik daraxti"
        ▼
  2. IGNITION (interpretator)    bytecode
        │   bytecode'ni darrov bajaradi (tez ishga tushadi)
        │   + ishlash paytida MA'LUMOT yig'adi (qaysi kod ko'p ishlaydi?)
        ▼
  3. TURBOFAN (JIT compiler)    optimallashtirilgan mashina kodi
            ko'p ishlaydigan ("hot") kodni juda tez mashina kodiga aylantiradi

Asosiy g'oyalar:

• AST (Abstract Syntax Tree) — parser kodingizni daraxtsimon tuzilmaga aylantiradi (masalan, let x = 5 "o'zgaruvchi e'loni" tuguni).
• Ignition (interpretator) — AST'ni bytecodega aylantirib, darrov bajaradi. Bu — tez ishga tushish uchun.
• JIT (Just-In-Time) compilation — bu eng aqlli qism. Ignition ishlayotganda qaysi kod ko'p marta chaqirilyaptini kuzatadi ("hot path"). Shu kodni TurboFan olib, juda tez mashina kodiga (0.1: CPU tushunadigan til) kompilyatsiya qiladi.
• Zamonaviy V8 ko'p bosqichli (tiered): Sparkplug (tez baseline) Maglev (o'rta) TurboFan (eng tez, eng "hot" kod uchun).

O'xshatish: yangi xizmatchini ishga oldingiz. Avval u har buyurtmani qog'ozga qarab (interpretator — sekin, lekin darrov boshlaydi) bajaradi. Vaqt o'tib, eng ko'p so'raladigan taomlarni yodlab oladi va ularni o'ylamasdan, tezda tayyorlaydi (JIT — optimallashtirilgan). Mana shuning uchun JavaScript "sekin til" emas — V8 uni juda jiddiy optimallashtiradi.

2.3. Critical Rendering Path — HTML'dan pikselgacha

Bu — bobning yuragi. Brauzer HTML/CSS/JS'ni ekrandagi piksellarga aylantirish bosqichlari (web.dev "Critical Rendering Path" hujjatiga ko'ra):

  HTML ──parse──▶ DOM ─┐
                        ├──▶ RENDER TREE ──▶ LAYOUT ──▶ PAINT ──▶ COMPOSITE
  CSS  ──parse──▶ CSSOM ┘    (ko'rinadigan)  (o'lcham/    (piksel    (qatlamlarni
                              elementlar)     joylashuv)   rang)      birlashtirish)

1) DOM (Document Object Model) qurish. Brauzer HTML matnini o'qib, uni tugunlar daraxtiga aylantiradi. <html> ichida <body>, uning ichida <div>... — bu ona–bola munosabatli daraxt:

  document
    └── html
         ├── head
         │    └── title
         └── body
              ├── h1
              └── p

2) CSSOM (CSS Object Model) qurish. Xuddi shunday, brauzer barcha CSS'ni o'qib, uslublar daraxtini quradi (qaysi elementga qanday rang, o'lcham).

CSS — "render-blocking". Brauzer butun CSS kelib, qayta ishlanguncha sahifani chiza olmaydi (web.dev). Sababi: CSS qoidalari bir-birini qoplaydi (override), shuning uchun yakuniy ko'rinishni bilish uchun hamma CSS kerak. Mana shuning uchun katta CSS — sahifani sekinlashtiradi.

3) Render Tree. Brauzer DOM va CSSOM'ni birlashtiradi — faqat ko'rinadigan elementlar va ularning uslublari (masalan display: none bo'lgan element render tree'ga kirmaydi).

4) Layout (reflow). Brauzer har element qayerda va qanday o'lchamda turishini hisoblaydi (piksel aniqligida).

5) Paint. Brauzer haqiqiy piksellarni chizadi — rang, matn, soya, rasm.

6) Composite. Agar elementlar bir-biri ustida bo'lsa (qatlamlar — masalan modal oyna), ularni to'g'ri tartibda birlashtiradi.

2.4. JS — rendering'ni "bloklaydi"

JavaScript DOM va CSSOM'ni o'zgartira oladi (2.16-bob DOM). Shuning uchun brauzer <script> ni uchratganda, odatda DOM qurishni to'xtatib, avval JS'ni bajaradi (chunki JS DOM'ni o'zgartirib yuborishi mumkin):

  HTML parse... ──▶ <script> uchradi ──▶  DOM TO'XTAYDI
                                          │  (JS yuklanadi va bajariladi)
                                          ▼
                                       ▶ DOM davom etadi

Shuning uchun <script> ni odatda </body> dan oldin qo'yadilar yoki defer/async ishlatadilar (4-bo'limda). Aks holda — sahifa "oq ekran" bo'lib turib qoladi.

2.5. JS runtime: call stack, bir thread va event loop (kirish)

JavaScript — bitta thread'li (0.1, 0.2: single-threaded). Ya'ni bir vaqtda faqat bitta ish bajaradi. Buning uchun ikki qism muhim:

• Call Stack (chaqiruvlar stegi) — hozir bajarilayotgan funksiyalar tartibi. Funksiya chaqirilsa — stekka qo'shiladi, tugasa — olinadi (0.1: Maximum call stack shundan).
• Heap (uyum) — obyektlar, massivlar saqlanadigan xotira (0.1: RAM).

Lekin bir thread bilan qanday qilib bir vaqtda so'rov yuborib, animatsiya ko'rsatib, foydalanuvchini tinglaydi? Javob — event loop va Web APIs:

  ┌─────────────┐         ┌──────────────────┐
  │  Call Stack  │         │  Web APIs (brauzer)│
  │ (sinxron kod)│ ──────▶ │ setTimeout, fetch, │
  └─────────────┘         │ DOM events...      │
        ▲                 └─────────┬─────────┘
        │                            │ (tayyor bo'lganda)
        │   ┌──────────────────┐     ▼
        └───│   EVENT LOOP      │◀── Callback Queue
            │ stack bo'shasa,   │    (kutib turgan ishlar)
            │ navbatdan oladi   │
            └──────────────────┘

Asosiy g'oya: og'ir/kutishli ishlar (so'rov, taymer) brauzerga (yoki Node'da OS'ga) topshiriladi; ular tayyor bo'lganda natija navbatga qo'yiladi; event loop call stack bo'shashini kutib, navbatdan ishlarni oladi. (0.1-dagi "bitta oshpaz ko'p taomni navbat bilan" — aynan shu.) Buni 5.1-bobda Node kontekstida to'liq, chuqur ochamiz. Hozircha shuni eslab qoling: JS bloklanmasligi kerak — agar bitta funksiya uzoq ishlasa, butun sahifa qotib qoladi.

Bir nozik nuqta: ikki xil navbat. Brauzerda aslida bitta emas, ikki xil navbat bor:

• Task queue (makrotask) — setTimeout, setInterval, foydalanuvchi hodisalari (click) shu yerga tushadi.
• Microtask queue — Promise.then(...), queueMicrotask, async/await natijalari shu yerga tushadi.

Qoidasi: har bir makrotask tugagach, event loop butun microtask navbatini bo'shatadi, keyingina navbatdagi makrotaskka o'tadi. Shuning uchun Promise.then doimo setTimeout(..., 0) dan oldin ishlaydi (ikkalasi bir vaqtda navbatga tushsa ham). Buni amalda 5.1-bobda sinab ko'ramiz; hozircha "Promise microtask tezroq, setTimeout makrotask" degan tartibni eslab qoling.

2.6. Reflow va repaint — performance kaliti

JS bilan sahifani o'zgartirganingizda (2.16 DOM), brauzer ba'zan qaytadan ishlashi kerak:

• Reflow (layout qayta hisoblash) — element o'lchami/joylashuvi o'zgarsa (kenglik, balandlik, joylanish). Qimmat — chunki boshqa elementlarga ham ta'sir qiladi (2.3-dagi Layout bosqichi qaytadan).
• Repaint (qayta chizish) — faqat ko'rinish o'zgarsa (rang, soya), o'lcham emas. Arzonroq.

Eng arzon — transform va opacity orqali animatsiya (ular faqat Composite bosqichiga tegadi, reflow keltirmaydi). Mana shuning uchun professional animatsiyalar transform bilan qilinadi (11.16-bob).

Nega aynan transform/opacity? — GPU qatlami (hardware acceleration). Brauzer ba'zi elementlarni alohida qatlam (compositor layer) ga ajratib, ularni markaziy protsessor (CPU) emas, grafik protsessor (GPU) orqali qayta ishlaydi — bu "hardware acceleration" deyiladi. transform va opacity aynan shu GPU qatlamida, Layout va Paint bosqichlarini chetlab o'tib, faqat Composite bosqichida hisoblanadi. Shuning uchun ular juda silliq (odatda 60 kadr/sek). Aksincha, top/left/width o'zgartirilsa — Layout qaytadan ishlaydi, sahifa "uziladi". DevTools'ning Layers paneli qaysi element alohida qatlamda ekanini ko'rsatadi. (Eslatma: keraksiz joyda will-change yoki ko'p qatlam yaratish xotirani yeydi — me'yorida ishlatish kerak.)

Amaliy saboq: tsikl ichida DOM'ni 1000 marta o'zgartirish — 1000 marta reflow — sahifani qotiradi. To'g'ri yo'l: o'zgarishlarni yig'ib, bir marta qo'llash (4 va 5-bo'lim).

3. Sintaksis va asosiy tushunchalar

Bu bobda "sintaksis" — DevTools panellari va rendering bosqichlari nomlari:

Brauzer DevTools (F12) — eng muhim panellar:

Rendering bosqichlari (yodlash):

DOM + CSSOM  Render Tree  Layout  Paint  Composite
 (tuzilma)     (ko'rinadigan)  (joy)   (rang)  (qatlam)

4. Batafsil kod namunalari

Misol 1 — <script> joyi va defer/async

<!--  head'da oddiy script — DOM qurilishini bloklaydi 2.4-bob -->
<head>
  <script src="app.js"></script>  <!-- DOM hali yo'q! -->
</head>

<!--  defer — HTML parse'ga xalaqit bermaydi, DOM tayyor bo'lganda ishlaydi -->
<head>
  <script src="app.js" defer></script>
</head>

<!--  yoki: script'ni body oxiriga qo'yish (DOM allaqachon tayyor) -->
<body>
  <h1>Salom</h1>
  <script src="app.js"></script>
</body>

• defer — script fonda yuklanadi, lekin DOM to'liq tayyor bo'lganda, tartib bilan bajariladi (eng tavsiya etilgan).
• async — fon'da yuklanadi va tayyor bo'lishi bilan bajariladi (tartib kafolatlanmaydi; mustaqil skriptlar uchun).

Misol 2 — DOM tayyor bo'lganini kutish

//  NOTO'G'RI — DOM hali qurilmagan bo'lsa, element topilmaydi  null
const tugma = document.querySelector("#btn"); // head'dagi script'da: null!

//  TO'G'RI — DOM to'liq qurilganini kutamiz (2.3)
document.addEventListener("DOMContentLoaded", () => {
  // bu yerga kelganda DOM tayyor
  const tugma = document.querySelector("#btn");
  tugma.addEventListener("click", () => console.log("Bosildi!"));
});

Misol 3 — Reflow'ni o'lchash (bir thread'ni "bloklash")

// JS bir thread'li 2.5-bob: bu tsikl tugamaguncha sahifa QOTADI
console.time("og'ir");
let yigindi = 0;
for (let i = 0; i < 1_000_000_000; i++) {
  yigindi += i; // milliard marta — bu paytda sahifa javob bermaydi
}
console.timeEnd("og'ir"); // masalan "og'ir: 450ms"

// XULOSA: og'ir hisobni asosiy thread'da qilma — sahifani muzlatadi.
// Yechim: bo'laklab qilish, yoki Web Worker (alohida thread).

Misol 4 — Reflow'ni kamaytirish (DOM'ni to'g'ri o'zgartirish)

const ro'yxat = document.querySelector("#list");

//  NOTO'G'RI — tsikl ichida DOM'ni 1000 marta o'zgartirish  1000 reflow 2.6-bob
for (let i = 0; i < 1000; i++) {
  ro'yxat.innerHTML += `<li>Element ${i}</li>`; // har safar qayta hisoblash!
}

//  TO'G'RI — avval xotirada yig'ib, BIR MARTA DOM'ga qo'shamiz
const fragment = document.createDocumentFragment(); // xotiradagi vaqtinchalik konteyner
for (let i = 0; i < 1000; i++) {
  const li = document.createElement("li");
  li.textContent = `Element ${i}`;
  fragment.appendChild(li); // DOM'ga emas, fragmentga (reflow yo'q)
}
ro'yxat.appendChild(fragment); // bitta reflow — tezroq

Misol 5 — Rendering vaqtini o'lchash (Performance API)

// performance.now() — yuqori aniqlikdagi vaqt (millisekund, kasr bilan)
const boshlanish = performance.now();

// ... biror DOM ishi ...
document.body.style.background = "navy";

const tugash = performance.now();
console.log(`Ish ${(tugash - boshlanish).toFixed(2)} ms davom etdi`);

5. To'g'ri va noto'g'ri holatlar

1) Skriptni <head>da defer'siz qo'yish

<!--  DOM qurilishini bloklaydi, sahifa kech ko'rinadi 2.4-bob -->
<head><script src="big.js"></script></head>

<!--  defer bilan -->
<head><script src="big.js" defer></script></head>

2) Asosiy thread'da og'ir hisob

//  butun sahifani muzlatadi (2.5)
const natija = juda_ogir_hisob(); // 3 sekund — sahifa javob bermaydi

//  bo'laklab, yoki Web Worker (alohida thread)da

3) Tsiklda DOM'ni qayta-qayta o'zgartirish (layout thrashing)

//  har iteratsiyada o'qish+yozish  ko'p reflow (2.6)
for (const el of elementlar) {
  el.style.height = el.offsetHeight + 10 + "px"; // o'qish va yozish aralash
}

//  avval hammasini o'qi, keyin hammasini yoz (yoki transform ishlat)

4) Animatsiyani top/left/width bilan qilish

/*  reflow keltiradi — uzilib-uzilib (janky) animatsiya 2.6-bob */
.box { transition: left 0.3s; }

/*  transform — faqat composite, silliq animatsiya */
.box { transition: transform 0.3s; }

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Uncaught TypeError: Cannot read properties of null

Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')

Sababi: JS element'ni DOM qurilmasdan oldin qidirdi — querySelector null qaytardi 2.4-bob. Yechimi: defer ishlating yoki DOMContentLoaded ichida yozing (Misol 2), yoki script'ni </body> oldiga qo'ying.

Xato 2 — Sahifa "qotib qoladi" (Page Unresponsive)

[Brauzer] This page is slowing down your browser

Sababi: asosiy thread'da uzoq ishlayotgan kod (cheksiz tsikl yoki og'ir hisob — 2.5). Yechimi: og'ir ishni bo'laklab qiling, setTimeout/requestIdleCallback yoki Web Worker ishlating.

Xato 3 — FOUC (Flash of Unstyled Content)

Sababi: CSS kech yuklandi, sahifa bir lahza stilsiz ko'rindi 2.3-bob. Yechimi: muhim CSS'ni <head>ga (yoki inline) qo'ying; CSS'ni kechiktirmang.

Xato 4 — Sekin yuklanish (past Performance ball)

Sababi: katta render-blocking CSS/JS, optimallashmagan rasmlar (0.1: rasm hajmi). Yechimi: CSS/JS'ni kichraytirish (minify), defer, lazy-load, rasmlarni siqish (web.dev, 13.10-bob).

Xato 5 — ReferenceError: X is not defined

Sababi: skriptlar noto'g'ri tartibda yuklandi (X'ni ishlatgan skript X'ni yaratgan skriptdan oldin ishladi). Yechimi: tartibni to'g'rilang yoki modullardan foydalaning (2.14-bob).

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

• DOM 2.16-bob: bu bobda tanishgan DOM daraxtini JS bilan o'zgartirish — frontend'ning o'zagi.
• React (11-QISM): "Virtual DOM" — aslida reflow'ni kamaytirish uchun o'ylab topilgan (real DOM o'zgarishini minimal qilish — 2.6).
• Performance optimizatsiya 11.11-bob: re-render, memo — hammasi 2.5–2.6 ga tayanadi.
• Event loop 5.1-bob: 2.5-dagi mexanizm Node kontekstida to'liq ochiladi.
• Browser APIs 2.17-bob: localStorage, fetch — 2.1-dagi brauzer modullari.
• Next.js rendering (13.3, 13.4): SSR/SSG — HTML'ni serverda chizib, brauzer ishini kamaytirish.
• Animatsiya 11.16-bob: Framer Motion — transform/opacity 2.6-bob ga tayanadi.
• Web Worker / performance 15.5-bob: og'ir ishni alohida thread'ga chiqarish.

8. Eng yaxshi amaliyotlar (best practices)

• Skriptni defer bilan yoki </body> oldida qo'ying. DOM'ni bloklamang.
• Asosiy thread'ni bo'shating. Og'ir hisobni bo'laklang yoki Web Worker'ga bering — sahifa qotmasin.
• DOM o'zgarishini yig'ing. Tsiklda emas, DocumentFragment bilan bir marta (Misol 4).
• Animatsiyani transform/opacity bilan qiling. Reflow'dan qoching 2.6-bob.
• DevTools'ni qurol qiling. Network 0.4-bob + Performance + Elements — har kuni ishlating.
• CSS'ni yengil tuting. U render-blocking; keraksiz CSS — sekinlik.
• Rasm va resurslarni optimallashtiring. Hajm = yuklanish vaqti 0.1-bob.
• Lighthouse (DevTools) bilan sahifa tezligini o'lchang va yaxshilang.

9. Amaliy loyiha: "Brauzer Tahlilchisi va Reflow Tajribasi"

DevTools bilan brauzerning ishini ko'rish va reflow'ni his qilish loyihasi.

Maqsad

Real sahifada rendering jarayonini kuzatish, JS'ning bir thread'li tabiatini va reflow'ning narxini amalda ko'rsatish.

Talablar (requirements)

A — kuzatuv (DevTools):

1. Istalgan saytni oching DevTools Performance yozishni boshlang sahifani yangilang to'xtating. Natijada Loading / Scripting / Rendering / Painting vaqtlarini toping va yozing 2.3-bob.
2. Network tab'da render-blocking resurslarni (CSS, JS) aniqlang.
3. Lighthouse (DevTools) bilan sahifa uchun Performance ballini oling va 3 ta tavsiyani yozing.

B — kod tajribasi (bitta HTML fayl): 4. Bitta index.html yozing: tugma va bo'sh <ul id="list">. 5. "Sekin" tugma: bosilganda tsikl ichida innerHTML += bilan 5000 ta <li> qo'shsin ( usul, Misol 4). console.time bilan vaqtini o'lchang. 6. "Tez" tugma: xuddi shu 5000 ta <li> ni DocumentFragment bilan qo'shsin ( usul). Vaqtini o'lchang va solishtiring. 7. "Muzlatish" tugma: asosiy thread'ni 3 sekund bloklaydigan tsikl (Misol 3). Bosilganda sahifa qotishini his qiling 2.5-bob. 8. (Bonus) DOM tayyor bo'lishini DOMContentLoaded bilan to'g'ri kutib, skriptni <head>da defer bilan ulang.

Maslahatlar (hint)

• console.time("nom") ... console.timeEnd("nom") — vaqt o'lchash (Misol 3).
• document.createDocumentFragment() — xotiradagi konteyner (Misol 4).
• "Muzlatish" effekti uchun while (performance.now() - boshlanish < 3000) {} (bo'sh tsikl).
• Performance tab'da "rangli chiziqlar" — sariq=Scripting, binafsha=Rendering, yashil=Painting.

"Tayyor" mezonlari (acceptance criteria)

• Performance yozuvida Loading/Scripting/Rendering/Painting ajratilgan.
• Lighthouse ball va 3 tavsiya yozilgan.
• "Sekin" va "Tez" tugmalar vaqti o'lchangan va farqi aniq ko'rinadi (Fragment tezroq).
• "Muzlatish" tugmasi bosilganda sahifa vaqtincha javob bermaydi (bir thread isboti).
• Skript defer/DOMContentLoaded bilan to'g'ri ishlaydi, null xatosi yo'q.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda brauzer matnni pikselga qanday aylantirishini o'rgandik:

• Brauzer — rendering engine (Blink/WebKit/Gecko) + JS engine (V8...) + tarmoq + saqlash modullaridan iborat. Node ham V8 ustiga qurilgan.
• V8 JS'ni bosqichma-bosqich bajaradi: ParserAST, Ignitionbytecode, TurboFan (JIT)optimallashtirilgan mashina kodi. JS "sekin" emas.
• Critical Rendering Path: HTMLDOM, CSSCSSOM (render-blocking), Render Tree Layout Paint Composite.
• JS rendering'ni bloklaydi (defer/async bilan hal qilinadi); JS bir thread'li — og'ir kod sahifani qotiradi (event loop — 5.1-bobda).
• Reflow (o'lcham o'zgarishi — qimmat) va repaint (rang — arzonroq); animatsiya uchun transform/opacity.

Keyingi bob — 0.6-bob: Algoritmik fikrlash va pseudokod. Endi mashina (0.1–0.2), uni boshqarish 0.3-bob va tarmoqni (0.4–0.5) tushundik. Endi eng muhim ko'nikma — muammoni qadamlarga bo'lib yechish, ya'ni dasturchi kabi fikrlashni o'rganamiz. Bu — har qanday tildan, frameworkdan muhimroq fundament.

Foydalanilgan rasmiy/ishonchli manbalar

• web.dev — Critical Rendering Path (render tree, layout, paint, composite)
• MDN Web Docs — Critical rendering path, DOM, defer/async
• v8.dev — Ignition interpreter, TurboFan JIT, V8 arxitekturasi