Le monde du web est en constante évolution, et la vitesse de chargement de vos pages est important pour l'expérience utilisateur et votre référencement. Au cœur de cette dynamique se trouve le Largest Contentful Paint (LCP), une métrique essentielle des Core Web Vitals de Google. Loin d'être un simple chiffre technique, le LCP est un indicateur de la rapidité avec laquelle le contenu principal de votre page devient visible pour l'utilisateur. Comprendre et maîtriser le LCP, c'est s'assurer que vos visiteurs se sentent rassurés sur l'utilité de votre page dès les premières secondes. On vous en dit plus, en nous appuyant en grande partie sur l’expertise d’Aymeric Bouillat, spécialiste du sujet !

Ce qu'il faut retenir :

  • Le LCP mesure la vitesse de chargement perçue de votre page web en identifiant le moment où le plus grand élément de contenu (image, vidéo, ou bloc de texte) est affiché dans la fenêtre d'affichage.
  • Un bon LCP est de 2,5 secondes ou moins, mesuré sur le 75e centile des chargements de pages pour garantir une expérience de qualité à la majorité de vos utilisateurs.
  • Le LCP n'est pas statique et peut changer au fur et à mesure du chargement de la page. Sa mesure s'arrête dès que l'utilisateur interagit avec la page (clic, défilement, touche).
  • L'optimisation du LCP passe par la réduction du temps de réponse du serveur (TTFB), la minification du JavaScript et du CSS, l'optimisation des images et des polices web, et une attention particulière au rendu côté client.

Qu'est-ce que le LCP et pourquoi est-il important ?

Le Largest Contentful Paint, ou LCP, est une métrique Core Web Vitals stable et importante qui évalue la vitesse de chargement perçue d'une page. Il marque le moment où le contenu principal de votre page est très probablement chargé et visible par l'utilisateur. Historiquement, il était difficile de mesurer la rapidité de chargement du contenu principal. Les anciennes métriques comme load ou DOMContentLoaded ne correspondaient pas toujours à ce que l'utilisateur voyait, et même des métriques plus récentes comme First Contentful Paint (FCP) ne capturaient que le début de l'expérience de chargement, sans indiquer quand le contenu "utile" apparaissait. Google a donc introduit le LCP comme un indicateur plus "humain" du ressenti utilisateur.

Un LCP rapide rassure l'utilisateur sur l'utilité de la page. À l'inverse, un LCP médiocre peut entraîner un taux de rebond plus élevé et une baisse du taux de conversion, tout en pénalisant votre classement SEO. C'est pourquoi le LCP est devenu un facteur de classement indispensable dans les SERP (Search Engine Results Pages), suite à la mise à jour des Core Web Vitals. Il est important de noter que le LCP se concentre uniquement sur le contenu principal situé au-dessus de la ligne de flottaison (la partie visible de la page sans défilement).

LCP - Exemple de chronologie avec Instagram - Source : web.dev

Qu'est-ce qui est pris en compte pour le LCP ?

Pour le calcul du LCP, seuls certains types d'éléments sont considérés comme des "candidats". Ces éléments sont ceux qui ont la plus grande taille visible dans la fenêtre d'affichage et qui sont susceptibles de représenter le contenu principal.

