Largest Contentful Paint (LCP) : Ce que c'est, comment mesurer et optimiser

Qu'est-ce que le Largest Contentful Paint (LCP) ?

Le Largest Contentful Paint est une mesure du temps de rendu du plus grand élément de contenu (de type image, vidéo ou texte) qui a été affiché sur la partie visible de l'écran. Le timing LCP indique le temps en millisecondes entre la demande de la page et le moment où ce plus grand élément de contenu est affiché sur la partie visible de la page web (au-dessus de la ligne de flottaison).

Histoire du Largest Contentful Paint

Quand on y pense, le LCP peut sembler être une métrique triviale pour représenter la partie chargement des Core Web Vitals. Pourquoi ne pas mesurer la vitesse de chargement comme « le temps qu'il faut pour que la page se charge » ?

C'est parce qu'il est difficile (voire impossible) sur la plupart des sites web modernes de définir quand la page a fini de charger. De plus en plus de sites utilisent des techniques comme le lazy loading ou le chargement progressif où la page peut techniquement continuer à charger indéfiniment. Cela signifie que la vitesse de la page ne peut pas être mesurée par un seul point dans le temps.

Il y a plusieurs moments lors du chargement de la page qui peuvent amener un utilisateur à percevoir la page comme rapide ou lente. Par exemple, le délai du serveur (Time to First Byte), la première fois qu'un contenu est visible (First Contentful Paint), le moment où le viewport visible semble complet (Largest Contentful Paint) et quand la page devient interactive (quand cliquer sur un lien devient possible) sont tous des points durant le processus de chargement où le site peut paraître lent ou rapide !

Le Largest Contentful Paint (LCP) a été choisi car il se concentre sur l'expérience utilisateur du visiteur. Lorsque le LCP se produit, on peut supposer que le visiteur pense que la page a fini de charger (même si des processus en arrière-plan sont toujours en cours). Le LCP a été créé pour répondre à la question : « Quand le contenu d'une page est-il visible ? ». C'est pourquoi le LCP est reconnu comme un indicateur clé de la performance centrée sur l'utilisateur.

LCP vs FCP : Quelle est la différence ?

Le Largest Contentful Paint (LCP) et le First Contentful Paint (FCP) mesurent tous deux la performance de chargement, mais ils capturent des moments fondamentalement différents dans la chronologie du chargement de la page. Le FCP se déclenche dès que le navigateur affiche le premier pixel de contenu, ce qui pourrait être une minuscule barre de navigation ou un indicateur de chargement. Le LCP se déclenche lorsque l'élément significatif le plus grand est rendu dans le viewport.

Voyez-le de cette façon : le FCP vous dit que la page a commencé à charger ; le LCP vous dit que la page semble chargée. Google a choisi le LCP comme Core Web Vital car il reflète plus précisément ce que les utilisateurs perçoivent comme de la « vitesse ».

Pour la plupart des sites web, l'optimisation du LCP devrait être la priorité. Si votre LCP est rapide, votre FCP le sera presque toujours aussi, car le FCP survient plus tôt dans la chronologie de chargement. L'inverse n'est pas vrai : un FCP rapide ne garantit pas un LCP rapide.

Pourquoi le LCP est important pour votre entreprise

Le Largest Contentful Paint est l'un des 3 Core Web Vitals. En tant que Core Web Vital, le Largest Contentful Paint est important pour le SEO, mais plus important encore, le LCP est critique pour l'UX. Les visiteurs n'aiment pas être tenus en attente, et avec de plus en plus de trafic mobile (qui a tendance à être plus lent que le trafic desktop), optimiser le Largest Contentful Paint est très logique.

• Pour le SEO. Oui, Google se concentre sur le service des meilleures pages dans ses résultats de recherche. Le LCP fait partie des Core Web Vitals de Google. Google stipule clairement que la vitesse du site est un facteur dans les résultats de recherche.
• Pour les visiteurs : Selon des recherches récentes de Google lui-même, la probabilité qu'un utilisateur quitte le site double avec un temps de chargement de 3 secondes. Vous le reconnaîtrez probablement par vous-même. En surfant sur Internet, presque rien ne semble aussi agaçant qu'un site web lent à charger. Il y a de fortes chances que vous quittiez rapidement une page lente.
• Autres raisons : La Page Speed est un facteur dans votre Google Ad Score. Cela signifie que vous pouvez acheter vos publicités moins cher. De plus, réussir les Core Web Vitals est l'un des prérequis pour la boîte "Top Story" de Google.

