L'amélioration de la Largest Contentful Paint (LCP) d'une page peut être compliquée, car elle implique souvent plusieurs parties mobiles et des compromis. Cet article s'intéresse aux données réelles issues des chargements de pages réelles sur le Web afin de déterminer où les développeurs doivent concentrer leurs efforts d'optimisation.
Conseil LCP classique: réduisez la taille de vos images.
Pour la plupart des pages sur le Web, l'élément LCP est une image. Il est alors naturel de supposer que le meilleur moyen d'améliorer le LCP est d'optimiser votre image LCP.
Il y a environ cinq ans après l'introduction du LCP, cet indicateur était souvent le principal conseil. Assurez-vous que vos images sont à la bonne taille et suffisamment compressées. Si possible, utilisez un format d'image du XXIe siècle. Lighthouse propose même trois audits différents pour proposer ces suggestions.
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">Cela s'explique en partie par le fait que le nombre excessif d'octets est facile à mesurer et que les outils de compression d'image sont faciles à suggérer. En fonction de vos pipelines de compilation et de déploiement, l'implémentation peut également être facile.
Si c'est le cas, faites-le ! Envoyer moins d'octets à vos utilisateurs est presque toujours une victoire. De nombreux sites sur le Web diffusent toujours des images inutilement volumineuses que même une compression de base permet de résoudre.
Toutefois, lorsque nous avons commencé à examiner les données de performances réelles pour les utilisateurs dans Chrome afin de déterminer à quoi servent généralement le LCP, nous avons constaté que le temps de téléchargement des images n'est presque jamais le goulot d'étranglement.
Au contraire, d'autres parties du LCP sont un problème beaucoup plus important.
Répartition des sous-parties du LCP
Pour identifier les principales 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 devient l'élément LCP de la page, chacun d'eux peut être divisé en plusieurs sous-parties:
Citation de cet article, les sous-parties sont les suivantes:
- Temps de latence du premier octet (TTFB)
- Délai entre le moment où l'utilisateur commence à charger la page et celui où le navigateur reçoit le premier octet de la réponse du document HTML.
- Délai de chargement des ressources
- Délai 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 ressource pour s'afficher, cette fois
0. - Durée de chargement des ressources
- Temps nécessaire pour charger la ressource LCP elle-même. Si le LCP
ne nécessite pas de chargement de ressource pour s'afficher (cette fois :
0). - Délai d'affichage des éléments
- Délai entre le chargement de la ressource LCP et l'élément LCP le rendu complet.
Données sur les performances réelles de la navigation
| Classification LCP | TTFB (ms) | Délai de chargement de l'image (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 page avec un LCP d'image de sous-ressource dans Chrome afin d'examiner les sous-parties du LCP. Nous avons déjà examiné ce type de données, mais jamais à partir de données réelles pour voir où les utilisateurs réels passent leur temps en attendant le LCP d'une page.
<ph type="x-smartling-placeholder">Comme pour le rapport Core Web Vitals, nous avons pris le 75e centile (p75) de chaque sous-partie LCP pour chaque origine dans l'ensemble de données CrUX, ce qui donne quatre distributions de valeurs p75 (une pour chaque sous-partie). Pour résumer ces distributions, nous avons pris la médiane de ces valeurs sur toutes les origines pour chacune des quatre sous-parties du LCP.
Enfin, nous répartissons les origines en buckets selon qu'elles ont une bonne", "améliorée nécessaire" ou "médiocre" Le LCP au 75e centile. Cela permet de mettre en évidence ce qui distingue une origine avec un LCP bon d'une origine avec un LCP faible.
Réduire la taille de votre image LCP ? Cette fois avec les données
La durée de chargement est la mesure du temps nécessaire pour récupérer la ressource LCP, dans ce cas, une image. Ce temps est généralement proportionnel au nombre d'octets de l'image, d'où tous les conseils de performance visant à réduire ce nombre d'octets.
Si l'on considère la progression du temps dans les graphiques précédents, on remarque qu'il n'y a pas beaucoup de temps consacré au chargement de l'image. En fait, il s'agit de la sous-partie LCP la plus courte, parmi tous les buckets LCP. La durée de chargement est plus longue pour les origines avec un LCP faible par rapport aux origines avec un LCP correct, mais ce n'est toujours pas là que le temps est largement consacré.
La majorité des personnes d'origine dont le LCP est faible passent moins de 10% de leur temps au LCP au LCP p75 à télécharger l'image du LCP.
Oui, vous devez vous assurer que vos images sont optimisées, mais ce n'est qu'un aspect de l'amélioration du LCP. Ces données montrent clairement que, pour l'origine typique sur le Web, les gains potentiels en millisecondes pour le LCP global sont faibles, quelle que soit la complexité du schéma de compression.
<ph type="x-smartling-placeholder">Dernière surprise: la lenteur de chargement était autrefois généralement attribuée aux appareils mobiles et à la qualité des réseaux mobiles. On aurait pu s'attendre à ce qu'un téléphone standard mette plusieurs fois plus de temps à télécharger la même image qu'un ordinateur de bureau avec une connexion filaire. Les données suggèrent que ce n'est plus le cas. Pour les origines dont le LCP est faible, le chargement des images au format p75 est 20% plus lent sur mobile que sur ordinateur.
Temps de latence du premier octet (TTFB)
Pour les navigations qui effectuent une requête réseau, le TTFB prendra toujours un certain temps. Il faut du temps pour effectuer une résolution DNS et démarrer une connexion. Et la physique est inégalée: une requête doit traverser le monde réel via des câbles et des câbles optiques pour atteindre un serveur, puis la réponse doit faire un retour en arrière. Même l'origine médiane présentant un bon LCP passe plus d'une demi-seconde sur le TTFB à son 75e centile.
Cependant, la disparité du TTFB entre les origines LCP bonnes et mauvaises indique une possibilité d'amélioration. Pour au moins la moitié des origines dont le LCP est faible, le TTFB p75 de 2 270 millisecondes à lui seul garantit presque que le LCP de p75 ne peut pas être plus rapide que le LCP de 2,5 secondes de sécurité. Même une réduction modérée en pourcentage de ce temps signifierait une amélioration significative du LCP.
Vous ne serez peut-être pas capable de battre la physique, mais il y a des choses qui peuvent être faites. Par exemple, si vos utilisateurs se trouvent souvent dans un emplacement très différent de celui de vos serveurs, un CDN peut permettre de rapprocher votre contenu d'eux.
Pour en savoir plus, consultez le guide sur l'optimisation de la TTFB.
Le retard de chargement des ressources, le coupable LCP lent négligé
Si le TTFB peut être amélioré, mais que les améliorations sont liées par la physique, le délai de chargement des ressources peut potentiellement être éliminé, car en pratique uniquement lié à votre architecture d'inférence.
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 sommes concentrés sur le temps nécessaire pour télécharger des images LCP, mais nous avons souvent ignoré le temps perdu avant même de demander au navigateur de lancer le téléchargement.
Le site médian dont le LCP est médiocre passe près de quatre fois plus de temps à télécharger l'image LCP qu'à le télécharger, soit 1,3 seconde entre le TTFB et la demande d'image. Cela représente plus de la moitié du budget LCP de 2,5 secondes consacré à une seule sous-partie.
Les chaînes de dépendances sont une cause fréquente de longs délais de chargement. Plus simplement, 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 devient le LCP. Toutes ces étapes doivent être effectuées avant même que le navigateur ne commence à télécharger l'image LCP.
à l'aide des données d'exploration publique des archives HTTP, qui enregistrent l'"initiateur" ; de requêtes réseau du document HTML vers une image LCP, vous pouvez voir la corrélation évidente entre la longueur de la chaîne de requêtes et le LCP plus lent.
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">L'essentiel est d'indiquer au navigateur le LCP dès que possible afin qu'il puisse commencer à le charger, avant même qu'il ne soit placé dans la mise en page. Pour cela, il existe quelques outils, tels qu'une balise <img> classique dans le code HTML afin que l'outil d'analyse du préchargement puisse la trouver rapidement et commencer à la télécharger, ou un tag <link rel="preload"> (ou un en-tête HTTP) pour les images qui ne sont pas de type <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 de la page, car le navigateur ne sait souvent pas quel sera l'élément LCP avant le chargement de la plupart de ces ressources et la mise en page. En annotant l'élément LCP probable avec un attribut fetchpriority="high" (et en veillant à éviter loading="lazy"), le navigateur indique clairement au navigateur qu'il doit commencer à charger la ressource immédiatement.
Découvrez d'autres conseils sur l'optimisation des délais de chargement.
Délai d'affichage
Le délai d'affichage mesure le temps écoulé entre le moment où l'image LCP est chargée et prête dans le navigateur. Cependant, pour une raison quelconque, l'affichage de l'image à l'écran prend un certain temps. Parfois, il s'agit d'une longue tâche qui bloque le thread principal lorsque l'image est prête. Dans d'autres cas, il peut s'agir d'un choix d'UI pour révéler un élément caché.
Pour l'origine typique sur le Web, il ne semble pas s'agir d'une opportunité de délai d'affichage énorme. Toutefois, lors de l'optimisation, vous pouvez parfois créer un délai d'affichage par rapport au temps passé précédemment dans d'autres sous-parties. Par exemple, si une page commence à précharger l'image LCP afin qu'elle soit disponible rapidement, le délai de chargement ne sera plus long, mais si la page elle-même n'est pas prête à afficher l'image (par exemple, à partir d'une grande feuille de style bloquant l'affichage ou d'une application de rendu côté client qui doit terminer le chargement de tout son code JavaScript avant que tout ne puisse s'afficher), le LCP sera toujours plus lent qu'il ne devrait l'être, et le temps d'attente sera affiché sous forme de délai d'affichage. C'est pourquoi le rendu côté serveur ou le code HTML statique présentent souvent un avantage en termes de LCP.
Si votre propre contenu est concerné, découvrez d'autres conseils sur l'optimisation du délai d'affichage.
Vérifiez toutes ces sous-parties
Il est clair que pour optimiser efficacement le LCP, les développeurs doivent examiner le chargement de la page de manière globale, et pas seulement se concentrer sur l'optimisation des images. Vérifiez chaque fois que vous souhaitez obtenir le LCP, car les opportunités d'amélioration sont probablement beaucoup plus importantes.
Pour collecter ces données sur le terrain, le build d'attribution de la bibliothèque web-vitals inclut les codes temporels des sous-parties du LCP. Le rapport d'expérience utilisateur Chrome n'inclut pas encore toutes ces données, mais il comporte des entrées pour le TTFB et le LCP. C'est donc un début. Nous espérons inclure les données utilisées pour cet article dans CrUX à l'avenir. Nous vous communiquerons prochainement plus d'informations à ce sujet.
Pour tester en local les sous-parties LCP, essayez l'extension Web Vitals ou l'extrait JavaScript de cet article. Lighthouse inclut également la répartition dans son élément "Largest Contentful Paint" audit. Vous trouverez d'autres conseils concernant le LCP dans le panneau "Performances" des outils de développement (bientôt disponible).