Le chemin critique du rendu désigne les étapes nécessaires jusqu'à ce que la page Web commence à s'afficher dans le navigateur. Pour afficher les pages, les navigateurs ont besoin du document HTML lui-même ainsi que de toutes les ressources essentielles nécessaires à l'affichage de ce document.
L'importation du document HTML dans le navigateur a été abordée dans le précédent module Considérations générales sur les performances HTML (en anglais). Dans ce module, nous examinerons en détail ce que fait le navigateur après avoir téléchargé le document HTML pour afficher la page.
Rendu progressif
Le Web est distribué par nature. Contrairement aux applications natives qui sont installées avant utilisation, les navigateurs ne peuvent pas dépendre de sites Web disposant de toutes les ressources nécessaires pour afficher la page. Les navigateurs sont donc très efficaces pour afficher les pages progressivement. Les applications natives comportent généralement une phase d'installation, puis une phase d'exécution. Toutefois, pour les pages Web et les applications Web, les lignes entre ces deux phases sont bien moins distinctes, et les navigateurs ont été spécialement conçus dans cet esprit.
Une fois que le navigateur dispose des ressources nécessaires pour afficher une page, il commence généralement à le faire. Le choix consiste donc à déterminer quand afficher: à quel moment est-il trop tôt ?
Si le navigateur s'affiche dès que possible alors qu'il contient juste du code HTML, mais avant de disposer du code CSS ou du code JavaScript nécessaire, la page risque d'être temporairement endommagée et changer considérablement pour l'affichage final. C'est une expérience pire que de présenter initialement un écran vide pendant un certain temps jusqu'à ce que le navigateur dispose de plus de ces ressources nécessaires pour un rendu initial offrant une meilleure expérience utilisateur.
En revanche, si le navigateur attend que toutes les ressources soient disponibles au lieu d'effectuer un affichage séquentiel, l'utilisateur devra patienter longtemps. Cela se produit souvent inutilement si la page était utilisable beaucoup plus tôt.
Le navigateur doit connaître le nombre minimal de ressources qu'il doit attendre afin d'éviter de présenter une expérience manifestement défaillante. D'autre part, le navigateur ne doit pas attendre plus longtemps que nécessaire avant de présenter du contenu à l'utilisateur. La séquence des étapes suivies par le navigateur avant d'effectuer le rendu initial est appelée chemin critique du rendu.
Comprendre le chemin critique du rendu peut vous aider à améliorer vos performances Web en vous assurant de ne pas bloquer l'affichage de la page initiale plus que nécessaire. Toutefois, il est important de ne pas autoriser le rendu trop tôt en supprimant les ressources nécessaires pour ce rendu initial du chemin critique.
Chemin de rendu (critique)
Le chemin de rendu implique les étapes suivantes:
- Créer le modèle objet de document (DOM) à partir du code HTML
- Créer le modèle d'objet CSS (CSSOM) à partir du CSS
- Appliquer du code JavaScript qui modifie le DOM ou le CSSOM
- Création de l'arborescence de rendu à partir des éléments DOM et CSSOM
- Effectuez des opérations de style et de mise en page sur la page pour voir quels éléments se situent.
- Peignez les pixels des éléments en mémoire.
- Combinez les pixels si l'un d'entre eux se chevauche.
- Dessinez physiquement tous les pixels obtenus à l'écran.
Le contenu ne s'affiche à l'écran qu'une fois toutes ces étapes terminées.
Ce processus d'affichage se produit plusieurs fois. Le rendu initial appelle ce processus, mais à mesure que de nouvelles ressources affectant le rendu de la page deviennent disponibles, le navigateur réexécute ce processus (ou peut-être seulement une partie de celui-ci) pour mettre à jour ce que voit l'utilisateur. Le chemin critique du rendu se concentre sur le processus décrit précédemment pour le rendu initial et dépend des ressources critiques nécessaires.
Quelles ressources se trouvent sur le chemin critique du rendu ?
Le navigateur doit attendre le téléchargement de certaines ressources critiques avant de pouvoir terminer le rendu initial. Voici notamment ce que vous y trouverez :
- Une partie du code HTML.
- Code CSS qui bloque l'affichage dans l'élément
<head>. - Code JavaScript bloquant l'affichage dans l'élément
<head>.
Il est important de noter que le navigateur traite le code HTML en streaming. Dès que le navigateur reçoit une partie du code HTML d'une page, il commence à la traiter. Le navigateur peut alors (et le fait souvent) décider de l'afficher correctement avant de recevoir le reste du code HTML d'une page.
Il est important de noter que pour le rendu initial, le navigateur n'attend généralement pas:
- Tout le code HTML.
- Polices.
- des images.
- Code JavaScript qui ne bloque pas l'affichage en dehors de l'élément
<head>(par exemple, les éléments<script>placés à la fin du code HTML). - CSS qui ne bloque pas l'affichage en dehors de l'élément
<head>, ou CSS avec une valeur d'attributmediaqui ne s'applique pas à la fenêtre d'affichage actuelle.
Les polices et les images sont souvent considérées par le navigateur comme du contenu à remplir lors du nouveau rendu de la page. Elles n'ont donc pas besoin de bloquer le rendu initial. Toutefois, cela peut signifier que des zones vides sont laissées dans le rendu initial pendant que le texte est masqué en attendant des polices ou jusqu'à ce que des images soient disponibles. Pire encore, lorsque l'espace réservé n'est pas suffisant pour certains types de contenu (en particulier lorsque les dimensions de l'image ne sont pas fournies dans le code HTML), la mise en page de la page peut être décalée lors du chargement ultérieur de ce contenu. Cet aspect de l'expérience utilisateur est mesuré par la métrique Cumulative Layout Shift (CLS).
L'élément <head> est essentiel pour traiter le chemin critique du rendu. À tel point que la section suivante aborde ce sujet en détail. L'optimisation du contenu de l'élément <head> est un aspect clé des performances Web. Toutefois, pour comprendre le chemin critique du rendu pour le moment, il vous suffit de savoir que l'élément <head> contient des métadonnées sur la page et ses ressources, mais pas de contenu réel que l'utilisateur peut voir. Le contenu visible est contenu dans l'élément <body> qui suit l'élément <head>. Pour que le navigateur puisse afficher le contenu, il a besoin à la fois du contenu à afficher et des métadonnées sur la manière de l'afficher.
Cependant, toutes les ressources référencées dans l'élément <head> ne sont pas strictement nécessaires au rendu initial de la page. Le navigateur n'attend donc que celles qui le sont. Pour identifier les ressources qui se trouvent sur le chemin critique du rendu, vous devez comprendre les langages CSS et JavaScript qui bloquent l'affichage et bloquent les analyseurs.
Ressources bloquant l'affichage
Certaines ressources sont jugées si critiques que le navigateur met en pause l'affichage de la page jusqu'à ce qu'il les traite. Le CSS entre dans cette catégorie par défaut.
Lorsqu'un navigateur voit le code CSS, qu'il s'agisse d'un code CSS intégré dans un élément <style> ou d'une ressource référencée en externe spécifiée par un élément <link rel=stylesheet href="...">, le navigateur évite d'afficher d'autres contenus tant qu'il n'a pas terminé de télécharger et de traiter ce CSS.
Le fait qu'une ressource bloque le rendu ne signifie pas nécessairement qu'elle empêche le navigateur de faire autre chose. Les navigateurs essaient d'être aussi efficaces que possible. Par conséquent, lorsqu'un navigateur détecte qu'il doit télécharger une ressource CSS, il la demande et interrompt l'affichage, mais continue de traiter le reste du code HTML et recherche d'autres tâches en attendant.
Les ressources qui bloquent l'affichage, comme les fichiers CSS, permettent de bloquer l'affichage complet de la page lorsqu'elles ont été découvertes. Cela signifie que le fait qu'un CSS bloque ou non l'affichage dépend de sa détection par le navigateur. Certains navigateurs (Firefox dans un premier temps, et désormais également Chrome) ne bloquent que l'affichage du contenu situé sous la ressource qui bloque l'affichage. Cela signifie que pour le chemin critique qui bloque l'affichage, nous nous intéressons généralement aux ressources qui bloquent l'affichage dans <head>, car elles bloquent effectivement l'affichage de la page entière.
Une innovation plus récente est l'attribut blocking=render, ajouté à Chrome 105. Cela permet aux développeurs de marquer explicitement un élément <link>, <script> ou <style> comme bloquant le rendu jusqu'à ce que l'élément soit traité, tout en permettant à l'analyseur de continuer à traiter le document en attendant.
Ressources bloquantes par l'analyseur
Les ressources qui bloquent l'analyseur sont celles qui empêchent le navigateur de rechercher d'autres tâches à effectuer en continuant à analyser le code HTML. Par défaut, JavaScript bloque l'analyse (sauf s'il est spécifiquement marqué comme asynchrone ou différé), car JavaScript peut modifier le DOM ou le CSSOM lors de son exécution. Par conséquent, le navigateur ne peut pas continuer à traiter d'autres ressources tant qu'il ne connaît pas l'impact complet du code JavaScript demandé sur le code HTML d'une page. Le code JavaScript synchrone bloque donc l'analyseur.
Les ressources qui bloquent les analyseurs bloquent également l'affichage. Étant donné que l'analyseur ne peut pas dépasser une ressource bloquant l'analyse tant qu'elle n'a pas été entièrement traitée, il ne peut pas accéder au contenu qui la suit ni l'afficher. En attendant, le navigateur peut afficher tout code HTML reçu jusqu'à présent, mais en ce qui concerne le chemin d'affichage critique, toute ressource qui bloque les analyseurs dans <head> signifie que l'affichage de tout le contenu de la page est bloqué.
Bloquer l'analyseur peut entraîner un coût de performances énorme, bien plus que le blocage de l'affichage. Pour cette raison, les navigateurs essaieront de réduire ce coût en utilisant un analyseur HTML secondaire, appelé outil d'analyse de préchargement, pour télécharger les ressources à venir lorsque l'analyseur HTML principal est bloqué. Bien que cela ne soit pas aussi efficace que d'analyser le code HTML, cela permet au moins aux fonctions de mise en réseau du navigateur de avancer sur l'analyseur bloqué, ce qui signifie qu'il sera moins susceptible d'être à nouveau bloqué à l'avenir.
Identifier les ressources bloquantes
De nombreux outils d'audit des performances identifient les ressources qui bloquent le rendu et les analyseurs. WebPageTest marque les ressources bloquant l'affichage à l'aide d'un cercle orange à gauche de l'URL de la ressource:
Toutes les ressources qui bloquent l'affichage doivent être téléchargées et traitées avant le début du rendu, ce qui est indiqué par la ligne verte foncée dans la cascade.
Lighthouse met également en évidence les ressources bloquant l'affichage, mais de manière plus subtile, et uniquement si elles retardent réellement l'affichage de la page. Cela peut être utile pour éviter les faux positifs lorsque vous minimisez le blocage de l'affichage. L'exécution via Lighthouse la même URL de page que la figure WebPageTest précédente n'identifie qu'une des feuilles de style comme ressource bloquant l'affichage.
Optimiser le chemin critique du rendu
L'optimisation du chemin critique du rendu implique de réduire le délai de réception du code HTML (représenté par la métrique Time to First Byte (TTFB)) comme détaillé dans le module précédent, ainsi que de réduire l'impact des ressources qui bloquent l'affichage. Ces concepts seront étudiés dans les modules suivants.
Chemin critique du rendu du contenu
Pendant longtemps, le chemin critique du rendu s'est concentré sur le rendu initial. Cependant, de plus en plus de métriques centrées sur l'utilisateur sont apparues pour les performances Web. On peut donc se demander si le point final du chemin de rendu critique doit être le tout premier ou l'un des autres coloris plus riches qui suivent.
Une autre approche consiste à se concentrer sur le temps écoulé avant le Largest Contentful Paint (LCP) (ou même First Contentful Paint (FCP)) dans un chemin de rendu contenu (ou chemin clé, comme d'autres pourraient l'appeler). Dans ce cas, vous devrez peut-être inclure des ressources qui ne sont pas nécessairement bloquantes, comme c'est généralement le cas pour le chemin critique du rendu, mais qui sont nécessaires pour afficher Contentful Paints.
Quelle que soit votre définition exacte de ce que vous définissez comme "critique", il est important de comprendre ce qui constitue tout rendu initial et votre contenu clé. L'outil "First Paint" mesure la première opportunité possible d'afficher tout pour l'utilisateur. Idéalement, il doit s'agir d'un élément significatif (et non d'une couleur d'arrière-plan, par exemple), mais même s'il ne présente pas de contenu, il est toujours utile de présenter quelque chose à l'utilisateur, ce qui constitue un argument pour mesurer le chemin critique du rendu tel qu'il a été défini de façon traditionnelle. Parallèlement, il est utile de mesurer le moment où le contenu principal est présenté à l'utilisateur.
Identifier le chemin d'affichage du contenu
De nombreux outils peuvent identifier les éléments LCP et le moment de leur rendu. En plus de l'élément LCP, Lighthouse permet d'identifier les phases LCP et le temps passé dans chacune d'elles pour vous aider à déterminer où concentrer vos efforts d'optimisation:
Pour les sites plus complexes, Lighthouse met également en évidence les chaînes de requêtes critiques dans un audit distinct:
Cet audit Lighthouse examine toutes les ressources chargées avec une priorité élevée. Il inclut donc les polices Web et d'autres contenus définis par Chrome comme une ressource à priorité élevée, même si ce n'est pas réellement qui bloque l'affichage.
Tester vos connaissances
À quoi fait référence le chemin critique du rendu ?
Quelles ressources sont impliquées dans le chemin critique du rendu ?
<head>.<head>.Pourquoi le blocage de l'affichage est-il une partie nécessaire du rendu des pages ?
Pourquoi JavaScript bloque-t-il l'analyseur HTML (en supposant que les attributs defer, async ou module ne sont pas spécifiés dans un élément <script>) ?
<script> bloque l'analyseur et l'affichage.À suivre: Optimiser le chargement des ressources
Dans ce module, nous avons abordé certaines notions théoriques qui sous-tendent le rendu d'une page Web par le navigateur, et en particulier ce qui est nécessaire pour effectuer le rendu initial d'une page. Le module suivant explique comment optimiser ce chemin de rendu en apprenant à optimiser le chargement des ressources.