Un LCP rapide donne au visiteur l'idée que la page se charge rapidement. En conséquence, un visiteur est moins susceptible de quitter la page.

Étude de cas : Vodafone (amélioration du LCP de 31 %, 8 % de ventes en plus)

Vodafone Italie a mené une expérience contrôlée en optimisant son score LCP. En réduisant le LCP de 31 %, ils ont mesuré une augmentation de 8 % des ventes. Il ne s'agit pas d'une corrélation ; c'est un test A/B direct prouvant qu'un chargement perçu plus rapide se traduit par plus de revenus. L'optimisation s'est concentrée sur le préchargement de l'image LCP et la réduction des ressources bloquant le rendu. Lire l'étude de cas complète de Vodafone sur web.dev.

Étude de cas : Google Flights (fetchpriority a permis de gagner 700 ms)

L'équipe de Google Flights a ajouté fetchpriority="high" à son image hero et a vu le LCP s'améliorer de 700 millisecondes. Ce simple changement d'attribut HTML a été l'optimisation la plus marquante de leur sprint de performance. L'attribut fetchpriority indique au navigateur de prioriser le téléchargement de l'image LCP par rapport aux autres ressources, et comme le démontre l'expérience Google Flights, l'impact peut être spectaculaire. En savoir plus sur la priorisation des ressources pour les Core Web Vitals.

Quels éléments sont considérés comme des éléments LCP ?

Tous les éléments ne sont pas considérés comme un élément LCP. Le Largest Contentful element doit être affiché sur la partie visible de l'écran (le viewport) avant que l'utilisateur n'ait interagi avec la page.

L'élément doit être :

• Un élément <img>.
• Un élément <image> imbriqué dans un élément <svg>.
• Un élément <video> (l'image poster ou la première frame vidéo, selon ce qui arrive en premier, est utilisée).
• Un élément avec une image d'arrière-plan chargée via la fonction CSS url(). (Note : C'est un anti-pattern pour l'optimisation du LCP car cela rend l'image indécouvrable pour le preload scanner du navigateur. Lisez notre guide sur le report des images d'arrière-plan).

• Un élément de niveau bloc contenant des nœuds de texte ou d'autres éléments de texte en ligne (dans le cas d'éléments de texte en ligne comme <span>, l'élément de niveau bloc le plus proche <div> ou <p> est considéré).

Actuellement, certains éléments sont exclus des candidats LCP, tels que les éléments cachés avec opacity: 0, les images qui correspondent à 100 % de la taille du viewport (images de couverture) et les placeholders (images à faible entropie). Gardez à l'esprit que cela peut changer à mesure que la spécification évolue !

Aspects techniques : Mesurer la taille de l'élément LCP

Le LCP identifie l'élément de contenu visible le plus grand dans le viewport et calcule sa taille sur la base d'un ensemble de règles précises. Ces règles garantissent la cohérence et l'exactitude, même dans des mises en page complexes.

• Viewport uniquement : Seule la partie visible de la page est prise en compte. Si un élément n'est que partiellement dans le viewport visible, la taille considérée sera rognée.
• Pas de bordure, de padding ou de marge : Pour tous les éléments, les bordures de texte et d'image, le padding et les marges sont complètement ignorés.
• Taille du texte : Les éléments de texte sont rapportés comme le plus petit rectangle pouvant être dessiné autour du ou des nœuds de texte.
• Taille de l'image : Pour les images, la plus petite des dimensions intrinsèques (la largeur et la hauteur d'origine) et de la taille d'affichage (la taille à l'écran) est utilisée pour calculer la taille de l'élément LCP.
• La première taille compte : Lorsque la mise en page change ou lorsqu'une taille d'élément change, seule la première taille est prise en compte pour le LCP.
• Les éléments supprimés sont inclus : Lorsqu'un élément est supprimé du DOM, il reste un candidat LCP.

Nature dynamique du LCP

Le Largest Contentful Paint (LCP) est une métrique dynamique. Bien que le rendu puisse être complexe et se produire par étapes, il est normal que l'élément LCP change pendant le chargement de la page. Avant la première interaction de l'utilisateur, l'observer de performance du navigateur identifie tous les éléments qui pourraient être considérés comme des candidats LCP. Si un nouvel élément est rendu qui est à la fois visible dans le viewport et plus grand que l'élément LCP précédemment identifié, il devient le nouveau LCP.

