Guide par étapes expliquant comment répartir le LCP et identifier les principaux domaines à améliorer.
La métrique LCP (Largest Contentful Paint) est l'une des trois métriques du rapport Core Web Vitals. Elle représente la vitesse de chargement du contenu principal d'une page Web. Plus précisément, le LCP mesure le temps qui s'écoule entre le moment où l'utilisateur lance le chargement de la page et le moment où l'image ou le bloc de texte le plus grand s'affiche dans la fenêtre d'affichage.
Pour offrir une bonne expérience utilisateur, les sites doivent s'efforcer d'avoir un LCP de 2,5 secondes ou moins pour au moins 75% des visites de page.
Un certain nombre de facteurs peuvent avoir une incidence sur la vitesse de chargement et d'affichage d'une page Web par le navigateur. Les retards dans l'exécution de ces opérations peuvent avoir un impact significatif sur le LCP.
Il est rare qu'une correction rapide sur une seule partie d'une page entraîne une amélioration significative du LCP. Pour améliorer le LCP, vous devez examiner l'intégralité du processus de chargement et vous assurer que chaque étape est optimisée.
Comprendre votre métrique LCP
Avant d'optimiser le LCP, les développeurs doivent chercher à comprendre s'ils rencontrent un problème LCP, ainsi que l'ampleur de ce problème.
Le LCP peut être mesuré à l'aide de plusieurs outils, qui ne mesurent pas tous le LCP de la même manière. Pour comprendre le LCP des utilisateurs réels, nous devons analyser l'expérience des utilisateurs réels, plutôt que ce qu'indique un outil basé sur un laboratoire comme Lighthouse ou des tests en local. Ces outils basés sur des laboratoires peuvent fournir une mine d'informations pour expliquer et vous aider à améliorer le LCP, mais gardez à l'esprit que les tests de laboratoire ne sont pas nécessairement représentatifs de l'expérience réelle de vos utilisateurs.
Les données LCP basées sur des utilisateurs réels peuvent être obtenues à partir des outils RUM (Real User Monitoring) installés sur un site ou via le rapport d'expérience utilisateur Chrome, qui recueille des données anonymes auprès d'utilisateurs réels de Chrome pour des millions de sites Web.
Utiliser les données LCP CrUX de PageSpeed Insights
PageSpeed Insights permet d'accéder aux données CrUX dans la section supérieure intitulée Découvrez l'expérience de vos utilisateurs réels. Vous trouverez des données plus détaillées sur les ateliers dans la section du bas intitulée Diagnostiquer les problèmes de performances. Si des données CrUX sont disponibles pour votre site Web, concentrez-vous toujours sur les données utilisateur réelles.
PageSpeed Insights affiche jusqu'à quatre données CrUX différentes:
- Données mobiles pour cette URL
- Données ordinateur pour cette URL
- Données mobiles pour l'ensemble du réseau Origin
- Données Desktop pour l'ensemble de l'Origin
Vous pouvez les activer/désactiver dans les commandes situées en haut à droite de cette section. Si une URL ne dispose pas de suffisamment de données pour être affichée au niveau de l'URL, mais qu'elle dispose de données pour l'origine, PageSpeed Insights affiche toujours les données d'origine.
Le LCP pour l'ensemble de l'origine peut être très différent du LCP d'une page individuelle en fonction de la façon dont le LCP est chargé sur cette page par rapport aux autres pages de cette origine. Il peut également être influencé par la façon dont les visiteurs accèdent à ces pages. Les pages d'accueil ont tendance à être consultées par de nouveaux utilisateurs. Elles peuvent donc souvent être chargées à "froid", sans contenu mis en cache, et ce sont souvent les pages les plus lentes d'un site Web.
L'examen des quatre différentes catégories de données CrUX peut vous aider à déterminer si un problème LCP est spécifique à cette page ou s'il s'agit d'un problème plus général affectant l'ensemble du site. De même, il peut indiquer les types d'appareils présentant des problèmes LCP.
Utiliser les métriques supplémentaires CrUX de PageSpeed Insights
Si vous souhaitez optimiser le LCP, vous devez également utiliser les temps First Contentful Paint (FCP) et Time to First Byte (TTFB), qui sont de bonnes métriques de diagnostic qui fournissent de précieux insights sur le LCP.
TTFB est le moment où le visiteur commence à naviguer vers une page (par exemple, en cliquant sur un lien), jusqu'à ce que les premiers octets du document HTML soient reçus. Avec un TTFB élevé, il peut être difficile, voire impossible, d'atteindre un LCP de 2,5 secondes.
Une valeur TTFB élevée peut être due à des redirections sur plusieurs serveurs, à des visiteurs éloignés du serveur du site le plus proche, à des visiteurs dont l'état du réseau est mauvaise ou à l'impossibilité d'utiliser le contenu mis en cache en raison des paramètres de requête.
Lorsqu'une page commence à s'afficher, un dessin initial (par exemple, la couleur de l'arrière-plan) peut apparaître, suivi de certains contenus (par exemple, l'en-tête du site). L'apparence du contenu initial est mesurée par le FCP. Le delta entre le FCP et les autres métriques peut être très révélateur.
Un écart important entre le TTFB et le FCP peut indiquer que le navigateur doit télécharger de nombreux éléments qui bloquent l'affichage. Cela peut également indiquer qu'il doit effectuer un travail important pour afficher tout contenu pertinent, signe classique d'un site qui s'appuie fortement sur le rendu côté client.
Un écart important entre le FCP et le LCP indique que la ressource LCP n'est pas immédiatement disponible pour le navigateur à prioriser (par exemple, du texte ou des images qui sont gérés par JavaScript au lieu d'être disponibles dans le code HTML initial) ou que le navigateur effectue d'autres tâches avant de pouvoir afficher le contenu LCP.
Utiliser les données PageSpeed Insights Lighthouse
La section Lighthouse de PageSpeed Insights propose quelques conseils pour améliorer le LCP, mais vous devez d'abord vérifier si le LCP indiqué correspond globalement aux données utilisateur réelles fournies par CrUX. Si Lighthouse et CrUX ne sont pas d'accord, alors CrUX fournit probablement une image plus précise de votre expérience utilisateur. Assurez-vous que vos données CrUX concernent votre page, et non l'origine complète, avant d'agir dessus.
Si Lighthouse et CrUX affichent des valeurs LCP qui doivent être améliorées, la section Lighthouse peut fournir de précieux conseils pour améliorer le LCP. Utilisez le filtre LCP pour n'afficher que les audits pertinents pour le LCP comme suit:
En plus des opportunités d'amélioration, des informations sur le diagnostic peuvent vous aider à diagnostiquer le problème. Le diagnostic de l'élément Largest Contentful Paint affiche une analyse utile des différentes durées composant le LCP:
Nous les étudierons plus en détail par la suite.
Répartition du LCP
L'optimisation du LCP peut s'avérer plus complexe lorsque PageSpeed Insights ne vous permet pas de savoir comment améliorer cette métrique. Dans le cas de tâches complexes, il est généralement préférable de les décomposer en tâches plus petites et plus faciles à gérer, et de les traiter séparément.
Cette section présente une méthodologie permettant de diviser le LCP en sous-parties les plus critiques, puis de présenter des recommandations spécifiques et les bonnes pratiques d'optimisation de chaque partie.
La plupart des chargements de page incluent généralement un certain nombre de requêtes réseau. Toutefois, afin d'identifier les opportunités d'amélioration du LCP, nous vous recommandons de commencer par examiner deux éléments:
- Le document HTML initial
- Ressource LCP (le cas échéant)
Bien que les autres demandes sur la page puissent avoir un impact sur le LCP, ces deux requêtes (en particulier les heures de début et de fin de la ressource LCP) indiquent si votre page est optimisée ou non pour le LCP.
Pour identifier la ressource LCP, vous pouvez utiliser des outils pour les développeurs (tels que PageSpeed Insights décrits ci-dessus, Chrome DevTools ou WebPageTest) afin de déterminer l'élément LCP. Vous pouvez alors faire correspondre l'URL (une nouvelle fois, le cas échéant) chargée par l'élément sur une cascade d'annonces réseau de toutes les ressources chargées par la page.
Par exemple, la visualisation suivante montre ces ressources mises en évidence sur un diagramme de cascade réseau à partir d'un chargement de page classique, où l'élément LCP nécessite une requête d'image pour s'afficher.
Pour une page bien optimisée, votre demande de ressource LCP doit commencer à se charger le plus tôt possible et l'élément LCP doit s'afficher le plus rapidement possible une fois le chargement de la ressource LCP terminé. Pour vous aider à visualiser si une page spécifique suit ou non ce principe, vous pouvez décomposer le temps LCP total en sous-parties suivantes:
- Temps de latence du premier octet (TTFB)
- Délai entre le moment où l'utilisateur lance le chargement de la page et le moment où le navigateur reçoit le premier octet de la réponse du document HTML.
- Délai de chargement des ressources
- Délai entre la valeur TTFB et le moment où le navigateur commence à charger la ressource LCP. Si l'élément LCP ne nécessite pas de charge de ressources pour s'afficher (par exemple, si l'élément est un nœud de texte affiché avec une police système), cette valeur est de 0.
- Durée de chargement des ressources
- Temps nécessaire pour charger 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 de 0.
- Délai d'affichage de l'élément
- Délai entre la fin du chargement de la ressource LCP et l'affichage complet de l'élément LCP.
Le LCP de chaque page se compose de ces quatre sous-catégories. Il n'y a pas d'écart ou de chevauchement entre eux, et leur somme correspond au temps LCP complet.
La valeur LCP de chaque page peut être décomposée en quatre sous-parties. Il n'y a pas de chevauchement ni d'écart entre les deux. Collectivement, leur somme correspond au temps LCP complet.
Lorsque vous optimisez le LCP, il est utile d'essayer d'optimiser individuellement ces sous-parties. Mais n'oubliez pas que vous devez toutes les optimiser. Dans certains cas, une optimisation appliquée à une partie n'améliore pas le LCP. Elle déplace simplement le temps gagné sur une autre partie.
Par exemple, dans la cascade réseau précédente, si vous réduisez la taille du fichier de notre image en la compressant davantage ou en choisissant un format plus optimal (par exemple, AVIF ou WebP), cela réduirait la durée de chargement des ressources, mais cela n'améliorerait pas le LCP, car le temps passerait simplement à la sous-partie Délai d'affichage de l'élément:
En effet, sur cette page, l'élément LCP est masqué jusqu'à la fin du chargement du code JavaScript, puis tout est révélé en une seule fois.
Cet exemple illustre bien le besoin d'optimiser toutes ces sous-parties pour obtenir les meilleurs résultats LCP.
Durée optimale des sous-parties
Afin d'optimiser chaque sous-partie du LCP, il est important de comprendre quelle est la répartition idéale de ces sous-parties sur une page bien optimisée.
Des quatre sous-parties, deux contiennent le mot « retard » dans leur nom. C'est un indice que vous devez obtenir un nombre aussi proche de zéro que possible. Les deux autres parties concernent les requêtes réseau qui, de par leur nature, prennent du temps.
Notez que ces répartitions du temps sont fournies à titre indicatif, et non à des règles strictes. Si les durées LCP de vos pages sont systématiquement à 2,5 secondes, les proportions relatives n'ont pas d'importance. Toutefois, si vous passez beaucoup de temps inutile dans l'une des parties "retardées", il sera très difficile d'atteindre en permanence l'objectif de 2,5 secondes.
Voici une bonne façon de considérer la répartition du temps LCP:
- La grande majorité du temps LCP doit être consacrée au chargement du document HTML et de la source LCP.
- Avant le LCP, chaque fois que l'une de ces deux ressources ne se charge pas, vous pouvez s'améliorer.
Comment optimiser chaque élément
Maintenant que vous comprenez comment chaque sous-partie du LCP doit se répartir sur une page bien optimisée, vous pouvez commencer à optimiser vos propres pages.
Les quatre sections suivantes présentent des recommandations et des bonnes pratiques pour optimiser chaque partie. Elles sont présentées dans l'ordre, en commençant par les optimisations susceptibles d'avoir le plus d'impact.
1. Éliminer les délais de chargement des ressources
L'objectif de cette étape est de s'assurer que le chargement de la ressource LCP commence le plus tôt possible. En théorie, le chargement d'une ressource au plus tôt pouvait se lancer immédiatement après le TTFB, mais en pratique, il y a toujours un certain délai avant que les navigateurs ne commencent réellement à charger des ressources.
En règle générale, le chargement de votre ressource LCP doit commencer en même temps que celui de la première ressource chargée par cette page. Autrement dit, si la ressource LCP commence à se charger plus tard que la première, il existe une possibilité d'amélioration.
En règle générale, deux facteurs ont une incidence sur la vitesse de chargement d'une ressource LCP:
- le moment où la ressource est découverte ;
- Priorité accordée à la ressource
Optimiser le moment où la ressource est découverte
Pour que votre ressource LCP se charge le plus tôt possible, il est essentiel qu'elle soit visible dans la réponse du document HTML initial par l'outil d'analyse de préchargement du navigateur. Par exemple, dans les cas suivants, le navigateur peut découvrir la ressource LCP en analysant la réponse du document HTML:
- L'élément LCP est un élément
<img>, et ses attributssrcousrcsetsont présents dans le balisage HTML initial. - L'élément LCP nécessite une image de fond CSS, mais cette image est préchargée à l'aide de
<link rel="preload">dans le balisage HTML (ou d'un en-têteLink). - L'élément LCP est un nœud de texte qui nécessite une police Web pour s'afficher. Cette police est chargée à l'aide de
<link rel="preload">dans le balisage HTML (ou d'un en-têteLink).
Voici quelques exemples où la ressource LCP ne peut pas être découverte à partir de l'analyse de la réponse du document HTML:
- L'élément LCP est un élément
<img>ajouté de façon dynamique à la page à l'aide de JavaScript. - L'élément LCP est chargé de manière différée avec une bibliothèque JavaScript qui masque ses attributs
srcousrcset(souventdata-srcoudata-srcset). - L'élément LCP nécessite une image de fond CSS.
Dans chacun de ces cas, le navigateur doit exécuter le script ou appliquer la feuille de style (ce qui implique généralement d'attendre la fin des requêtes réseau) avant de pouvoir détecter la ressource LCP et commencer à la charger. Ce n'est jamais optimal.
Pour éliminer tout délai inutile de chargement des ressources, votre ressource LCP doit être visible à partir du code source HTML. Si la ressource n'est référencée qu'à partir d'un fichier CSS ou JavaScript externe, la ressource LCP doit être préchargée avec une priorité d'extraction élevée, par exemple:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
Optimiser la priorité accordée à la ressource
Même si la ressource LCP est visible à partir du balisage HTML, il est possible qu'elle ne commence toujours pas à se charger dès la première ressource. Cela peut se produire si l'heuristique de priorité de l'outil d'analyse de préchargement du navigateur ne reconnaît pas l'importance de la ressource, ou s'il détermine que d'autres ressources sont plus importantes.
Par exemple, vous pouvez retarder l'image LCP à l'aide de HTML si vous définissez loading="lazy" sur l'élément <img>. Si vous utilisez le chargement différé, la ressource ne sera pas chargée tant que la mise en page n'aura pas confirmé que l'image se trouve dans la fenêtre d'affichage. Le chargement peut donc commencer plus tard qu'auparavant.
Même sans chargement différé, les images ne sont pas initialement chargées avec la priorité la plus élevée par les navigateurs, car ce ne sont pas des ressources qui bloquent l'affichage. L'attribut fetchpriority vous permet d'indiquer au navigateur les ressources qui pourraient bénéficier d'une priorité plus élevée:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Nous vous recommandons de définir fetchpriority="high" sur un élément <img> si vous pensez qu'il s'agit probablement de l'élément LCP de votre page. Toutefois, le fait de définir une priorité élevée sur plusieurs images ou deux rend le paramétrage de la priorité inutile pour réduire le LCP.
Vous pouvez également réduire la priorité des images qui se trouvent peut-être au début de la réponse du document, mais qui ne sont pas visibles en raison de leur style, comme les images des diapositives de carrousel qui ne sont pas visibles au démarrage:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
Si vous dépriorisez certaines ressources, vous pouvez accorder plus de bande passante aux ressources qui en ont le plus besoin, mais faites attention. Vérifiez toujours la priorité des ressources dans les outils de développement et testez les modifications à l'aide des outils d'atelier et de terrain.
Une fois que vous avez optimisé la priorité et le délai de découverte de votre ressource LCP, votre cascade réseau devrait se présenter comme suit (la ressource LCP commençant en même temps que la première ressource):
2. Élimination du délai d'affichage de l'élément
L'objectif de cette étape est de s'assurer que l'élément LCP peut s'afficher immédiatement après le chargement de sa ressource, quoi qu'il arrive.
La principale raison pour laquelle l'élément LCP ne peut pas s'afficher immédiatement après le chargement de sa ressource est que l'affichage est bloqué pour une autre raison:
- L'affichage de la page entière est bloqué en raison de feuilles de style ou de scripts synchrones dans
<head>qui sont toujours en cours de chargement. - Le chargement de la ressource LCP est terminé, mais l'élément LCP n'a pas encore été ajouté au DOM (il attend le chargement d'un code JavaScript).
- L'élément est masqué par un autre code, comme une bibliothèque de tests A/B qui détermine encore le test auquel l'utilisateur devrait participer.
- Le thread principal est bloqué en raison de longues tâches, et l'affichage doit attendre qu'elles soient terminées.
Les sections suivantes expliquent comment résoudre les causes les plus courantes de retard d'affichage inutile des éléments.
Réduire ou intégrer les feuilles de style bloquant l'affichage
Les feuilles de style chargées à partir du balisage HTML bloquent l'affichage de tout le contenu qui les suit, ce qui est une bonne chose, car vous ne souhaitez généralement pas afficher du code HTML sans style. Toutefois, si la feuille de style est si grande qu'elle met beaucoup plus de temps à se charger que la ressource LCP, elle empêche l'affichage de l'élément LCP, même après le chargement de sa ressource, comme illustré dans cet exemple:
Pour résoudre ce problème, vous avez le choix entre les options suivantes:
- d'intégrer la feuille de style dans le code HTML pour éviter toute demande réseau supplémentaire ;
- réduire la taille de la feuille de style.
En général, l'intégration de votre feuille de style n'est recommandée que si elle est petite, car le contenu intégré dans le code HTML ne peut pas bénéficier de la mise en cache lors des chargements de page suivants. Si une feuille de style est si grande que son chargement prend plus de temps que la ressource LCP, il est peu probable qu'elle soit adaptée à l'intégration.
Dans la plupart des cas, le meilleur moyen de s'assurer que la feuille de style ne bloque pas l'affichage de l'élément LCP est de réduire sa taille afin qu'elle soit inférieure à la ressource LCP. Cela devrait permettre de s'assurer qu'il ne s'agit pas d'un goulot d'étranglement pour la plupart des visites.
Voici quelques recommandations pour réduire la taille de la feuille de style:
- Supprimer les ressources CSS inutilisées: utilisez les outils pour les développeurs Chrome pour identifier les règles CSS qui ne sont pas utilisées et qui peuvent être supprimées (ou différées).
- Différer les fichiers CSS non critiques : divisez votre feuille de style en deux catégories : requis pour le chargement initial de la page, puis styles pouvant être chargés en différé.
- Réduisez et compressez les fichiers CSS: pour les styles essentiels, veillez à réduire autant que possible leur taille de transfert.
Reporter ou intégrer le code JavaScript bloquant l'affichage
Il n'est presque jamais nécessaire d'ajouter des scripts synchrones (sans les attributs async ou defer) à l'élément <head> de vos pages, car cela a presque toujours un impact négatif sur les performances.
Si le code JavaScript doit s'exécuter le plus tôt possible au cours du chargement de la page, il est préférable de l'intégrer afin de ne pas retarder l'affichage en attendant une autre requête réseau. Comme pour les feuilles de style, n'intégrez des scripts que s'ils sont très petits.
<head> <script src="/path/to/main.js"></script> </head>
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>
Utiliser le rendu côté serveur
L'affichage côté serveur consiste à exécuter votre logique d'application côté client sur le serveur et à répondre aux demandes de document HTML avec le balisage HTML complet.
Du point de vue de l'optimisation du LCP, la fonctionnalité SSR présente deux avantages principaux:
- Vos ressources d'image seront visibles à partir du code source HTML (comme indiqué à l'étape 1).
- Le contenu de votre page ne nécessitera pas de requêtes JavaScript supplémentaires avant de pouvoir s'afficher.
Le principal inconvénient de la restauration SSR est qu'elle nécessite un temps de traitement supplémentaire sur le serveur, ce qui peut ralentir votre TTFB. Toutefois, ce compromis en vaut généralement la peine, car vous contrôlez les temps de traitement du serveur, contrairement aux capacités du réseau et des appareils de vos utilisateurs.
Une option semblable à la fonctionnalité SSR est appelée génération de site statique (SSG) ou prérendu. Le processus consiste à générer vos pages HTML au cours d'une étape de compilation plutôt qu'à la demande. Si le prérendu est possible avec votre architecture, il s'agit généralement d'un meilleur choix en termes de performances.
Divisez les longues tâches
Même si vous avez suivi les conseils précédents et que votre code JavaScript ne bloque pas l'affichage et n'est pas responsable de l'affichage de vos éléments, il peut toujours retarder le LCP.
Le plus souvent, cela se produit lorsque les pages chargent des fichiers JavaScript volumineux, qui doivent être analysés et exécutés sur le thread principal du navigateur. Cela signifie que, même si votre ressource d'image est entièrement téléchargée, il se peut qu'elle doive attendre la fin de l'exécution d'un script sans rapport avant de pouvoir s'afficher.
Aujourd'hui, tous les navigateurs affichent les images sur le thread principal. Par conséquent, tout ce qui bloque le thread principal peut également entraîner un délai d'affichage de l'élément inutile.
3. Réduire la durée de chargement des ressources
L'objectif de cette étape est de réduire le temps passé à transférer les octets de la ressource sur le réseau vers l'appareil de l'utilisateur. En règle générale, vous pouvez procéder de trois façons:
- Réduisez la taille de la ressource.
- Réduisez la distance que la ressource doit parcourir.
- Réduisez les conflits pour la bande passante réseau.
- Éliminer complètement le temps consacré au réseau
Réduire la taille de la ressource
La ressource LCP d'une page (si elle en possède une) sera une image ou une police Web. Les guides suivants expliquent en détail comment réduire la taille des deux éléments:
- Diffuser une image de taille optimale
- Utiliser des formats d'image modernes
- Compresser les images
- Réduire la taille de la police Web
Réduire la distance que la ressource doit parcourir
En plus de réduire la taille d'une ressource, vous pouvez également réduire les temps de chargement en rapprochant géographiquement vos serveurs de vos utilisateurs. Le meilleur moyen d'y parvenir est d'utiliser un réseau de diffusion de contenu (CDN).
Les CDN d'images sont particulièrement utiles, car non seulement ils réduisent la distance que doit parcourir la ressource, mais ils réduisent également généralement la taille de la ressource. Ils appliquent automatiquement toutes les recommandations de réduction de taille que nous vous avons faites précédemment.
Réduire les conflits pour la bande passante réseau
Même si vous avez réduit la taille de votre ressource et la distance qu'elle doit parcourir, le chargement d'une ressource peut prendre beaucoup de temps si vous chargez de nombreuses autres ressources en même temps. Ce problème est connu sous le nom de conflit de réseau.
Si vous avez attribué un fetchpriority élevé à votre ressource LCP et que vous avez commencé à la charger dès que possible, le navigateur fera de son mieux pour éviter que les ressources de priorité inférieure ne lui concurrencent. Toutefois, si vous chargez de nombreuses ressources avec un fetchpriority élevé, ou si vous ne chargez qu'un grand nombre de ressources en général, cela peut affecter la vitesse de chargement de la ressource LCP.
Éliminer complètement le temps d'utilisation du réseau
Le meilleur moyen de réduire la durée de chargement des ressources consiste à éliminer entièrement le réseau du processus. Si vous diffusez vos ressources à l'aide d'une règle efficace de contrôle du cache, les visiteurs qui les demandent une deuxième fois verront celles-ci diffusées à partir du cache, mettant ainsi la durée de chargement des ressources à zéro.
Si votre ressource LCP est une police Web, en plus de réduire la taille de cette police, vous devez également déterminer si vous devez bloquer l'affichage sur le chargement de la ressource de police Web. Si vous définissez une valeur font-display autre que auto ou block, le texte sera toujours visible pendant le chargement et le LCP ne sera pas bloqué pour une requête réseau supplémentaire.
Enfin, si votre ressource LCP est petite, il peut être judicieux d'intégrer les ressources en tant qu'URL de données, ce qui supprimera également la requête réseau supplémentaire. Toutefois, l'utilisation d'URL de données présente des mises en garde, car les ressources ne peuvent alors pas être mises en cache et, dans certains cas, les délais d'affichage peuvent être plus longs en raison du coût de décodage supplémentaire.
4. Réduire le temps de latence du premier octet
L'objectif de cette étape est de livrer le code HTML initial le plus rapidement possible. Cette étape apparaît en dernier, car il s'agit souvent de celle sur laquelle les développeurs ont le moins de contrôle. Cependant, il s'agit également de l'une des étapes les plus importantes, car elle affecte directement chaque étape qui la suit. Rien ne peut se produire sur l'interface tant que le backend n'a pas fourni le premier octet de contenu. Par conséquent, tout ce que vous pouvez faire pour accélérer votre TTFB améliorera également toutes les autres métriques de charge.
Si le TTFB est lent sur un site autrement rapide, cela est souvent dû au fait que les visiteurs accèdent à votre site via plusieurs redirections, par exemple à partir de publicités ou de liens courts. Réduisez toujours au minimum le nombre de redirections qu'un visiteur doit attendre.
Autre cause fréquente : le contenu mis en cache ne peut pas être utilisé à partir d'un serveur de périphérie CDN et toutes les requêtes doivent être redirigées vers le serveur d'origine. Cela peut se produire si les visiteurs utilisent des paramètres d'URL uniques à des fins d'analyse, même s'ils ne génèrent pas de pages différentes.
Pour obtenir des conseils spécifiques sur l'optimisation du TTFB, consultez le guide "Optimiser le TTFB".
Surveiller la répartition du LCP en JavaScript
Les informations temporelles de toutes les sous-parties LCP décrites précédemment sont disponibles dans JavaScript via une combinaison des API de performances suivantes:
Le calcul de ces valeurs temporelles en JavaScript présente l'avantage de vous permettre de les envoyer à un fournisseur de solutions d'analyse ou de les enregistrer dans vos outils de développement afin de faciliter le débogage et l'optimisation.
Par exemple, la capture d'écran suivante utilise la méthode performance.measure() de l'API User Timing pour ajouter des barres à la piste "Timing" dans le panneau "Performances" des outils pour les développeurs Chrome.
Les visualisations du canal Durée sont particulièrement utiles lorsqu'on les compare aux pistes Réseau et Thread principal, car elles permettent de voir d'un seul coup d'œil ce qui se passe sur la page au cours de ces périodes.
En plus de visualiser les sous-parties du LCP dans le suivi des durées, vous pouvez également utiliser JavaScript pour calculer le pourcentage de chaque sous-partie par rapport à la durée totale du LCP. Grâce à ces informations, vous pouvez déterminer si vos pages respectent les répartitions en pourcentage recommandées décrites précédemment.
Cette capture d'écran montre un exemple qui consigne dans la console le temps total de chaque sous-partie LCP, ainsi que son pourcentage du temps LCP total.
Ces deux visualisations ont été créées avec le code suivant:
const LCP_SUB_PARTS = [
'Time to first byte',
'Resource load delay',
'Resource load duration',
'Element render delay',
];
new PerformanceObserver((list) => {
const lcpEntry = list.getEntries().at(-1);
const navEntry = performance.getEntriesByType('navigation')[0];
const lcpResEntry = performance
.getEntriesByType('resource')
.filter((e) => e.name === lcpEntry.url)[0];
// Ignore LCP entries that aren't images to reduce DevTools noise.
// Comment this line out if you want to include text entries.
if (!lcpEntry.url) return;
// Compute the start and end times of each LCP sub-part.
// WARNING! If your LCP resource is loaded cross-origin, make sure to add
// the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
const ttfb = navEntry.responseStart;
const lcpRequestStart = Math.max(
ttfb,
// Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
);
const lcpResponseEnd = Math.max(
lcpRequestStart,
lcpResEntry ? lcpResEntry.responseEnd : 0
);
const lcpRenderTime = Math.max(
lcpResponseEnd,
// Use LCP startTime (the final LCP time) because there are sometimes
// slight differences between loadTime/renderTime and startTime
// due to rounding precision.
lcpEntry ? lcpEntry.startTime : 0
);
// Clear previous measures before making new ones.
// Note: due to a bug, this doesn't work in Chrome DevTools.
LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));
// Create measures for each LCP sub-part for easier
// visualization in the Chrome DevTools Performance panel.
const lcpSubPartMeasures = [
performance.measure(LCP_SUB_PARTS[0], {
start: 0,
end: ttfb,
}),
performance.measure(LCP_SUB_PARTS[1], {
start: ttfb,
end: lcpRequestStart,
}),
performance.measure(LCP_SUB_PARTS[2], {
start: lcpRequestStart,
end: lcpResponseEnd,
}),
performance.measure(LCP_SUB_PARTS[3], {
start: lcpResponseEnd,
end: lcpRenderTime,
}),
];
// Log helpful debug information to the console.
console.log('LCP value: ', lcpRenderTime);
console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
console.table(
lcpSubPartMeasures.map((measure) => ({
'LCP sub-part': measure.name,
'Time (ms)': measure.duration,
'% of LCP': `${
Math.round((1000 * measure.duration) / lcpRenderTime) / 10
}%`,
}))
);
}).observe({type: 'largest-contentful-paint', buffered: true});
Vous pouvez utiliser ce code tel quel pour le débogage local, ou le modifier pour envoyer ces données à un fournisseur de solutions d'analyse. Vous pourrez ainsi mieux comprendre la répartition du LCP sur vos pages pour les utilisateurs réels.
Surveiller les répartitions LCP à l'aide de l'extension Web Vitals
L'extension Web Vitals enregistrera l'heure du LCP, l'élément LCP et ces quatre sous-parties dans la console pour vous permettre de consulter facilement cette répartition.
Résumé
Le LCP est complexe et sa chronologie peut être affectée par un certain nombre de facteurs. Mais si vous considérez que l'optimisation du LCP consiste principalement à optimiser la charge de la ressource LCP, cela peut considérablement simplifier les choses.
De manière générale, l'optimisation du LCP se résume en quatre étapes:
- Assurez-vous que le chargement de la ressource LCP commence le plus tôt possible.
- Assurez-vous que l'élément LCP peut s'afficher dès la fin du chargement de sa ressource.
- Réduisez autant que possible le temps de chargement de la ressource LCP sans compromettre la qualité.
- Envoyez le document HTML initial aussi rapidement que possible.
Si vous êtes en mesure de suivre ces étapes sur vos pages, vous devriez alors être sûr d'offrir à vos utilisateurs une expérience de chargement optimale. Cela devrait se refléter dans vos scores LCP réels.