Navigateurs & Rendu

Que fait réellement un navigateur ?

Un navigateur est un environnement d’exécution, et pas seulement un visualiseur de documents. Il analyse le HTML et le CSS pour les transformer en arbres, exécute le JavaScript, expose des API pour le réseau et le stockage, et convertit le résultat en pixels. Comprendre ce pipeline permet de transformer l’optimisation des performances : on passe alors du tâtonnement à l’ingénierie.

Les éditeurs de navigateurs proposent trois moteurs principaux : Blink (Chrome, Edge, Opera), Gecko (Firefox) et WebKit (Safari). Ils implémentent les mêmes standards, donc les concepts abordés ici s’appliquent partout, même lorsque les détails techniques diffèrent.

Analyse du HTML vers le DOM

Lorsque le navigateur reçoit du HTML, il l’analyse pour créer le DOM : un arbre d’objets représentant chaque élément, attribut et fragment de texte. L’analyseur fonctionne en streaming, ce qui lui permet de commencer à construire l’arbre avant même que l’intégralité du document ne soit reçue.

L’analyse du HTML est résiliente par conception. Une balise de fermeture manquante ou un élément mal placé n’interrompt pas le chargement de la page ; l’analyseur récupère l’erreur et continue. C’est pourquoi un balisage mal formé s’affiche tout de même, et c’est aussi pourquoi la validation de votre HTML est essentielle pour garantir un comportement prévisible.

CSS et le CSSOM

Les feuilles de style sont analysées pour créer le CSSOM, un arbre de règles. Le navigateur calcule ensuite le style final de chaque élément en combinant la cascade, l’héritage et la spécificité.

Le CSS est render-blocking (bloquant pour le rendu) : le navigateur ne procèdera pas au rendu tant qu’il n’aura pas les styles nécessaires, car un rendu avec des styles incorrects provoquerait un flash visuel. C’est pourquoi une feuille de style volumineuse dans le head retarde le premier rendu (first paint), et pourquoi l’intégration du CSS critique en ligne (inlining) est utile.

L’arbre de rendu (render tree)

Le DOM et le CSSOM se combinent pour former l’arbre de rendu, qui ne contient que les éléments qui seront réellement affichés, chacun avec ses styles calculés. Les éléments avec display: none sont exclus ; les éléments visibility: hidden sont inclus mais ne sont pas peints.

À partir de là, le navigateur sait quoi dessiner, mais pas encore où.

Layout

Le Layout, également appelé reflow, calcule la taille et la position de chaque boîte de l’arbre de rendu (render tree). Il parcourt l’arbre, résout les largeurs, hauteurs, marges, paddings et le positionnement, pour produire un modèle de boîte avec une géométrie exacte.

Le Layout est coûteux car les changements peuvent se propager en cascade : le redimensionnement d’un élément peut déplacer ses éléments frères, son parent et tout ce qui se trouve en dessous. La lecture de propriétés comme offsetHeight force le navigateur à s’assurer que le layout est à jour ; ainsi, l’alternance de lectures et d’écritures déclenche des layouts répétés.

Peinture et composition (Paint and composite)

Après le layout, le navigateur effectue la peinture (paint) des boîtes dans des couches (layers), en remplissant les couleurs, le texte, les images, les bordures et les ombres. Il composite ensuite ces couches, souvent via le GPU, pour produire l’image finale.

Certaines modifications sont moins coûteuses que d’autres :

• Modifier une couleur déclenche le paint.
• Modifier une taille déclenche le layout et le paint.
• Modifier transform ou opacity peut être géré par le compositeur, court-circuitant ainsi totalement le layout et le paint.

C’est pourquoi les animations devraient se limiter aux transforms et à l’opacity. Consultez le guide des animations CSS et le guide de performance Web.

Le chemin de rendu critique (Critical Rendering Path)

Le chemin allant du HTML aux premiers pixels affichés est le suivant :

1. Analyser (Parse) le HTML pour créer le DOM.
2. Analyser (Parse) le CSS pour créer le CSSOM.
3. Combiner les deux pour former l’arbre de rendu (render tree).
4. Calculer la disposition (Layout) des boîtes.
5. Peindre (Paint) et composer (composite) l’image.

Réduire la longueur de ce chemin est l’élément central de la performance perçue : moins de ressources bloquantes, un CSS plus léger et un JavaScript qui ne gêne pas le processus.

<!-- fast.html -->
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin />
<style>/* critical, above-the-fold CSS */</style>
<script src="/app.js" defer></script>

preload lance les requêtes importantes le plus tôt possible, l’intégration du CSS critique (inlined critical CSS) évite un aller-retour bloquant, et defer permet à l’analyseur de terminer son travail avant l’exécution du script.

Le thread principal et JavaScript

Le thread principal gère l’exécution de JavaScript, le layout, le paint et la gestion des événements. Une seule tâche peut s’exécuter à la fois ; ainsi, une tâche trop longue bloque les entrées utilisateur et donne l’impression que la page est figée.

• Gardez vos tâches courtes et fragmentez les opérations coûteuses.
• Déplacez les calculs lourds vers un Web Worker, qui s’exécute sur un thread séparé.
• Évitez le “layout thrashing” en regroupant les lectures et écritures du DOM.
• Laissez la main au navigateur entre chaque bloc de travail.

Il s’agit de la même boucle d’événements que vous avez découverte dans le guide JavaScript, mais avec l’ajout des tâches de rendu qui se disputent le même thread.

Stockage et API du navigateur

Au-delà du rendu, le navigateur propose des API de stockage et de plateforme : les cookies, localStorage et sessionStorage, IndexedDB, la Cache API, les service workers, WebSockets, WebRTC, le presse-papier, les notifications et bien plus encore. C’est grâce à elles qu’une page web peut se comporter comme une application. Le guide PWA traite des service workers et de la mise en cache.

Bonnes pratiques

• Gardez le chemin critique court : intégrez le CSS critique en ligne et différez le chargement des scripts.
• Utilisez preload pour les polices et autres ressources critiques pour le rendu.
• Animez les propriétés transform et opacity, et non les propriétés de mise en page (layout).
• Regroupez les lectures et écritures du DOM pour éviter le “layout thrashing”.
• Gardez les tâches JavaScript courtes ; utilisez des Web Workers pour les traitements lourds.
• Réservez l’espace pour les images et les contenus intégrés afin d’éviter les décalages de mise en page (layout shift).
• Testez sur plusieurs moteurs de rendu, en particulier Safari et sur mobile.

Erreurs courantes

• Confondre le DOM avec la source HTML.
• Bloquer le rendu avec des feuilles de style volumineuses ou des scripts synchrones.
• Lire des propriétés de mise en page dans une boucle, provoquant ainsi des reflows répétés.
• Animer width ou top, ce qui cause du jank.
• Exécuter des calculs lourds sur le thread principal.
• Tester sur un seul navigateur et ignorer les différences entre les moteurs.

Et après ?

La compréhension du fonctionnement interne du navigateur permet de saisir pourquoi les conseils de performance sont efficaces. Mettez cela en pratique avec le guide sur la performance Web, apprenez à animer efficacement avec les CSS Animations, et manipulez l’arbre du document en toute sécurité avec la DOM Manipulation. Ensuite, ouvrez les DevTools et observez le pipeline de rendu dans le panneau de performance.