Hvordan parser nettleseren HTML og bygger siden (kritisk renderingsbane)?

Question

Accepted Answer

**Kritisk renderingsbane** er sekvensen av trinn nettleseren tar for å gjøre HTML, CSS og JS om til piksler. Å forstå den forklarer hva som blokkerer rendering og hvordan man gjør sider raskere å tegne. ## Trinnene ```text 1. Parse HTML → DOM tree (the document structure) 2. Parse CSS → CSSOM tree (the style rules) 3. DOM + CSSOM → Render tree (visible nodes + their styles) 4. Layout (reflow) → compute each node's geometry (position/size) 5. Paint → fill in pixels (colors, text, images) 6. Composite → combine layers onto the screen ``` ## Hva blokkerer rendering **CSS er render-blocking.** Nettleseren tegner ikke før CSSOM er klar (for å unngå at ustylet innhold vises kort). Så stor/langsom CSS forsinker første tegning — hold kritisk CSS liten og inlines den når mulig. **Synkrone skript blokkerer parsing.** Et vanlig ` ``` Verre, et synkront skript som trenger CSSOM (f.eks. leser beregnede stiler) venter på CSS også — så en CSS-fil kan indirekte blokkere et skript, som blokkerer parseren. ## Hvordan optimalisere det - Legg CSS i `` (last den tidlig); inline kritisk CSS. - Legg til `defer` (eller `type="module"`) til skript, eller plasser dem før ``. - Minimer og komprimer CSS/JS; fjern ubrukte regler. - Bruk `preload` for kritiske fonter/ressurser, `preconnect` for viktige kilder. - Unngå layout thrashing (gjentatt lesing/skriving av layout i JS) — det tvinger ekstra reflows. ## Hvorfor det betyr noe Den kritiske renderingsbanen bestemmer målinger som First Contentful Paint og Largest Contentful Paint. Å vite at CSS blokkerer rendering og synkron JS blokkerer parsing, forteller deg nøyaktig hvorfor `defer`/`async`, inlined kritisk CSS og resource hints gjør siden raskere — de forkorter eller fjerner blokkering av denne banen.