Qu'est-ce que le chemin de rendu critique ?

Qu'est-ce que le chemin de rendu critique ?

Le chemin de rendu critique (Critical Rendering Path, CRP) est la suite d'étapes par laquelle le navigateur transforme HTML, CSS et JavaScript en pixels à l'écran : construire le DOM, construire le CSSOM, les combiner en arbre de rendu, calculer la mise en page, puis peindre. Tout ce que le navigateur doit télécharger et traiter avant ce premier affichage se trouve sur le chemin ; le raccourcir permet donc d'afficher le contenu plus tôt.

Comment le navigateur parcourt le chemin

• DOM. Le navigateur analyse le HTML en jetons, puis en nœuds, et construit le Document Object Model. C'est un processus incrémental, qui peut commencer avant l'arrivée de tout le fichier. Selon MDN, plus il y a de nœuds, plus les étapes suivantes sont longues.
• CSSOM. Le CSS est analysé pour former le CSS Object Model. Contrairement au DOM, il n'est pas incrémental, car des règles ultérieures peuvent écraser les précédentes.
• Arbre de rendu. Le DOM et le CSSOM sont combinés. L'arbre ne contient que le contenu visible : les éléments en display: none et leurs descendants en sont exclus, tout comme le head.
• Mise en page (layout). Le navigateur calcule la taille et la position de chaque élément. Elle dépend de la largeur de la fenêtre d'affichage et est donc recalculée à chaque redimensionnement ou rotation de l'appareil.
• Affichage (paint). Le navigateur dessine les pixels. Au chargement, tout l'écran est peint ; ensuite, seules les zones modifiées sont repeintes.

Les indicateurs d'un rapport de vitesse reposent sur ce chemin. Le First Contentful Paint est le premier moment où du contenu est peint : chaque milliseconde que le chemin passe à attendre s'y ajoute directement.

Ce qui bloque le chemin

Le CSS bloque le rendu. D'après MDN, le navigateur retient le rendu tant qu'il n'a pas reçu et traité tout le CSS, car les règles peuvent être écrasées et le contenu ne peut pas être dessiné avant que le CSSOM soit complet.

Les scripts classiques bloquent l'analyse. Un script sans async, defer ni type="module" est téléchargé et exécuté immédiatement, avant que le navigateur poursuive l'analyse de la page (MDN). Lighthouse signale comme bloquant un script du head sans defer ni async, ainsi qu'un lien de feuille de style dont le media correspond à l'appareil. Les deux attributs ne se comportent pas pareil : defer exécute le script après l'analyse, dans l'ordre du document, avant DOMContentLoaded ; async l'exécute dès qu'il est téléchargé, sans ordre garanti. Voir le chargement asynchrone pour choisir entre les deux.

Exemple

Une page marketing charge une grosse feuille de style pour tout le site, un script de gestionnaire de balises dans le head et une bibliothèque de carrousel. Le premier affichage attend la feuille de style et le téléchargement puis l'exécution du script, alors que le visiteur n'a d'abord besoin que du titre et de l'image principale. La correction a trois volets : placer en ligne, dans un bloc <style>, les quelques règles de la partie visible, ajouter defer aux scripts dont le premier écran n'a pas besoin, et demander l'image principale tôt avec un resource hint.

<style>/* seulement les règles du premier écran */</style>
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<script src="/app.js" defer></script>

Comment raccourcir le chemin

• Moins de ressources critiques. Retirez tout ce dont le premier écran n'a pas besoin. L'onglet Coverage de Chrome DevTools montre le CSS et le JavaScript inutilisés.
• Des ressources critiques plus légères. Minifiez et compressez le CSS et le JavaScript, et évitez de gonfler le DOM sans raison.
• CSS critique en ligne, le reste chargé sans bloquer. En découpant les feuilles de style avec l'attribut media, le navigateur ne bloque que sur celles qui correspondent à l'appareil.
• defer ou async pour les scripts inutiles au premier affichage.
• Un meilleur ordre. Faites démarrer tôt, avec un hint, les fichiers découverts tard, comme une image de fond CSS ou une police.

Erreurs courantes

• Mettre tout le CSS en ligne. Chaque page devient plus lourde et la feuille de style perd le cache ; ne placez en ligne que ce dont le premier écran a besoin.
• Mettre async sur des scripts qui dépendent les uns des autres. L'ordre n'est pas garanti : utilisez defer.
• Différer un script qui construit du contenu visible, au risque de laisser un vide ou de faire sauter la mise en page plus tard.
• Optimiser les sélecteurs CSS pour la vitesse. MDN précise que le gain se compte en microsecondes ; mieux vaut s'occuper des fichiers bloquants.
• Ne tester que sur une connexion de bureau rapide. Sur un mobile lent, chaque requête bloquante coûte plus cher.

Lien avec les tests et la surveillance

Les audits en laboratoire listent les requêtes bloquant le rendu d'une page, et la cascade réseau montre ce que le premier affichage a attendu. Pour suivre cela dans le temps, LoadFocus Page Speed Monitoring lance des audits Google Lighthouse selon un calendrier allant de toutes les heures à chaque semaine, depuis 25 régions cloud, avec des alertes par e-mail, Slack ou Microsoft Teams. Le vérificateur gratuit de Core Web Vitals affiche le LCP, l'INP et le CLS d'utilisateurs réels à partir des données CrUX de Google, pour voir si une correction a atteint les visiteurs. D'autres améliorations front-end figurent dans le guide en 10 étapes pour accélérer un site. Pour les définitions précises, consultez le guide MDN du chemin de rendu critique.

Questions fréquentes : chemin de rendu critique

Quelles sont les étapes du chemin de rendu critique ?

Construire le DOM à partir du HTML, construire le CSSOM à partir du CSS, les combiner en un arbre de rendu du contenu visible, calculer la mise en page et peindre les pixels.

JavaScript bloque-t-il le rendu ?

Un script classique sans async, defer ni type module bloque l'analyse du HTML pendant son téléchargement et son exécution, et Lighthouse le signale comme bloquant s'il est dans le head. Avec defer ou async, il ne bloque plus.

Pourquoi le CSS bloque-t-il le rendu ?

Les règles CSS ultérieures peuvent écraser les précédentes : le navigateur attend donc que le CSSOM soit complet avant de dessiner quoi que ce soit.

Qu'est-ce que le CSS critique ?

C'est le petit ensemble de règles nécessaire pour dessiner le premier écran. Il est placé en ligne dans le head, et le reste du CSS est chargé sans bloquer le premier affichage.

Comment mesurer le chemin de rendu critique ?

Lancez un audit Lighthouse pour voir les requêtes bloquantes et lisez une cascade réseau pour voir ce que le premier affichage a attendu. Répétez la mesure depuis plusieurs régions et avec une connexion bridée.