Idées reçues sur la façon d'optimiser le LCP

Il peut être difficile d'améliorer le Largest Contentful Paint (LCP) d'une page, car cela implique souvent plusieurs éléments en mouvement et des compromis. Cet article examine les données sur le terrain issues de chargements de pages réels sur le Web pour déterminer sur quoi les développeurs doivent concentrer leurs efforts d'optimisation.

Pour la plupart des pages Web, l'élément LCP est une image. Il est donc naturel de penser que le meilleur moyen d'améliorer le LCP est d'optimiser l'image du LCP.

Depuis environ cinq ans, depuis l'introduction du LCP, ce conseil a souvent été le principal. Assurez-vous que vos images sont correctement dimensionnées et suffisamment compressées. N'hésitez pas à utiliser un format d'image du 21e siècle. Lighthouse propose même trois audits différents pour formuler ces suggestions.

Les trois audits d'optimisation des images dans un rapport Lighthouse
Les trois audits d'optimisation des images dans un rapport Lighthouse.

Ce conseil est si courant en partie parce que les octets en trop sont faciles à mesurer et que les outils de compression d'images sont faciles à suggérer. Selon vos pipelines de compilation et de déploiement, il peut également être facile à implémenter.

Si c'est le cas, faites-le. Envoyer moins d'octets à vos utilisateurs est presque toujours une bonne chose. De nombreux sites Web diffusent encore des images inutilement volumineuses, que même une compression de base pourrait résoudre.

Toutefois, lorsque nous avons commencé à examiner les données de performances sur le terrain des utilisateurs dans Chrome pour déterminer où le temps avant le LCP est généralement dépensé, nous avons constaté que le temps de téléchargement des images n'était presque jamais le goulot d'étranglement.

En revanche, d'autres parties de la LCP constituent un problème beaucoup plus important.

Répartition des sous-parties du LCP

Pour identifier les plus grandes opportunités d'amélioration du LCP, nous avons examiné les données des sous-parties du LCP, comme décrit dans Optimiser le LCP.

Bien que chaque page et chaque framework puissent adopter une approche différente pour charger et afficher ce qui deviendra l'élément LCP de la page, chacun peut être divisé en sous-parties:

Décomposition de la LCP en quatre sous-parties

Citant cet article, les sous-parties sont les suivantes:

Temps de latence du premier octet (TTFB)
Délai écoulé entre le déclenchement du chargement de la page par l'utilisateur et la réception par le navigateur du premier octet de la réponse du document HTML.
Délai de chargement de la ressource
Temps écoulé entre le TTFB et le moment où le navigateur commence à charger la ressource LCP. Si l'élément LCP ne nécessite pas de chargement de ressources pour s'afficher, cette valeur est 0.
Durée de chargement de la ressource
Durée de chargement de la ressource LCP elle-même. Si l'élément LCP ne nécessite pas de chargement de ressources pour s'afficher, cette valeur est 0.
Délai d'affichage de l'élément
Temps écoulé entre la fin du chargement de la ressource LCP et l'affichage complet de l'élément LCP.

Données réelles sur les performances de navigation

Graphique à barres illustrant les différences de temps passé dans chaque sous-partie de la LCP, regroupées dans des catégories de LCP (bon, amélioration nécessaire et médiocre). La durée du TTFB et du délai de chargement augmente rapidement, tandis que la durée de chargement et le délai de rendu restent courts. Les données sont reproduites dans le tableau ci-dessous.

Score LCP TTFB (ms) Délai de chargement des images (ms) Durée de chargement de l'image (ms) Délai d'affichage (ms)
Bonne 600 350 160 230
Amélioration nécessaire 1 360 720 270 310
Médiocre 2 270 1 290 350 360

Pour cet article, nous avons utilisé les données des navigations de pages avec un LCP d'image de sous-ressource dans Chrome pour examiner les sous-parties du LCP. Nous avons déjà examiné ce type de données, mais jamais à partir de données sur le terrain pour voir où les utilisateurs réels passent leur temps en attendant le LCP d'une page.

Comme pour les Core Web Vitals, nous avons calculé le 75e centile (p75) de chaque sous-partie de la LCP pour chaque origine de l'ensemble de données CrUX. Cela a donné quatre distributions de valeurs p75 (une pour chaque sous-partie). Pour résumer ces distributions, nous avons calculé la médiane de ces valeurs pour toutes les origines de chacune des quatre sous-parties de la LCP.