Enseignements des données de terrain LCP : Chez CoreDash, nous suivons des millions d'entrées LCP par jour. Il s'avère que pour les pages vues sur mobile, l'élément LCP est souvent un élément textuel, soit un paragraphe, soit un titre. En moyenne (ou au 75e centile pour être précis), les Core Web Vitals passeront lorsque l'élément LCP est un nœud de texte ou même une image normale. Lorsque l'élément LCP est une image d'arrière-plan, une vidéo ou une image chargée en différé (lazy-loaded), les Core Web Vitals ont tendance à échouer.

Qu'est-ce qu'un bon score LCP ?

Pour réussir les Core Web Vitals pour le Largest Contentful Paint, au moins 75 % de vos visiteurs doivent avoir un « bon » score LCP. Un score LCP compris entre 0 et 2,5 secondes est considéré comme un bon score LCP, un score LCP entre 2,5 et 4 secondes nécessite une amélioration et un score LCP supérieur à 4 secondes est considéré comme médiocre.

Ce que montrent les données LCP réelles

CoreDash suit chaque jour des millions de mesures LCP d'utilisateurs réels. Voici ce que les données révèlent sur la performance LCP à travers le web.

LCP Image vs LCP Texte

Les pages avec des éléments LCP basés sur l'image ont un p75 LCP de 744 ms, soit près de deux fois plus lent que les éléments LCP basés sur le texte à 388 ms. Cela confirme que l'optimisation des images est le domaine le plus impactant pour améliorer les scores LCP. Si votre élément LCP est une image, vous devez être particulièrement agressif dans son optimisation.

L'impact du préchargement et du Lazy Loading

Les images LCP préchargées obtiennent 100 % de scores « bons » avec un p75 de 364 ms. En revanche, les images LCP chargées en différé (lazy-loaded) sont parmi les plus lentes à 720 ms, avec 4,3 % des chargements de page classés comme « médiocres ». Les images non préchargées ne sont guère plus performantes à 752 ms. La conclusion est claire : préchargez votre image LCP et ne la chargez jamais en différé.

LCP Mobile vs Desktop

Le LCP mobile (764 ms au 75e centile) est 2 fois plus lent que le LCP desktop (380 ms). Cet écart est dû aux réseaux mobiles plus lents et aux processeurs mobiles moins puissants. Puisque Google utilise l'indexation mobile-first, l'optimisation du LCP mobile devrait être la priorité.

Statistiques mondiales du LCP

Selon l'HTTP Archive Web Almanac 2025, 62 % des pages mobiles atteignent mondialement un bon score LCP (moins de 2,5 secondes), contre 44 % en 2022. Le LCP reste le Core Web Vital le plus difficile à réussir et constitue le principal goulot d'étranglement pour les scores CWV globaux. De plus, 73 % des éléments LCP mobiles sont des images, et 16 % des sites mobiles chargent par erreur leur image LCP en différé.

Comment le LCP est mesuré : Les quatre phases clés

Selon Google, le Largest Contentful Paint peut être décomposé en 4 sous-parties. Comprendre quelle phase cause le goulot d'étranglement est essentiel pour une optimisation efficace, car chaque phase nécessite un correctif complètement différent. Un Time to First Byte (TTFB) lent nécessite un travail côté serveur, tandis qu'un retard de chargement de ressource lent nécessite des modifications de votre HTML.

Le temps LCP final d'une page n'est pas une valeur unique et monolithique. C'est la somme de quatre sous-parties distinctes. Comprendre cette décomposition est la clé pour diagnostiquer et corriger les problèmes de LCP efficacement.

Voici une décomposition des quatre phases :

