Optimiser le Largest Contentful Paint

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 lance le chargement de la page et celui où la plus grande image ou le plus grand bloc de texte est affiché dans la fenêtre d'affichage.

Pour offrir une expérience utilisateur de qualité, les sites doivent s'efforcer d'afficher le plus grand élément visible en 2,5 secondes ou moins pour au moins 75% des visites de page.

Une valeur LCP satisfaisante est de 2,5 secondes ou moins. Une valeur LCP mauvaise est supérieure à 4 secondes. Une valeur LCP comprise entre ces deux valeurs doit être améliorée.
Une valeur LCP satisfaisante est de 2,5 secondes ou moins.

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'ils vivent, plutôt que ce qu'un outil de laboratoire tel que Lighthouse ou des tests locaux montrent. 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.

LCP local et sur le terrain dans le panneau "Performances" des outils pour les développeurs Chrome
LCP local et sur le terrain dans le panneau "Performances" des outils pour les développeurs Chrome.

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

PageSpeed Insights vous 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. Des données plus détaillées issues de tests en laboratoire 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.

Données CrUX affichées dans PageSpeed Insights
Les données CrUX affichées dans PageSpeed Insights.

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.

PageSpeed Insights utilise les données au niveau de l'origine lorsque les données au niveau de l'URL ne sont pas disponibles
Lorsque PageSpeed Insights ne dispose pas de données au niveau de l'URL, il affiche les données au niveau de l'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 souvent 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 à déterminer si un problème de LCP est spécifique à cette page ou s'il s'agit d'un problème plus général sur l'ensemble 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

Pour optimiser le LCP, vous devez également utiliser les temps de First Contentful Paint (FCP) et de Time to First Byte (TTFB), qui sont de bonnes métriques de diagnostic pouvant fournir des insights précieux 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'apparition du contenu initial est mesurée par 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 repose 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 Lighthouse de PageSpeed Insights

La section Lighthouse de PageSpeed Insights propose des conseils pour améliorer le LCP. Toutefois, vous devez d'abord vérifier si le LCP indiqué est globalement conforme aux 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:

Opportunités et diagnostics LCP de Lighthouse
Les diagnostics Lighthouse et les suggestions pour améliorer le LCP

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:

Phases du LCP dans Lighthouse
Répartition des éléments LCP par Lighthouse.

Nous allons maintenant examiner ces sous-parties.

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:

  1. Document HTML initial
  2. 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.

Cascade de réseau avec les ressources HTML et LCP mises en évidence
Un diagramme en cascade illustrant les temps de chargement du code HTML d'une page Web et les ressources dont le LCP a besoin.

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 à déterminer si une page particulière respecte ou non ce principe, vous pouvez décomposer la durée totale de la LCP en sous-parties:

Délai avant le 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 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
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 de 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.

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.

Répartition de la LCP en quatre sous-catégories
Même diagramme en cascade, avec les quatre sous-catégories de LCP superposées à la chronologie.

La valeur LCP de chaque page peut être décomposée en quatre sous-parties. Il n'y a pas de chevauchement ni d'espace entre eux. Ensemble, ils représentent 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éduisez la taille de 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 réellement le LCP, car le temps serait simplement décalé vers la sous-partie Délai de rendu des éléments:

Même répartition du LCP que celle présentée précédemment, où la sous-catégorie "Durée de chargement des ressources" est raccourcie, mais que la durée globale du LCP reste la même.
Raccourcir la durée de chargement des ressources augmente le délai d'affichage de l'élément sans réduire le LCP.

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 illustre le fait 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" (retard). Cela signifie que vous devez réduire ces délais au maximum. Les deux autres parties impliquent des requêtes réseau, qui prennent du temps par nature.

Sous-partie du LCP % du LCP
Délai avant le premier octet ~40%
Délai de chargement de la ressource < 10 %
Durée de chargement de la ressource ~40%
Délai d'affichage de l'élément < 10 %
TOTAL 100 %

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.
  • Avant le LCP, chaque fois qu'une de ces deux ressources ne se charge pas, c'est une opportunité d'amélioration.

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 les plus 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, la ressource peut commencer à se charger immédiatement après le TTFB, mais en pratique, il y a toujours un délai avant que les navigateurs ne commencent à charger les ressources.

En règle générale, votre ressource LCP doit commencer à se charger 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.