Enfin, nous répartissons les origines en groupes selon que leur LCP au 75e centile est bon, à améliorer ou médiocre. Cela permet de voir ce qui distingue une origine avec un bon LCP d'une origine avec un mauvais LCP.

Réduire la taille de votre image LCP ? Cette fois avec des données

La durée de chargement mesure le temps nécessaire pour extraire la ressource LCP, dans ce cas une image. Ce temps est généralement proportionnel au nombre d'octets de l'image. C'est pourquoi nous vous conseillons de réduire ce nombre d'octets pour améliorer les performances.

En examinant la répartition du temps dans les graphiques précédents, une chose ressort : la durée de chargement des images n'est pas très longue. En fait, il s'agit de la sous-partie LCP la plus courte, dans tous les buckets LCP. La durée de chargement est plus longue pour les origines avec un LCP faible que pour celles avec un LCP élevé, mais ce n'est pas là que le temps est principalement dépensé.

La majorité des origines avec un LCP faible passent moins de 10% de leur temps LCP p75 à télécharger l'image LCP.

Oui, vous devez vous assurer que vos images sont optimisées, mais ce n'est qu'une partie de l'amélioration du LCP. Il ressort clairement de ces données que, pour une origine typique sur le Web, les gains potentiels en millisecondes pour le LCP sont faibles dans l'ensemble, quel que soit le schéma de compression.

Dernière surprise: les temps de chargement lents étaient autrefois attribués aux appareils mobiles et à la qualité des réseaux mobiles. Il y a quelques années, nous nous attendions à ce qu'un téléphone standard mette plusieurs fois plus de temps à télécharger une image qu'un ordinateur de bureau connecté par câble. Les données suggèrent que ce n'est plus le cas. Pour les origines avec un LCP médiocre, la durée médiane de chargement d'image p75 n'est que 20% plus lente sur mobile que sur ordinateur.

Temps de latence du premier octet (TTFB)

Pour les navigations qui envoient une requête réseau, le TTFB prend toujours un certain temps. Une recherche DNS et le démarrage d'une connexion prennent du temps. Et vous ne pouvez pas lutter contre les lois de la physique: une requête doit parcourir le monde réel via des fils et des câbles optiques pour atteindre un serveur, puis la réponse doit faire le chemin inverse. Même l'origine médiane avec un bon LCP passe plus d'une demi-seconde sur le TTFB au 75e percentile.

Toutefois, la disparité de TTFB entre les origines de LCP bonnes et mauvaises montre qu'il existe des possibilités d'amélioration. Pour au moins la moitié des origines présentant un LCP faible, le TTFB p75 de 2 270 millisecondes seul garantit presque que le LCP p75 ne peut pas être plus rapide que le seuil de 2,5 secondes considéré comme "bon". Même une réduction modérée de ce délai entraînerait une amélioration significative du LCP.

Vous ne pourrez peut-être pas défier les lois de la physique, mais il existe des solutions. Par exemple, si vos utilisateurs se trouvent souvent dans des zones géographiques très différentes de celles de vos serveurs, un CDN peut rapprocher vos contenus d'eux.

Pour en savoir plus, consultez le guide d'optimisation du TTFB.

Délai de chargement de la ressource, responsable méconnu du temps LCP lent

Si le TTFB peut être amélioré, mais que les améliorations sont limitées par la physique, le délai de chargement des ressources peut être éliminé, en pratique uniquement limité par votre architecture de diffusion.

Cette sous-partie mesure le temps écoulé entre l'arrivée du premier octet de la réponse HTML (TTFB) et le moment où le navigateur lance une requête pour l'image LCP. Depuis des années, nous nous concentrons sur le temps de téléchargement des images LCP, mais nous avons souvent ignoré le temps perdu avant même que le navigateur ne soit invité à lancer le téléchargement.

Le site médian avec un LCP faible passe presque quatre fois plus de temps à attendre le début du téléchargement de l'image LCP qu'à le télécharger réellement, avec un temps d'attente de 1,3 seconde entre le TTFB et la requête d'image. Cela représente plus de la moitié du budget de 2,5 secondes pour le LCP dépensé en une seule sous-partie.