Les types d'éléments pris en compte incluent :

  • Les éléments <img> (même les GIF ou PNG animés, c'est le temps de présentation du premier frame qui est utilisé).
  • Les éléments <image> à l'intérieur d'un élément <svg>. Attention,les éléments <svg> eux-mêmes ne sont généralement pas pris en compte pour le LCP, sauf s'ils contiennent des éléments <image> individuels.
  • Les éléments <video> (le temps de chargement de l'image ou le temps de présentation du premier frame est utilisé, le plus tôt possible).
  • Les éléments avec une image de fond chargée via la fonction url() en CSS (et non via un dégradé CSS).
  • Les éléments de niveau bloc contenant des nœuds de texte ou d'autres éléments enfants de texte au niveau de l'alignement en ligne (par exemple, un grand paragraphe <p> ou un titre <h1>).

Certains éléments sont spécifiquement exclus par des heuristiques, car ils ne sont généralement pas considérés comme du "contenu" principal :

  • Les éléments avec une opacité de 0, qui sont invisibles.
  • Les éléments qui couvrent toute la fenêtre d'affichage et sont probablement des arrière-plans.
  • Les images fictives ou peu informatif, qui ne représentent pas le contenu réel de la page.

Ces heuristiques peuvent différer de celles utilisées par le FCP, car le LCP vise à identifier le contenu principal, tandis que le FCP mesure l'affichage de n'importe quel contenu.

Comment la taille d'un élément est-elle déterminée ?

La taille d'un élément pour le LCP correspond à la portion visible par l'utilisateur dans la fenêtre d'affichage. Si une partie de l'élément est rognée, dépasse la fenêtre d'affichage ou est masquée, ces portions ne sont pas prises en compte.

  • Pour les images redimensionnées, la taille retenue est la plus petite entre la taille visible et la taille intrinsèque.
  • Pour les éléments textuels, le LCP considère le plus petit rectangle englobant tous les nœuds de texte. Les marges, paddings et bordures CSS ne sont pas inclus dans le calcul de la taille de l'élément.

Précisons que le LCP ne mesure pas la "surface de pixel" au sens strict, mais le temps de rendu de l'élément le plus grand ; la surface servant uniquement à déterminer quel est cet "élément le plus grand".

LCP - Exemple de chronologie avec CNN - Source : web.dev

Quand le LCP est-il mesuré et signalé ?

Le LCP n'est pas une mesure statique ; il peut changer au fur et à mesure du chargement de la page. Le navigateur distribue de nouvelles entrées largest-contentful-paint à chaque fois que l'élément le plus grand change. Par exemple, un titre peut d'abord être le LCP, puis une image plus grande qui se charge plus tard peut devenir le nouveau LCP. Un élément n'est considéré comme un candidat LCP qu'après avoir été rendu et visible. Les images non encore chargées ou les textes utilisant des polices web non encore téléchargées ne sont pas prises en compte tant qu'ils ne sont pas affichés.

La mesure du LCP s'arrête dès que l'utilisateur interagit avec la page (en la faisant défiler, en cliquant ou en appuyant sur une touche), car ces interactions modifient souvent ce qui est visible.

Un point important à noter est la distinction entre le temps de chargement et le temps d'affichage. Le temps de chargement (quand la ressource est téléchargée) peut être différent du temps d'affichage (quand elle est rendue). Pour les images cross-origines (issu d’un autre domaine), il y avait auparavant une restriction de sécurité qui ne permettait d'exposer que le temps de chargement, ce qui pouvait faire apparaître le LCP comme antérieur au FCP dans certains cas. Ce problème a été résolu pour Chrome 133, mais l'utilisation de l'en-tête Timing-Allow-Origin est toujours recommandée pour des mesures plus précises.

Notons aussi que les modifications de taille ou de position d'un élément après son affichage initial ne génèrent pas de nouveaux candidats LCP. Seules la taille et la position initiales de l'élément dans la fenêtre d'affichage sont prises en compte.

Quel est un "bon" score LCP ?

Pour offrir une expérience utilisateur de qualité, un site web doit viser un LCP de 2,5 secondes ou moins.

  • Vert (rapide) : 0 à 2,5 secondes.
  • Orange (modéré) : 2,5 à 4 secondes.
  • Rouge (lent) : Plus de 4 secondes.

Ces seuils sont cohérents entre les données de terrain (CrUX) et les recommandations de l'initiative Web Vitals pour tous les appareils. Cependant, Lighthouse, en tant qu'outil de laboratoire, peut utiliser des seuils légèrement plus stricts pour les ordinateurs, par exemple, un LCP de 0-1,2 secondes est considéré comme "rapide" sur ordinateur dans Lighthouse.

Pour s'assurer que cet objectif est atteint pour la majorité des utilisateurs, Google recommande de mesurer le 75e centile des chargements de pages, segmenté par appareil (mobile et ordinateur). Si vos utilisateurs attendent 5 secondes ou plus, ils risquent d'abandonner votre site.

LCP face aux autres métriques

Le LCP est souvent comparé à d'autres métriques de performance :

  • LCP vs. FCP (First Contentful Paint) : Le FCP mesure le temps d'affichage du premier contenu, tandis que le LCP mesure le temps d'affichage du plus grand contenu. On peut considérer le FCP comme le "premier candidat LCP". Si votre FCP et votre LCP sont très proches, c'est un bon signe de chargement rapide.
  • LCP et TTFB (Time To First Byte) : Un bon TTFB (le délai entre la requête et la réception du premier octet de la réponse du serveur) est souvent synonyme d'un bon LCP, car un TTFB élevé a un impact direct sur le LCP. Diminuer le TTFB d'une seconde peut réduire le LCP d'autant. La latence du premier octet est d'ailleurs une sous-partie du LCP dans les diagnostics de Lighthouse.
  • Speed Index : Historiquement, le Speed Index était utilisé pour capturer l'expérience de chargement après l'affichage initial. Cependant, Aymeric Bouillat n'utilise pas le Speed Index, car les métriques comme TBT, LCP, FCP et TTFB fournissent déjà des données suffisantes.
  • LCP en complément d'autres Core Web Vitals : Bien que le LCP soit central pour l'expérience utilisateur, il fonctionne toujours en complément avec le CLS (Cumulative Layout Shift) et le FID (First Input Delay) pour l'évaluation globale des Core Web Vitals.

Les causes fréquentes d'un LCP médiocre

Plusieurs facteurs peuvent entraîner un LCP médiocre, souvent regroupés en quatre catégories principales :

  1. Temps de réponse du serveur lent (TTFB) : C'est un facteur majeur qui affecte toutes les métriques de vitesse. Il est souvent dû à une infrastructure serveur peu optimisée, des requêtes de base de données inefficaces ou des réponses API lentes.
  2. JavaScript et CSS bloquant le rendu : Les fichiers JavaScript et CSS qui ne sont pas optimisés peuvent empêcher le navigateur de rendre la page rapidement. Si trop de code bloque le rendu au-dessus de la ligne de flottaison, le LCP en souffrira.
  3. Temps de chargement lent des ressources : Les images non optimisées, les vidéos lourdes, les GIF, ou tout contenu visuel à fort impact prennent du temps à charger et peuvent ralentir le LCP.
  4. Rendu côté client : Les applications web qui s'appuient fortement sur JavaScript pour rendre le contenu (rendu côté client) peuvent créer des délais supplémentaires, car le navigateur doit télécharger, analyser et exécuter le JavaScript avant d'afficher le contenu principal.

Comment optimiser votre LCP ?

Pour améliorer votre LCP, plusieurs stratégies peuvent être mises en œuvre :

  1. Optimisez votre CSS :
    • Minifiez et compressez vos fichiers CSS.
    • Supprimez le code CSS inutilisé pour réduire la taille des fichiers.
    • Utilisez les requêtes média pour charger des CSS spécifiques en fonction des caractéristiques de l'appareil.
    • Évitez d'avoir trop de fichiers CSS bloquant le rendu.
  2. Optimisez vos images :
    • Compressez vos images sans perte de qualité significative.
    • Convertissez-les vers des formats modernes et plus efficaces (comme WebP ou AVIF).
    • Assurez-vous qu'elles ont les bonnes dimensions pour la fenêtre d'affichage.
    • Envisagez d'utiliser des vidéos (avec l'attribut autoplay et loop) à la place des GIF, car elles sont souvent plus légères.
    • Questionnez la nécessité de chaque image.
  3. Optimisez vos WebFonts :
    • Les polices personnalisées peuvent être lourdes et bloquer l'affichage du texte.
    • Réduisez la taille de vos fichiers de polices.
    • Utilisez la propriété CSS font-display pour contrôler la façon dont les polices sont chargées et affichées.
    • Chargez les polices de manière asynchrone.
  4. Optimisez votre JavaScript :
    • Supprimez le code JavaScript inutilisé.
    • Minifiez et compressez vos fichiers JavaScript.
    • Mettez à jour votre code pour qu'il soit compatible avec les navigateurs modernes.
    • Utilisez le fractionnement de code (code splitting) pour ne charger que le JavaScript nécessaire pour la partie visible de la page.
    • Précharge les requêtes clés.
    • Réduisez l'impact du code tiers.
  5. Améliorez le temps de réponse du serveur (TTFB) :
    • Assurez-vous que votre site est hébergé sur un bon serveur.
    • Utilisez un CDN (Content Delivery Network) pour distribuer votre contenu plus près de vos utilisateurs.
    • Optimisez vos requêtes de base de données et les appels API.
    • Mettez en place des stratégies de mise en cache efficaces, car un cache manqué (cache miss) peut augmenter le TTFB et donc le LCP.
  6. Adaptez votre contenu :
    • Dans certains cas, comme le mentionne Aymeric Bouillat, si votre LCP est un élément texte très long, vous pourriez découper un gros paragraphe en plusieurs balises <p> pour qu'il ne soit plus considéré comme le plus grand élément et potentiellement améliorer le score.
    • Il est parfois possible de modifier légèrement la taille d'un élément (comme un <h1>) pour qu'il devienne le LCP à la place d'une image. Le texte étant directement dans le HTML et ne nécessitant pas de ressource complémentaire, cela peut accélérer le chargement.

Mesurer et déboguer votre LCP

Plusieurs outils sont à votre disposition pour mesurer et analyser votre LCP, tant en Lab qu'avec des données réelles d’utilisateurs :

Outils sur le terrain (Field Data) : Ces données proviennent de l'expérience réelle des utilisateurs et sont utilisées pour évaluer les performances de votre site dans des conditions réelles.

  • Rapport sur l'expérience utilisateur de Chrome (CrUX) : Fournit les données LCP réelles collectées auprès des utilisateurs de Chrome.
  • Google Search Console (Rapport Core Web Vitals) : Vous donne un aperçu des performances LCP de vos URLs, vous aidant ainsi à identifier les problèmes. Soyez attentif à ne pas confondre les données globales d'un site (origine) avec les données spécifiques à une URL, car Google pourrait afficher les données globales par défaut si les données pour une URL sont insuffisantes.
  • PageSpeed Insights : Affiche à la fois les données de laboratoire et de terrain pour votre LCP et propose des recommandations d'optimisation.
  • Bibliothèque JavaScript web-vitals : Permet de collecter les données LCP réelles de vos utilisateurs directement sur votre site et de les envoyer à des outils d'analyse (comme Google Analytics ou Piano Analytics). C'est particulièrement utile pour les pages à faible trafic pour lesquelles Google pourrait ne pas avoir suffisamment de données CrUX.

Outils de Lab Data : Ces outils fournissent des mesures reproductibles dans un environnement contrôlé, idéales pour le débogage.

  • Chrome DevTools (onglet Performance) : Un excellent outil pour visualiser les éléments LCP et analyser leur chargement en détail. Vous pouvez y voir la répartition du LCP en sous-parties (TTFB, délai de chargement, temps de chargement, délai de rendu).
  • Lighthouse : Intégré à Chrome DevTools et à PageSpeed Insights, il affiche votre score LCP et des diagnostics détaillés pour l'améliorer.
  • WebPageTest : Un outil avancé pour des tests de performance détaillés.
  • Debug Bear : Cet outil effectue des mesures de laboratoire régulières et fournit des recommandations d'optimisation très spécifiques et orientées développement, allant au-delà de PageSpeed Insights.
  • Treo.sh : conseillé par Aymeric, cet outil permet de consulter les données LCP à l'échelle mondiale, utile pour les sites internationaux.

Pour mesurer le LCP en JavaScript, vous pouvez utiliser l'API Largest Contentful Paint. Cependant, cette API présente des différences subtiles par rapport au calcul réel de la métrique (par exemple, elle signale des entrées pour les onglets en arrière-plan qui doivent être ignorées, et ne tient pas compte des iFrames ou des pages restaurées du cache avant/arrière). Il est donc fortement recommandé d'utiliser la bibliothèque JavaScript web-vitals qui gère la plupart de ces complexités pour vous.

En surveillant et en optimisant constamment votre LCP, vous vous assurez non seulement de fournir une meilleure expérience à vos utilisateurs, mais aussi de maintenir un bon classement dans les moteurs de recherche !