Come il browser analizza l'HTML e costruisce la pagina (critical rendering path)?

Question

Accepted Answer

Il **critical rendering path** è la sequenza di passaggi che il browser segue per trasformare HTML, CSS e JS in pixel. Comprenderlo spiega cosa blocca il rendering e come rendere le pagine più veloci. ## I passaggi ```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 ``` ## Cosa blocca il rendering **CSS è render-blocking.** Il browser non disegnerà finché il CSSOM non è pronto (per evitare un flash di contenuto non stilizzato). Quindi CSS grande/lento ritarda il first paint — mantieni il CSS critico piccolo e incorporalo quando possibile. **Gli script sincroni sono parser-blocking.** Un semplice ` ``` Peggior ancora, uno script sincrono che ha bisogno del CSSOM (ad esempio legge gli stili calcolati) attende anche il CSS — quindi un file CSS può indirettamente bloccare uno script, che blocca il parser. ## Come ottimizzarlo - Metti il CSS in `` (caricalo presto); incorpora il CSS critico. - Aggiungi `defer` (o `type="module"`) agli script, o posizionali prima di ``. - Minimizza e comprimi CSS/JS; rimuovi le regole non utilizzate. - Usa `preload` per font/asset critici, `preconnect` per origini chiave. - Evita il layout thrashing (lettura/scrittura ripetuta del layout in JS) — forza reflow extra. ## Perché è importante Il critical rendering path determina metriche come First Contentful Paint e Largest Contentful Paint. Sapere che CSS blocca il rendering e che JS sincrono blocca l'analisi ti dice esattamente perché `defer`/`async`, il CSS critico incorporato e gli hint di risorsa velocizzano una pagina — accorciano o sbloccano questo path.