Comment le navigateur analyse le HTML et construit la page (critical rendering path) ?

Question

Accepted Answer

La **critical rendering path** est la séquence d'étapes que le navigateur effectue pour transformer HTML, CSS et JS en pixels. La comprendre explique ce qui bloque le rendu et comment faire peindre les pages plus vite. ## Les étapes ```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 ``` ## Ce qui bloque le rendu **Le CSS bloque le rendu.** Le navigateur ne peindra pas tant que le CSSOM n'est pas prêt (pour éviter un flash de contenu non stylisé). Ainsi, un CSS volumineux ou lent retarde le premier affichage — gardez le CSS critique petit et inlinisez-le si possible. **Les scripts synchrones bloquent l'analyseur.** Un ` ``` Pire, un script synchrone qui nécessite le CSSOM (par exemple lire les styles calculés) attend le CSS aussi — donc un fichier CSS peut indirectement bloquer un script, qui bloque l'analyseur. ## Comment l'optimiser - Mettez le CSS dans `` (chargez-le tôt) ; inlinisez le CSS critique. - Ajoutez `defer` (ou `type="module"`) aux scripts, ou placez-les avant ``. - Minimisez et compressez CSS/JS ; supprimez les règles inutilisées. - Utilisez `preload` pour les fonts/ressources critiques, `preconnect` pour les origines clés. - Évitez le layout thrashing (lecture/écriture répétée du layout en JS) — cela force des reflows supplémentaires. ## Pourquoi c'est important La critical rendering path détermine des métriques comme First Contentful Paint et Largest Contentful Paint. Savoir que le CSS bloque le rendu et que le JS synchrone bloque l'analyse vous dit exactement pourquoi `defer`/`async`, le CSS critique inlinisé et les resource hints accélèrent une page — ils raccourcissent ou débloquent ce chemin.