Les chaînes de dépendances sont une cause courante de longs délais de chargement. Dans le cas le plus simple, une page charge une feuille de style qui, une fois la mise en page effectuée par le navigateur, définit une image de fond qui deviendra le LCP. Toutes ces étapes doivent être effectuées avant que le navigateur ne sache même commencer à télécharger l'image du LCP.

En utilisant les données d'exploration publiques d'HTTP Archive, qui enregistrent la chaîne d'initiateurs des requêtes réseau du document HTML à une image LCP, vous pouvez voir la corrélation claire entre la longueur de la chaîne de requêtes et la LCP plus lente.

Graphique illustrant la relation entre les chaînes de requêtes dépendantes et le LCP. La LCP médiane passe de 2 150 millisecondes avec aucune requête dépendante à 2 540 millisecondes avec une requête dépendante, puis à 2 850 millisecondes avec deux requêtes dépendantes.
Lien entre les chaînes de requêtes dépendantes et le LCP.

L'essentiel est d'indiquer au navigateur dès que possible la valeur de la LCP afin qu'il puisse commencer à la charger, même avant qu'elle ne trouve sa place dans la mise en page de la page. Pour ce faire, vous pouvez utiliser plusieurs outils, comme une balise <img> classique dans le code HTML afin que le lecteur préchargé puisse la trouver rapidement et commencer à la télécharger, ou une balise <link rel="preload"> (ou un en-tête HTTP) pour les images qui ne seront pas des <img>.

Il est également important d'aider le navigateur à déterminer les ressources à prioriser. Cela est particulièrement vrai si votre page envoie de nombreuses requêtes lors du chargement. En effet, le navigateur ne sait souvent pas quel sera l'élément LCP tant que de nombreuses ressources n'ont pas été chargées et que la mise en page n'a pas eu lieu. En annotant l'élément LCP probable avec un attribut fetchpriority="high" (et en veillant à éviter loading="lazy"), le navigateur commence à charger la ressource immédiatement.

En savoir plus sur l'optimisation du délai de chargement

Délai de rendu

Le délai de rendu mesure le temps écoulé entre le moment où le navigateur a chargé et préparé l'image LCP, mais pour une raison quelconque, il y a un délai avant qu'elle ne s'affiche à l'écran. Il peut s'agir d'une tâche longue bloquant le thread principal lorsque l'image est prête, ou d'un choix d'UI pour révéler un élément masqué.

Pour l'origine typique sur le Web, il ne semble pas y avoir de réelle opportunité de retard de rendu, mais lors de l'optimisation, vous pouvez parfois créer un retard de rendu à partir du temps précédemment passé dans d'autres sous-parties. Par exemple, si une page commence à précharger l'image du LCP pour qu'elle soit disponible rapidement, le temps de chargement ne sera plus long. Toutefois, si la page elle-même n'est pas prête à afficher l'image (par exemple, en raison d'une grande feuille de style bloquant le rendu ou d'une application de rendu côté client qui doit terminer le chargement de tout son code JavaScript avant que quoi que ce soit puisse s'afficher), le LCP sera toujours plus lent que prévu, et le temps d'attente s'affichera désormais sous la forme d'un délai de rendu. C'est pourquoi le rendu côté serveur ou le code HTML statique ont souvent un avantage en termes de LCP.

Si votre propre contenu est concerné, consultez d'autres conseils pour optimiser le délai de rendu.

Cochez toutes ces sous-parties

Il est clair que pour optimiser efficacement le LCP, les développeurs doivent examiner la charge de la page de manière globale et ne pas se concentrer uniquement sur l'optimisation des images. Vérifiez chaque partie du temps avant le LCP, car il y a probablement de nombreuses possibilités d'amélioration.

Pour collecter ces données sur le terrain, la version d'attribution de la bibliothèque web-vitals inclut des délais pour les sous-parties du LCP. Le rapport d'expérience utilisateur Chrome (CrUX) n'inclut pas encore toutes ces données, mais il contient des entrées pour le TTFB et le LCP. Nous espérons pouvoir inclure les données utilisées pour cet article dans CrUX à l'avenir. Tenez-vous prêt à en savoir plus à ce sujet.

Pour tester localement les sous-composants du LCP, essayez l'extension Web Vitals ou l'extrait JavaScript de cet article. Lighthouse inclut également la répartition dans son audit "Élément identifié comme "Largest Contentful Paint"". Pour obtenir d'autres conseils sur les sous-parties du LCP, consultez le panneau "Performances" des outils de développement, qui sera bientôt disponible.