Guide par étapes expliquant comment décomposer le LCP et identifier les principaux domaines à améliorer.
Publié le 30 avril 2020
Le Largest Contentful Paint (LCP) est l'une des trois métriques Core Web Vitals. Il indique la rapidité avec laquelle le contenu principal d'une page Web est chargé. Plus précisément, le LCP mesure le temps écoulé entre le moment où l'utilisateur commence à charger la page et l'affichage de l'image ou du bloc de texte le plus grand dans la fenêtre d'affichage.
Afin d'offrir une expérience utilisateur de qualité, les sites doivent s'efforcer de présenter un LCP de 2,5 secondes ou moins pour au moins 75% des visites de page.
Plusieurs facteurs peuvent affecter la vitesse à laquelle le navigateur peut charger et afficher une page Web. Les retards sur chacun d'eux peuvent avoir un impact significatif sur le LCP.
Il est rare qu'une petite correction sur une seule partie d'une page améliore sensiblement le LCP. Pour améliorer le LCP, vous devez examiner l'ensemble 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 déterminer s'ils ont un problème de LCP et l'étendue de ce problème.
Le LCP peut être mesuré dans plusieurs outils, et tous ne le mesurent pas de la même manière. Pour comprendre le LCP des utilisateurs réels, nous devons examiner ce qu'ont vécu ces utilisateurs réels plutôt que les résultats obtenus à l'aide d'un outil en laboratoire comme Lighthouse ou des tests en local. Ces outils en laboratoire peuvent fournir une mine d'informations pour vous expliquer et vous aider à améliorer le LCP. Toutefois, sachez que les tests en laboratoire ne sont pas toujours entièrement représentatifs de l'expérience de vos utilisateurs réels.
Les données LCP basées sur des utilisateurs réels peuvent être obtenues à partir d'outils de surveillance des utilisateurs réels (RUM) installés sur un site ou à l'aide du rapport d'expérience utilisateur Chrome (CrUX), qui collecte des données anonymes auprès d'utilisateurs Chrome réels pour des millions de sites Web.
Utiliser les données LCP CrUX des outils pour les développeurs Chrome
Le panneau "Performances" des outils pour les développeurs Chrome affiche votre expérience LCP locale à côté de la LCP CrUX de la page ou de l'origine dans la vue des métriques en direct.
En superposant des données de champ au panneau "Performances", vous pouvez évaluer si une page présente des problèmes de LCP pour les utilisateurs réels et adapter les paramètres de votre environnement local pour mieux reproduire et déboguer ces problèmes.
Utiliser les données LCP CrUX de PageSpeed Insights
L'outil PageSpeed Insights vous permet d'accéder aux données d'expérience utilisateur Chrome (CrUX) dans la section supérieure intitulée Découvrez ce que vivent vos utilisateurs réels. Des données de laboratoire plus détaillées sont disponibles dans la section inférieure intitulée Diagnostiquer les problèmes de performances. Si des données CrUX sont disponibles pour votre site Web, concentrez-vous d'abord 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 de l'origine
- Données Ordinateur pour l'ensemble de l'origine
Vous pouvez les activer ou les désactiver dans les commandes situées en haut et 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 en contient pour l'origine, PageSpeed Insights affiche toujours les données d'origine.
La LCP de l'ensemble de l'origine peut être très différente de celle d'une page individuelle, selon la façon dont la LCP est chargée sur cette page par rapport aux autres pages de cette origine. La façon dont les visiteurs accèdent à ces pages peut également avoir une incidence. Les pages d'accueil sont généralement consultées par les nouveaux utilisateurs. Elles peuvent donc être chargées "à froid", sans contenu mis en cache, et sont donc souvent les pages les plus lentes d'un site Web.
Examiner les quatre différentes catégories de données CrUX peut vous aider à comprendre si un problème LCP est spécifique à cette page ou s'il s'agit d'un problème plus général à l'échelle du site. De même, il peut indiquer les types d'appareils présentant des problèmes de LCP.
Utiliser les métriques supplémentaires CrUX de PageSpeed Insights
Ceux qui souhaitent optimiser le LCP doivent également utiliser les temps First Contentful Paint (FCP) et Time to First Byte (TTFB), qui sont de bonnes métriques de diagnostic pouvant fournir de précieux insights sur le LCP.
Le TTFB correspond au temps écoulé entre le moment où le visiteur commence à accéder à une page (par exemple, en cliquant sur un lien) et la réception des premiers octets du document HTML. Un TTFB élevé peut rendre difficile, voire impossible, d'atteindre un LCP de 2,5 secondes.
Un TTFB élevé peut être dû à plusieurs redirections de serveur, à des visiteurs situés loin du serveur de site le plus proche, à des conditions réseau défavorables ou à l'impossibilité d'utiliser du contenu mis en cache en raison de paramètres de requête.
Une fois qu'une page commence à s'afficher, une peinture initiale (par exemple, la couleur d'arrière-plan) peut être appliquée, suivie de l'affichage 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 d'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 bloquant le rendu. Cela peut également être un signe que le site doit effectuer beaucoup de travail pour afficher un contenu significatif, ce qui est un 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 que le navigateur la priorise (par exemple, du texte ou des images gérés par JavaScript plutôt que 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 de 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 donné est globalement en accord avec les données utilisateur réelles fournies par CrUX. Si Lighthouse et CrUX ne sont pas d'accord, CrUX fournit probablement une image plus précise de votre expérience utilisateur. Avant de prendre des mesures, assurez-vous que vos données CrUX concernent votre page, et non l'origine complète.
Si Lighthouse et CrUX indiquent que les valeurs du LCP doivent être améliorées, la section Lighthouse peut vous fournir des conseils utiles pour y parvenir. 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 de diagnostic peuvent vous aider à diagnostiquer le problème. Le diagnostic Élément Largest Contentful Paint fournit une répartition utile des différents temps qui constituent le LCP:
Nous approfondirons ces sous-parties par la suite.
Répartition du LCP
L'optimisation du LCP peut être une tâche plus complexe lorsque PageSpeed Insights ne vous indique pas comment améliorer cette métrique. Pour les 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 traiter chacune séparément.
Cette section présente une méthodologie permettant de décomposer le LCP en ses sous-composants les plus critiques, puis présente des recommandations et des bonnes pratiques spécifiques pour optimiser chaque partie.
La plupart des chargements de page incluent généralement un certain nombre de requêtes réseau. Toutefois, pour identifier les possibilités d'amélioration du LCP, vous devez commencer par n'en examiner que deux:
- Le document HTML initial
- Ressource LCP (le cas échéant)
Bien que d'autres requêtes sur la page puissent affecter 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 pour le LCP ou non.
Pour identifier la ressource LCP, vous pouvez utiliser des outils pour les développeurs (tels que PageSpeed Insights, déjà mentionné, les Outils pour les développeurs Chrome ou WebPageTest) afin de déterminer l'élément LCP. Vous pouvez ensuite faire correspondre l'URL (encore une fois, le cas échéant) chargée par l'élément dans une cascade de ressources 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 en cascade réseau d'une page chargée de manière typique, où l'élément LCP nécessite une requête d'image pour s'afficher.
Pour une page bien optimisée, vous devez commencer à charger votre requête de ressource LCP le plus tôt possible et vous devez afficher l'élément LCP le plus rapidement possible une fois la ressource LCP chargée. Pour vous aider à visualiser si une page spécifique suit ce principe, vous pouvez décomposer la durée totale du LCP en sous-parties suivantes:
- Délai avant le premier octet (TTFB)
- Délai écoulé 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
- 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 l'affichage (par exemple, s'il s'agit d'un nœud de texte affiché avec une police système), cette valeur est 0.
- Durée de chargement de la ressource
- 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 le chargement de la ressource LCP et l'affichage complet de l'élément LCP.
La LCP de chaque page se compose de ces quatre sous-catégories. Il n'y a pas d'espace ni de chevauchement entre eux, et ils représentent la durée complète du LCP.
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. Ensemble, ils s'additionnent pour calculer la durée totale du LCP.
Lorsque vous optimisez le LCP, il est utile d'essayer d'optimiser ces sous-parties individuellement. Toutefois, il est également important de garder à l'esprit que vous devez les optimiser tous. Dans certains cas, une optimisation appliquée à une partie n'améliore pas le LCP, mais transfère simplement le temps gagné vers une autre partie.
Par exemple, dans la cascade réseau précédente, si vous réduisiez la taille du fichier de notre image en la compressant davantage ou en passant à un format plus optimal (tel que AVIF ou WebP), cela réduirait la durée de chargement des ressources, mais cela n'améliorerait pas le LCP, car le temps serait simplement décalé vers la sous-partie Délai d'affichage de l'élément:
En effet, sur cette page, l'élément LCP est masqué jusqu'à ce que le code JavaScript soit chargé, puis tout est révélé en même temps.
Cet exemple montre que vous devez optimiser toutes ces sous-parties pour obtenir les meilleurs résultats possibles pour le LCP.
Durée optimale des sous-parties
Pour 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.
Sur les quatre sous-parties, deux contiennent le mot "delay". Cela indique que vous voulez obtenir ces temps le plus près possible de zéro. Les deux autres parties impliquent des requêtes réseau, qui prennent du temps par nature.
Notez que ces répartitions temporelles sont des indications et non des règles strictes. Si les temps de LCP de vos pages sont constamment compris entre 2,5 secondes, les proportions relatives n'ont pas vraiment d'importance. Toutefois, si vous passez beaucoup de temps inutilement dans l'une des parties "retard", il sera très difficile d'atteindre constamment la cible de 2,5 secondes.
Voici une bonne façon de penser à la répartition du temps de LCP:
- La grande majorité du temps LCP doit être consacrée au chargement du document HTML et de la source LCP.
- Chaque fois qu'une de ces deux ressources ne se charge pas avant le LCP, cela peut être une opportunité de s'améliorer.
Optimiser chaque partie
Maintenant que vous savez comment chaque temps de 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 le délai de chargement des ressources
L'objectif de cette étape est de s'assurer que la ressource LCP commence à se charger le plus tôt possible. En théorie, le chargement d'une ressource pourrait débuter au plus tôt juste après le TTFB. Toutefois, dans la pratique, il y a toujours un certain délai avant que les navigateurs ne commencent à charger des ressources.
En règle générale, il convient de commencer à charger votre ressource LCP en même temps que la première ressource chargée par cette page. Autrement dit, si la ressource LCP commence à se charger plus tard que la première ressource, il existe une marge d'amélioration.
En règle générale, deux facteurs ont une incidence sur la vitesse de chargement d'une ressource LCP:
- Lorsque la ressource est découverte.
- Priorité de la ressource.
Optimiser lorsque la ressource est découverte
Pour vous assurer que votre ressource LCP commence à se charger le plus tôt possible, il est essentiel qu'elle soit visible dans la réponse initiale du document HTML par l'outil d'analyse du 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 la balise HTML initiale. - 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 à l'aide d'un en-têteLink). - L'élément LCP est un nœud de texte qui nécessite une police Web pour s'afficher. La police est chargée à l'aide de
<link rel="preload">dans le balisage HTML (ou à l'aide d'un en-têteLink).
Voici quelques exemples de cas où la ressource LCP ne peut pas être détectée en analysant la réponse du document HTML:
- L'élément LCP est un
<img>ajouté de manière dynamique à la page à l'aide de JavaScript. - L'élément LCP est chargé de manière paresseuse avec une bibliothèque JavaScript qui masque ses attributs
srcousrcset(souvent sous la formedata-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écouvrir la ressource LCP et de 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 de la source HTML. Si la ressource n'est référencée que depuis un fichier CSS ou JavaScript externe, la ressource LCP doit être préchargée avec une priorité de récupération élevée, par exemple:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/https/web.developers.google.cn/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="/https/web.developers.google.cn/path/to/hero-image.webp" type="image/webp">
Optimiser la priorité attribuée à la ressource
Même si la ressource LCP est visible dans le balisage HTML, elle peut tout de même ne pas commencer à se charger aussi tôt que la première ressource. Cela peut se produire si les heuristiques de priorité du scanner de préchargement du navigateur ne reconnaissent pas que la ressource est importante ou si elles déterminent que d'autres ressources sont plus importantes.
Par exemple, vous pouvez retarder l'affichage de votre image LCP à l'aide du code HTML si vous définissez loading="lazy" sur votre élément <img>. L'utilisation du chargement paresseux signifie que la ressource ne sera chargée qu'après que la mise en page aura confirmé que l'image se trouve dans le viewport. Le chargement peut donc commencer plus tard que d'habitude.
Même sans chargement différé, les images ne sont pas chargées initialement avec la priorité la plus élevée par les navigateurs, car elles ne sont pas des ressources bloquant le rendu. Vous pouvez indiquer au navigateur quelles ressources sont les plus importantes à l'aide de l'attribut fetchpriority pour les ressources qui pourraient bénéficier d'une priorité plus élevée:
<img fetchpriority="high" src="/https/web.developers.google.cn/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, définir une priorité élevée pour plus d'une ou deux images n'est pas utile pour réduire le LCP.
Vous pouvez également réduire la priorité des images qui peuvent apparaître au début de la réponse du document, mais qui ne sont pas visibles en raison du style, comme les images dans les diapositives de carrousel qui ne sont pas visibles au démarrage:
<img fetchpriority="low" src="/https/web.developers.google.cn/path/to/carousel-slide-3.webp">
Déprioriser certaines ressources peut accorder plus de bande passante aux ressources qui en ont le plus besoin, mais soyez prudent. Vérifiez toujours la priorité des ressources dans DevTools et testez les modifications à l'aide d'outils de laboratoire et sur le terrain.
Une fois que vous avez optimisé la priorité et le délai de découverte de votre ressource LCP, votre cascade de réseau devrait ressembler à ceci (la ressource LCP commençant en même temps que la première ressource):
2. Éliminer le délai d'affichage des éléments
L'objectif de cette étape est de s'assurer que l'élément LCP peut s'afficher immédiatement une fois que sa ressource a fini de se charger, quel que soit le moment.
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:
- Le rendu de l'intégralité de la page est bloqué en raison de feuilles de style ou de scripts synchrones dans le
<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, tel qu'une bibliothèque de tests A/B qui détermine encore le test auquel l'utilisateur doit participer.
- Le thread principal est bloqué en raison de longues tâches, et le rendu doit attendre que ces longues tâches soient terminées.
Les sections suivantes expliquent comment résoudre les causes les plus courantes de retard de rendu d'éléments inutiles.
Réduire ou intégrer les feuilles de style bloquant le rendu
Les feuilles de style chargées à partir de la balise 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 de code HTML sans style. Toutefois, si la feuille de style est si volumineuse que son chargement prend beaucoup plus de temps que la ressource LCP, elle empêchera 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 deux options:
- Insérer la feuille de style dans le code HTML pour éviter la requête 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é au 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 volumineuse qu'elle prend plus de temps à se charger que la ressource LCP, il est peu probable qu'elle soit un bon candidat pour 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 plus petite que la ressource LCP. Cela devrait éviter que ce ne soit un goulot d'étranglement pour la plupart des visites.
Voici quelques recommandations pour réduire la taille de la feuille de style:
- Supprimer le CSS inutilisé: utilisez les outils pour les développeurs Chrome pour rechercher les règles CSS qui ne sont pas utilisées et qui peuvent être supprimées (ou différées).
- Différez le CSS non critique: divisez votre feuille de style en styles requis pour le chargement initial de la page, puis en styles pouvant être chargés de manière paresseuse.
- Réduisez et compressez les fichiers CSS: pour les styles essentiels, assurez-vous de réduire autant que possible la taille de transfert.
Différer ou intégrer le code JavaScript bloquant l'affichage
Il n'est presque jamais nécessaire d'ajouter des scripts synchrones (scripts sans les attributs async ou defer) au <head> de vos pages. Cela aura presque toujours un impact négatif sur les performances.
Lorsque le code JavaScript doit s'exécuter le plus tôt possible lors du chargement de la page, il est préférable de l'intégrer afin que l'affichage ne soit pas retardé en attendant une autre requête réseau. Toutefois, comme pour les feuilles de style, vous ne devez insérer des scripts en ligne que s'ils sont très courts.
<head> <script src="/https/web.developers.google.cn/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
Le rendu côté serveur (SSR) consiste à exécuter votre logique d'application côté client sur le serveur et à répondre aux requêtes de documents HTML avec le balisage HTML complet.
Du point de vue de l'optimisation du LCP, le SSR présente deux avantages principaux:
- Vos ressources d'image seront visibles dans la source HTML (comme indiqué à l'étape 1 ci-dessus).
- Le contenu de votre page ne nécessitera pas de requêtes JavaScript supplémentaires pour s'afficher.
Le principal inconvénient du rendu côté serveur est qu'il nécessite un temps de traitement supplémentaire, ce qui peut ralentir le TTFB. Toutefois, ce compromis en vaut généralement la peine, car les délais de traitement du serveur sont sous votre contrôle, contrairement aux capacités du réseau et de l'appareil de vos utilisateurs.
Une option similaire au SSR est appelée génération de site statique (SSG) ou prérendu. Il s'agit du processus de génération de vos pages HTML lors d'une étape de compilation plutôt que sur demande. Si le prérendu est possible avec votre architecture, il est généralement préférable pour les performances.
Décomposer les tâches longues
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 tout de même retarder le LCP.
Cela se produit le plus souvent lorsque les pages chargent de gros fichiers JavaScript, qui doivent être analysés et exécutés sur le thread principal du navigateur. Cela signifie que même si votre ressource image est entièrement téléchargée, elle peut toujours devoir attendre la fin de l'exécution d'un script sans rapport avant de pouvoir s'afficher.
Tous les navigateurs d'aujourd'hui affichent des images sur le thread principal. Par conséquent, tout élément qui bloque le thread principal peut également entraîner un retard d'affichage des éléments 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 général, il existe quatre façons de procéder:
- Réduisez la taille de la ressource.
- Réduisez la distance que la ressource doit parcourir.
- Réduisez les conflits de bande passante réseau.
- Éliminez complètement le temps réseau.
Réduire la taille de la ressource
La ressource LCP d'une page (si elle en a une) est une image ou une police Web. Les guides suivants expliquent en détail comment réduire la taille des deux éléments:
- Diffuser la taille d'image 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 plaçant vos serveurs aussi près que possible 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 ils réduisent non seulement la distance que la ressource doit parcourir, mais aussi généralement sa taille. Ils implémentent automatiquement toutes les recommandations de réduction de taille précédentes.
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 en chargez de nombreuses autres en même temps. Ce problème est appelé conflit de réseau.
Si vous avez attribué à votre ressource LCP une fetchpriority élevée et que vous avez commencé à la charger dès que possible, le navigateur fera tout son possible pour empêcher les ressources de priorité inférieure de lui faire concurrence. Toutefois, si vous chargez de nombreuses ressources avec un fetchpriority élevé ou si vous ne chargez que beaucoup de ressources en général, cela peut affecter la vitesse de chargement de la ressource LCP.
Éliminer complètement le temps réseau
Le meilleur moyen de réduire la durée de chargement des ressources consiste à éliminer complètement le réseau du processus. Si vous diffusez vos ressources à l'aide d'une stratégie de contrôle de cache efficace, les visiteurs qui les demandent une seconde fois les verront diffusées à partir du cache, ce qui réduit la durée de chargement des ressources à pratiquement zéro.
Si votre ressource LCP est une police Web, en plus de réduire la taille de la police Web, vous devez également déterminer si vous devez bloquer le rendu lors du 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 lors du chargement, et le LCP ne sera pas bloqué par 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 élimine également la requête réseau supplémentaire. L'utilisation d'URL de données s'accompagne toutefois de mises en garde, car les ressources ne peuvent pas être mises en cache. Dans certains cas, cela peut entraîner des délais d'affichage plus longs en raison du coût de décodage supplémentaire.
4. Réduire le délai de transmission du premier octet
L'objectif de cette étape est de diffuser le code HTML initial le plus rapidement possible. Cette étape est listée en dernier, car c'est souvent 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 a une incidence directe sur toutes les étapes qui suivent. Rien ne peut se passer au niveau du frontend tant que le backend n'a pas envoyé le premier octet de contenu. Par conséquent, tout ce que vous pouvez faire pour accélérer le TTFB améliorera également toutes les autres métriques de chargement.
Un TTFB lent pour un site rapide est souvent dû à l'arrivée de visiteurs via plusieurs redirections, par exemple à partir d'annonces ou de liens abrégés. Réduisez toujours le nombre de redirections qu'un visiteur doit attendre.
Une autre cause courante est lorsque le contenu mis en cache ne peut pas être utilisé à partir d'un serveur de bordure CDN et que toutes les requêtes doivent être redirigées vers le serveur d'origine. Cela peut se produire si des visiteurs utilisent des paramètres d'URL uniques à des fins d'analyse, même s'ils ne renvoient pas vers des 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 pour toutes les sous-parties du LCP décrites précédemment sont disponibles en JavaScript via une combinaison des API de performances suivantes:
L'avantage de calculer ces valeurs de temps en JavaScript est qu'il vous permet de les envoyer à un fournisseur d'analyse ou de les consigner dans vos outils de développement pour 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 "Timings" (Temps) dans le panneau "Performances" des Outils pour les développeurs Chrome.
Les visualisations du canal Timings sont particulièrement utiles lorsqu'elles sont examinées avec les canaux Network (Réseau) et Main thread (Fil de discussion principal), car vous pouvez voir d'un coup d'œil ce qui se passe d'autre sur la page pendant ces périodes.
En plus de visualiser les sous-parties du LCP dans le canal "Timings", 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 de pourcentages recommandées décrites précédemment.
Cette capture d'écran montre un exemple qui enregistre la durée totale de chaque sous-partie LCP, ainsi que le pourcentage correspondant du temps LCP total à la console.
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 afin d'envoyer ces données à un fournisseur de solutions d'analyse. Cela vous permettra de mieux comprendre la répartition du LCP sur vos pages pour les utilisateurs réels.
Résumé
La LCP est complexe, et son calendrier peut être affecté par un certain nombre de facteurs. Toutefois, si vous considérez que l'optimisation du LCP consiste principalement à optimiser la charge de la ressource LCP, cela peut simplifier considérablement les choses.
De manière générale, l'optimisation du LCP peut se résumer en quatre étapes:
- Assurez-vous que la ressource LCP commence à se charger le plus tôt possible.
- Assurez-vous que l'élément LCP peut s'afficher dès que le chargement de sa ressource est terminé.
- Réduisez autant que possible le temps de chargement de la ressource LCP sans sacrifier la qualité.
- Livrez le document HTML initial aussi vite que possible.
Si vous pouvez suivre ces étapes sur vos pages, vous pouvez être sûr de proposer une expérience de chargement optimale à vos utilisateurs. Cela devrait se refléter dans vos scores LCP réels.