• Time to First Byte (TTFB) : C'est le temps de réponse pur du serveur. Il couvre tout, de la recherche DNS à la connexion TCP/TLS, jusqu'au moment où le navigateur reçoit le premier octet du document HTML. Un TTFB lent est un problème fondamental qui tuera toujours votre LCP. Sur le web, les sites avec un mauvais LCP passent en moyenne 2,27 secondes sur le seul TTFB, ce qui représente presque la totalité du seuil de 2,5 secondes. Optimiser le TTFB implique la mise en cache côté serveur, la configuration du CDN et un code backend efficace.
• Resource Load Delay : C'est l'« écart de découverte ». Il mesure le temps entre la fin du TTFB et le moment où le navigateur commence réellement à télécharger la ressource LCP. Un long délai ici signifie que le navigateur a trouvé la ressource LCP tardivement. C'est le symptôme classique de l'utilisation d'images d'arrière-plan CSS (que le preload scanner ne peut pas découvrir) ou du rendu côté client (où l'élément LCP n'apparaît qu'après l'exécution du JavaScript). Le correctif consiste à s'assurer que votre élément LCP est dans le HTML initial et à précharger l'image LCP si le navigateur ne peut pas la découvrir assez tôt.
• Resource Load Duration : C'est le temps qu'il faut pour télécharger réellement le fichier de ressource LCP (l'image, la police ou la vidéo). Cette phase concerne uniquement la taille du fichier et les conditions du réseau. Optimiser signifie utiliser des formats d'image modernes comme AVIF ou WebP, implémenter des images responsives avec srcset, et servir les actifs via un CDN avec une compression appropriée.
• Element Render Delay : C'est le délai final. Il mesure le temps entre le moment où la ressource LCP a fini de se télécharger et celui où l'élément est entièrement rendu à l'écran. Ce délai est presque toujours causé par le main thread du navigateur bloqué par d'autres tâches, en particulier le traitement JavaScript. Le CSS bloquant le rendu et les scripts synchrones sont les causes les plus fréquentes.

Chacun de ces domaines d'intervention peut être optimisé pour améliorer le Largest Contentful Paint. Pour comprendre les étapes à suivre, lisez Corriger et identifier les problèmes de Largest Contentful Paint (LCP).

Erreurs LCP courantes

Après avoir analysé des millions de chargements de pages via CoreDash, trois erreurs LCP apparaissent bien plus souvent que toutes les autres. Les éviter permettra à la plupart des sites d'obtenir un score LCP réussi.

Erreur 1 : Lazy-Loading de l'image LCP

Ajouter loading="lazy" à votre image hero est l'erreur LCP la plus courante. Le lazy loading indique au navigateur de retarder intentionnellement le téléchargement de l'image jusqu'à ce qu'elle apparaisse dans le viewport lors du défilement. Pour votre image LCP (qui est déjà dans le viewport), cela crée un délai totalement inutile. Selon les données CrUX, 16 % des sites mobiles font cette erreur. Les données CoreDash montrent que les images LCP chargées en différé ont un p75 de 720 ms avec 4,3 % d'expériences médiocres, contre 364 ms et 0 % de médiocres pour les images préchargées. Lisez notre guide complet sur comment corriger une image LCP chargée en différé.

Erreur 2 : Ne pas précharger l'image LCP

Même sans lazy loading, de nombreux sites ne signalent pas assez tôt l'image LCP au navigateur. Si l'URL de l'image n'est découverte qu'après l'analyse du CSS ou l'exécution du JavaScript, le navigateur perd des centaines de millisecondes avant même de commencer le téléchargement. Le correctif consiste à ajouter un indice de préchargement (preload) dans le <head> de votre document :

<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

Cela indique au navigateur de commencer le téléchargement de l'image immédiatement, sans attendre le CSS ou les calculs de mise en page. Combinez-le avec fetchpriority="high" pour un impact maximal. Apprenez-en plus dans notre guide sur le préchargement de l'image LCP.

Erreur 3 : Utiliser une image d'arrière-plan CSS pour le LCP

Les images d'arrière-plan CSS chargées via background-image: url(...) sont invisibles pour le preload scanner du navigateur. Le navigateur ne peut pas les découvrir avant d'avoir téléchargé le HTML, analysé le CSS et construit l'arbre de rendu (render tree). Cela ajoute un retard de chargement de ressource significatif. Selon les données CrUX, 9 % des pages mobiles utilisent une image d'arrière-plan CSS comme élément LCP. La solution est d'utiliser une balise <img> standard à la place, avec l'attribut fetchpriority="high" :

<img src="/img/hero.webp"
     alt="Texte alt descriptif"
     width="1200"
     height="600"
     fetchpriority="high">

L'attribut fetchpriority="high" est un signal direct au navigateur que cette image est la ressource la plus prioritaire de la page. Comme l'a démontré l'étude de cas Google Flights, ce seul attribut peut réduire le LCP de 700 ms. Pour une compréhension plus approfondie, consultez notre guide sur la priorisation des ressources.

Comment mesurer le Largest Contentful Paint

Le Largest Contentful Paint (LCP) peut être mesuré avec du JavaScript pur, des données de laboratoire (Lab), et des outils de terrain (Field). Les deux ont leurs avantages et inconvénients.

Mesurer le Largest Contentful Paint avec JavaScript

Pour mesurer le Largest Contentful Paint (LCP) en utilisant JavaScript, l'API Performance Observer offre une solution rapide. L'extrait de code suivant montre comment capturer le timing LCP et les informations sur l'élément :

new PerformanceObserver((list) => {
    const lcpEntry = list.getEntries().at(-1);
    console.log('Valeur LCP : ', lcpEntry.startTime);
    console.log('Élément LCP : ', lcpEntry.element, lcpEntry.url);
  }).observe({ type: 'largest-contentful-paint', buffered: true });

Cet extrait suit l'entrée LCP au fur et à mesure qu'elle est rapportée, affichant son horodatage et les détails de l'élément dans la console. Pour des informations plus approfondies, envisagez d'utiliser la Web Vitals Library.

Mesurer le Largest Contentful Paint (LCP) dans les Chrome DevTools

1. Ouvrez les Chrome DevTools en appuyant sur Ctrl+Maj+I (ou Cmd+Option+I sur Mac).
2. Accédez à l'onglet Performance.
3. Rechargez la page pour voir les Core Web Vitals.

L'onglet Performance des DevTools affiche désormais des informations sur les Core Web Vitals, y compris le timing et l'élément du Largest Contentful Paint.

Mesurer le Largest Contentful Paint avec les outils Lab et Field

Soyons clairs : les données de laboratoire (Lab) et de terrain (Field) servent deux objectifs différents. Vous avez besoin des deux.

• Les données de terrain (RUM et CrUX) sont les seules données qui comptent réellement pour réussir les Core Web Vitals. C'est ce que vos utilisateurs réels vivent. Google utilise ces données issues de son ensemble de données CrUX. Vous commencez ici pour savoir si vous avez un problème.
• Les données de laboratoire (Lighthouse, etc.) sont un test contrôlé. Ce n'est pas ce que Google utilise pour le classement, mais c'est essentiel pour le débogage. Vous utilisez cela pour comprendre pourquoi vous avez un problème.

Voici un guide rapide des outils essentiels :

Améliorer le Largest Contentful Paint

Optimiser le LCP nécessite une approche systématique qui traite les quatre phases. Tout ce qui se passe avant que l'élément LCP ne soit affiché, que ce soit lié au réseau ou intensif pour le processeur, peut avoir un impact sur le score LCP. Ne vous contentez pas de poursuivre un seul correctif ; comprenez toute la chaîne. Voici la stratégie de haut niveau :

• Optimiser le TTFB : Votre serveur doit être rapide. Si votre TTFB est lent, rien d'autre n'a d'importance. Cela implique la mise en cache côté serveur, l'utilisation d'un CDN et un code backend efficace. En savoir plus dans notre guide d'optimisation du TTFB.
• Éliminer le Resource Load Delay : Assurez-vous que l'élément LCP est dans le HTML initial afin que le preload scanner du navigateur puisse le trouver instantanément. Évitez les images d'arrière-plan CSS pour le LCP. Préchargez les images critiques qui sont découvertes tardivement. Apprenez comment dans notre guide sur la correction du Resource Load Delay.
• Réduire le Resource Load Time : Réduisez la taille du fichier LCP. Cela signifie utiliser des formats d'image modernes comme AVIF, des images responsives et une compression appropriée. Consultez notre guide complet sur comment optimiser l'image LCP. Vous pouvez également lire comment nous avons réduit le LCP de 70 % sur un projet réel.
• Raccourcir l'Element Render Delay : Arrêtez de bloquer le main thread. Différez le JavaScript non critique, découpez les tâches longues et minimisez le CSS bloquant le rendu. Ceci est couvert dans notre guide sur la correction de l'Element Render Delay.

Guides connexes

Cette page d'accueil couvre le Largest Contentful Paint de manière générale. Pour des conseils détaillés et pratiques sur chaque aspect de l'optimisation du LCP, explorez ces guides dédiés :

• Corriger et identifier les problèmes de LCP : Un guide de diagnostic étape par étape pour trouver exactement ce qui cause votre LCP lent, à l'aide de Chrome DevTools, WebPageTest et CoreDash.
• Optimiser l'image LCP : Tout sur les formats d'image, les images responsives, la compression et le service de l'image optimale pour chaque appareil.
• Resource Load Delay : Comment s'assurer que le navigateur découvre votre ressource LCP le plus tôt possible, y compris le préchargement, la fetchpriority et l'évitement des images d'arrière-plan CSS.
• Resource Load Duration : Réduire le temps de téléchargement réel de la ressource LCP grâce à l'optimisation de la taille du fichier, la configuration du CDN et une compression moderne.
• Element Render Delay : Éliminer le délai entre le téléchargement de la ressource et le rendu à l'écran en réduisant le blocage du main thread par le JavaScript et le CSS.