Schéma de cascade de réseau montrant la ressource LCP commençant après la première ressource, et indiquant les possibilités d&#39;amélioration
Sur cette page, la ressource LCP commence à se charger bien après la feuille de style qui se charge en premier. Il y a encore de la marge de progression.

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é attribuée à la ressource.

Optimiser lorsque la ressource est découverte

Pour que votre ressource LCP commence à se charger le plus tôt possible, il est essentiel qu'elle soit détectable dans la réponse du document HTML initial par le scanner 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 attributs src ou srcset sont 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ête Link).
  • 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ête Link).

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 src ou srcset (souvent sous la forme data-src ou data-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 éviter tout retard de chargement de ressources inutile, votre ressource LCP doit être détectable à 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="/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é attribuée à la ressource

Même si la ressource LCP est visible dans le balisage HTML, elle peut toujours 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 s'il détermine 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="/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, si vous définissez une priorité élevée sur plus d'une ou deux images, cela ne vous aidera pas à réduire le LCP.

Vous pouvez également réduire la priorité des images qui peuvent se trouver au début de la réponse du document, mais qui ne sont pas visibles en raison du style, par exemple les images des diapositives de carrousel qui ne sont pas visibles au démarrage:

<img fetchpriority="low" src="/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):

Diagramme en cascade du réseau montrant que la ressource LCP commence désormais en même temps que la première ressource
La ressource LCP commence désormais à se charger en même temps que la feuille de style.

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 toujours le test auquel l'utilisateur doit participer.
  • Le thread principal est bloqué en raison de tâches longues, et le travail de rendu doit attendre que ces tâches longues 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:

Schéma en cascade du réseau montrant qu&#39;un fichier CSS volumineux bloque l&#39;affichage de l&#39;élément LCP, car son chargement prend plus de temps que la ressource LCP
La feuille de style et l'image commencent à se charger en même temps, mais l'image ne peut pas s'afficher tant que la feuille de style n'est pas prête.

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 consiste à 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:

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.

À éviter
<head>
  <script src="/path/to/main.js"></script>
</head>
À faire
<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

Utiliser l'affichage côté serveur

Le rendu côté serveur (SSR) consiste à exécuter la logique de votre application côté client sur le serveur et à répondre aux requêtes de documents HTML avec la balise HTML complète.

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 être affiché.

Le principal inconvénient du SSR est qu'il nécessite un temps de traitement supplémentaire du serveur, ce qui peut ralentir votre TTFB. Ce compromis est généralement intéressant, car vous pouvez contrôler les temps de traitement du serveur, contrairement aux fonctionnalités réseau et des appareils 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 n'est pas bloquant pour le rendu ni responsable du rendu de vos éléments, il peut toujours 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éduire les conflits pour la bande passante réseau.
  • Supprimez complètement l'heure 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:

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 un fetchpriority élevé 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 chargez simplement beaucoup de ressources en général, cela peut affecter la rapidité de chargement de la ressource LCP.

Supprimer complètement l'heure 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. Toutefois, l'utilisation d'URL de données présente des limites, car les ressources ne peuvent pas être mises en cache et, dans certains cas, peuvent entraîner des délais de rendu 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 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 les visiteurs utilisent des paramètres d'URL uniques pour les données analytiques, même s'ils ne renvoient pas à des pages différentes.

Pour obtenir des conseils spécifiques sur l'optimisation du TTFB, consultez le guide d'optimisation du TTFB.

Surveiller la répartition du LCP en JavaScript

Les informations de timing pour toutes les sous-parties du LCP abordées 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" (Performances) des outils pour les développeurs Chrome.

Mesures de la durée utilisateur des sous-catégories de LCP visualisées dans les outils pour les développeurs Chrome
Le canal "Durées" affiche les chronologies des sous-catégories du LCP.

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 pourcentage recommandées décrites précédemment.

Cette capture d'écran montre un exemple qui consigne la durée totale de chaque sous-partie du LCP, ainsi que son pourcentage de la durée totale du LCP dans la console.

Les temps de la sous-catégorie LCP, ainsi que leur pourcentage de LCP, affichés dans la console
Temps et pourcentages des sous-catégories de LCP.

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 d'analyse afin de mieux comprendre la répartition de la 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:

  1. Assurez-vous que la ressource LCP commence à se charger dès que possible.
  2. Assurez-vous que l'élément LCP peut s'afficher dès que sa ressource a fini de se charger.
  3. Réduisez autant que possible le temps de chargement de la ressource LCP sans sacrifier la qualité.
  4. Fournissez le document HTML initial aussi rapidement 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.