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

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

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

Historique du Largest Contentful Paint

À première vue, 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 nécessaire au chargement de la page » ?

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

Lors du chargement d'une page, plusieurs moments influencent la perception de vitesse de l'utilisateur. Par exemple, le délai du serveur (Time to First Byte), le moment où le premier contenu devient visible (First Contentful Paint), le moment où le viewport visible semble complet (Largest Contentful Paint) ou le moment où la page devient interactive (quand il devient possible de cliquer sur un lien). Ce sont tous des jalons du chargement où le site peut sembler rapide ou lent !

Le Largest Contentful Paint (LCP) a été choisi parce qu'il se concentre sur l'expérience du visiteur. Lorsque le LCP se produit, on peut considérer que le visiteur estime que la page a fini de charger (même si des processus en arrière-plan continuent de tourner). 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 les performances de chargement, mais ils capturent des moments fondamentalement différents dans la chronologie de chargement de la page. Le FCP se déclenche dès que le navigateur affiche le premier pixel de contenu, comme une petite barre de navigation ou un indicateur de chargement. Le LCP se déclenche lorsque le plus grand élément significatif s'affiche dans le viewport.

Voyez les choses ainsi : le FCP indique que la page a commencé à charger ; le LCP indique que la page semble chargée. Google a choisi le LCP comme Core Web Vital parce qu'il reflète plus fidèlement la vitesse perçue par les utilisateurs.

Pour la plupart des sites web, optimiser le LCP doit être la priorité. Si votre LCP est rapide, votre FCP le sera presque toujours aussi, car le FCP intervient 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 activité

Le Largest Contentful Paint est l'un des trois Core Web Vitals. En tant que tel, le Largest Contentful Paint est important pour le SEO, mais surtout, le LCP est crucial pour l'UX. Les visiteurs n'aiment pas attendre. Avec la part croissante du trafic mobile (généralement plus lent que le trafic sur ordinateur), optimiser le Largest Contentful Paint est indispensable.

• Pour le SEO. Oui, Google cherche à proposer les meilleures pages dans ses résultats de recherche. Le LCP fait partie des Core Web Vitals de Google. Et Google indique clairement que la vitesse du site est un facteur de classement.
• Pour les visiteurs : selon une étude de Google, la probabilité d'abandon double lorsque le temps de chargement atteint 3 secondes. Vous en avez sûrement fait l'expérience. Rien n'est plus agaçant qu'un site web lent. Vous quitterez rapidement une page lente.
• Autres raisons : la vitesse de vos pages est un facteur de votre Ad Score Google. Cela vous permet d'acheter vos publicités moins cher. De plus, réussir le test des Core Web Vitals est l'une des conditions requises pour apparaître dans le carrousel des « Une » de Google.

Un LCP rapide donne l'impression que la page charge vite. Le visiteur reste sur la page.

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

Vodafone Italie a mené une expérience contrôlée pour optimiser 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, mais d'un test A/B direct prouvant qu'un chargement perçu comme 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 render blocking. Lisez l'étude de cas complète de Vodafone sur web.dev.

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

L'équipe Google Flights a ajouté fetchpriority="high" à son image principale et a vu son LCP s'améliorer de 700 millisecondes. Ce simple 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. Comme le montre l'expérience de Google Flights, l'impact peut être spectaculaire. En savoir plus sur la priorisation des ressources pour les Core Web Vitals.

Quels éléments sont pris en compte pour le LCP ?

Tous les éléments ne sont pas éligibles comme éléments LCP. Le plus grand élément de contenu doit être affiché dans le viewport avant que l'utilisateur n'interagisse avec la page.

Il doit s'agir de :

• Un élément <img>.
• Un élément <image> imbriqué dans un <svg>.
• Un élément <video> (l'image d'affiche ou la première image de la vidéo, selon la première occurrence, est utilisée).
• Un élément avec une image de fond chargée via la fonction CSS url(). (Note : c'est un anti-pattern pour l'optimisation du LCP, car cela rend l'image invisible pour le scanner de préchargement du navigateur. Lisez notre guide sur le chargement différé des images de fond).

• Un élément de niveau bloc contenant des nœuds de texte ou d'autres éléments de texte inline (pour des éléments inline comme <span>, l'élément block-level le plus proche, comme <div> ou <p>, est pris en compte).

Actuellement, certains éléments sont exclus des candidats LCP, comme les éléments masqués avec opacity: 0, les images qui occupent 100 % du viewport (images de couverture) et les espaces réservés (images à faible entropie). Gardez à l'esprit que cela peut évoluer avec les spécifications !

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

Le LCP identifie le plus grand élément de contenu visible dans le viewport et calcule sa taille selon des règles précises. Ces règles garantissent cohérence et précision, 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, la taille considérée est rognée.
• Sans bordure, padding ni marge : pour tous les éléments, les bordures, paddings et marges des textes et des images sont totalement ignorés.
• Taille du texte : les éléments textuels sont mesurés selon le plus petit rectangle pouvant être dessiné autour du ou des nœuds de texte.
• Taille de l'image : pour les images, c'est la plus petite valeur entre les dimensions intrinsèques (largeur et hauteur d'origine) et la taille d'affichage (la taille à l'écran) qui sert à calculer la taille de l'élément LCP.
• Seule la première taille compte : en cas de modification de la mise en page ou de la taille d'un élément, seule sa taille initiale est prise en compte.
• Les éléments supprimés restent inclus : lorsqu'un élément est retiré du DOM, il reste un candidat LCP.

Nature dynamique du LCP

Le Largest Contentful Paint (LCP) est une métrique dynamique. Le rendu d'une page étant parfois complexe et progressif, il est normal que l'élément LCP change pendant le chargement. Avant la première interaction de l'utilisateur, l'observateur de performance du navigateur identifie tous les candidats LCP potentiels. Si un nouvel élément s'affiche, qu'il est visible dans le viewport et plus grand que l'élément LCP précédemment identifié, il devient le nouveau LCP.

Ce qu'il faut retenir des field data LCP : chez CoreDash, nous suivons des millions d'entrées LCP chaque jour. Il s'avère que sur mobile, l'élément LCP est souvent un élément textuel, comme un paragraphe ou un titre. En moyenne (ou plus précisément au 75e centile), les Core Web Vitals passent avec succès lorsque l'élément LCP est un nœud de texte ou une image classique. En revanche, lorsque l'élément LCP est une image de fond, une vidéo ou une image chargée en lazy loading, les Core Web Vitals ont tendance à échouer.

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

Pour réussir le test des Core Web Vitals sur le Largest Contentful Paint, au moins 75 % de vos visiteurs doivent obtenir un « bon » score LCP. Un score LCP compris entre 0 et 2,5 secondes est considéré comme bon. Entre 2,5 et 4 secondes, il nécessite des améliorations, et au-delà de 4 secondes, il est jugé médiocre.

Ce que révèlent les données LCP du monde réel

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

LCP image vs LCP texte

Les pages dont l'élément LCP est une image ont un LCP au 75e centile de 744 ms, soit près de deux fois plus lent que les éléments LCP textuels à 388 ms. Cela confirme que l'optimisation des images est le levier le plus puissant pour améliorer vos scores LCP. Si votre élément LCP est une image, vous devez être particulièrement agressif sur son optimisation.

L'impact du préchargement et du lazy loading

Les images LCP préchargées obtiennent 100 % de « bons » scores, avec un 75e centile à 364 ms. À l'inverse, les images LCP en lazy loading sont parmi les plus lentes à 720 ms, avec 4,3 % de chargements de pages classés comme « médiocres ». Les images non préchargées ne font guère mieux à 752 ms. La conclusion est évidente : préchargez votre image LCP et ne la chargez jamais en lazy loading.

LCP mobile vs ordinateur

Le LCP sur mobile (764 ms au 75e centile) est deux fois plus lent que sur ordinateur (380 ms). Cet écart est dû à la lenteur des réseaux mobiles et à la puissance limitée des processeurs des smartphones. Google pratiquant l'indexation mobile-first, l'optimisation du LCP mobile doit être votre priorité.

Statistiques globales du LCP

Selon l'HTTP Archive Web Almanac 2025, 62 % des pages mobiles dans le monde obtiennent 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 goulet d'étranglement pour les scores globaux des Core Web Vitals. De plus, 73 % des éléments LCP sur mobile sont des images, et 16 % des sites mobiles commettent l'erreur de charger leur image LCP en lazy loading.

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

Selon Google, le Largest Contentful Paint se décompose en 4 sous-parties. Identifier la phase responsable du goulet d'étranglement est essentiel pour optimiser efficacement, car chaque phase requiert une correction totalement différente. Un Time to First Byte (TTFB) lent nécessite un travail côté serveur, tandis qu'un long délai de chargement de la ressource (Resource Load Delay) impose 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 répartition est la clé pour diagnostiquer et corriger efficacement les problèmes de LCP.

Voici le détail de ces quatre phases :

• Time to First Byte (TTFB) : c'est le temps de réponse pur du serveur. Il englobe tout, de la résolution DNS à la réception du premier octet du document HTML par le navigateur, en passant par la connexion TCP/TLS. Un TTFB lent est un problème fondamental qui pénalisera systématiquement votre LCP. Sur le web, les sites ayant un mauvais LCP passent en moyenne 2,27 secondes uniquement sur le TTFB, soit presque la totalité du seuil des 2,5 secondes. L'optimisation du TTFB passe par la mise en cache côté serveur, la configuration d'un CDN et un code backend efficace.
• Resource Load Delay (délai de chargement de la ressource) : c'est l'écart de découverte (« discovery gap »). Il mesure le temps qui s'écoule entre la fin du TTFB et le début effectif du téléchargement de la ressource LCP par le navigateur. Un long délai ici signifie que le navigateur a découvert la ressource LCP trop tard. C'est le symptôme classique de l'utilisation d'images de fond CSS (que le scanner de préchargement ne peut pas détecter) ou du rendu côté client (où l'élément LCP n'apparaît qu'après l'exécution de JavaScript). La solution consiste à s'assurer que votre élément LCP figure dans l'HTML initial et à précharger l'image LCP si le navigateur ne peut pas la découvrir assez tôt.
• Resource Load Duration (temps de chargement de la ressource) : c'est le temps nécessaire au téléchargement physique du fichier de la ressource LCP (l'image, la police ou la vidéo). Cette phase dépend entièrement de la taille du fichier et des conditions réseau. Optimiser cette phase implique d'utiliser des formats d'image modernes comme AVIF ou WebP, de mettre en œuvre des images responsives avec srcset, et de distribuer les ressources via un CDN avec une compression adaptée.
• Element Render Delay (délai de rendu de l'élément) : c'est le retard final. Il mesure le temps entre la fin du téléchargement de la ressource LCP et son affichage complet à l'écran. Ce délai est presque toujours causé par le blocage du main thread du navigateur par d'autres tâches, en particulier le traitement du JavaScript. Les feuilles de style CSS render blocking et les scripts synchrones en sont les causes les plus fréquentes.

Chacun de ces domaines clés peut être optimisé pour améliorer le Largest Contentful Paint. Pour comprendre les étapes à suivre, lisez notre guide Identifier et corriger les problèmes de Largest Contentful Paint (LCP).

Erreurs courantes liées au LCP

Après avoir analysé des millions de chargements de pages avec CoreDash, trois erreurs LCP reviennent beaucoup plus souvent que les autres. Les éviter permettra à la plupart des sites de réussir le test du LCP.

Erreur 1 : charger l'image LCP en lazy loading

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

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

Même sans lazy loading, de nombreux sites n'indiquent pas assez tôt au navigateur l'existence de l'image LCP. Si l'URL de l'image n'est découverte qu'après l'analyse du CSS ou l'exécution de JavaScript, le navigateur perd des centaines de millisecondes avant même de lancer le téléchargement. La solution consiste à ajouter une instruction de préchargement (preload) dans la balise <head> de votre document :

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

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

Erreur 3 : utiliser une image de fond CSS pour le LCP

Les images de fond CSS chargées via background-image: url(...) sont invisibles pour le scanner de préchargement du navigateur. Ce dernier ne peut les découvrir qu'après avoir téléchargé le HTML, analysé le CSS et construit l'arbre de rendu (render tree). Cela ajoute un délai de chargement important. Selon les données CrUX, 9 % des pages mobiles utilisent une image de fond CSS comme élément LCP. La solution consiste à utiliser une balise <img> standard à la place, avec l'attribut fetchpriority="high" :

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

L'attribut fetchpriority="high" est un signal direct envoyé au navigateur pour lui indiquer que cette image est la ressource la plus prioritaire de la page. Comme l'a montré l'étude de cas Google Flights, ce simple attribut peut réduire le LCP de 700 ms. Pour approfondir le sujet, consultez notre guide sur la priorisation des ressources.

Comment mesurer le Largest Contentful Paint

Le Largest Contentful Paint (LCP) peut être mesuré via du JavaScript pur, des lab data ou des outils de field data. Les deux approches ont leurs avantages et inconvénients.

Mesurer le Largest Contentful Paint en JavaScript

Pour mesurer le Largest Contentful Paint (LCP) en JavaScript, l'API Performance Observer offre une solution rapide. Le code ci-dessous montre comment récupérer le temps LCP et les informations de l'élément :

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

Ce code suit l'entrée LCP au fur et à mesure de son signalement, affichant son horodatage et les détails de l'élément dans la console. Pour des analyses plus poussées, vous pouvez utiliser la bibliothèque Web Vitals.

Mesurer le Largest Contentful Paint (LCP) dans Chrome DevTools

1. Ouvrez 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 afficher les Core Web Vitals.

L'onglet Performance de DevTools affiche les informations relatives aux Core Web Vitals, y compris le temps de rendu et l'élément du Largest Contentful Paint.

Mesurer le Largest Contentful Paint avec des outils de lab data et de field data

Soyons clairs : les lab data et les field data répondent à deux objectifs différents. Vous avez besoin des deux.

• Les field data (RUM et CrUX) sont les seules données qui comptent vraiment pour réussir le test des Core Web Vitals. Elles représentent l'expérience de vos utilisateurs réels. Google utilise ces données issues de son jeu de données CrUX. C'est par là que vous commencez pour savoir si vous avez un problème.
• Les lab data (Lighthouse, etc.) proviennent de tests contrôlés. Google ne s'en sert pas pour le classement, mais elles sont indispensables pour le débogage. Vous les utilisez pour comprendre la cause de votre problème.

Voici un guide rapide des outils indispensables :

Améliorer le Largest Contentful Paint

L'optimisation du LCP exige une approche systématique ciblant les quatre phases. Tout événement survenant avant l'affichage de l'élément LCP, qu'il soit lié au réseau ou au CPU, peut dégrader votre score LCP. Ne cherchez pas une correction isolée ; comprenez l'ensemble de la chaîne de chargement. Voici la stratégie globale :

• Optimiser le TTFB : votre serveur doit être rapide. Si votre TTFB est lent, rien d'autre ne compte. Cela passe par la mise en cache côté serveur, l'usage d'un CDN et un code backend optimisé. En savoir plus dans notre guide d'optimisation du TTFB.
• Éliminer le délai de chargement de la ressource (Resource Load Delay) : assurez-vous que l'élément LCP se trouve dans le code HTML initial afin que le scanner de préchargement du navigateur le repère instantanément. Évitez les images de fond CSS pour le LCP. Préchargez les images critiques découvertes tardivement. Découvrez comment procéder dans notre guide pour résoudre le Resource Load Delay.
• Réduire le temps de chargement de la ressource (Resource Load Duration) : réduisez la taille du fichier LCP. Utilisez pour cela des formats d'image modernes comme AVIF, des images responsives et une compression adaptée. Consultez notre guide complet sur comment optimiser l'image LCP. Vous pouvez également découvrir comment nous avons réduit le LCP de 70 % sur un projet réel.
• Raccourcir le délai de rendu de l'élément (Element Render Delay) : arrêtez de bloquer le main thread. Différez le JavaScript non critique, segmentez les long tasks et réduisez le CSS render blocking. Ce sujet est traité dans notre guide pour résoudre l'Element Render Delay.

Guides associés

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

• Identifier et corriger les problèmes de LCP : un guide de diagnostic pas à pas pour trouver précisément l'origine de votre LCP lent avec Chrome DevTools, WebPageTest et CoreDash.
• Optimiser l'image LCP : tout ce qu'il faut savoir sur les formats d'image, les images responsives, la compression et la diffusion de l'image idéale pour chaque appareil.
• Resource Load Delay : comment veiller à ce que le navigateur découvre votre ressource LCP le plus tôt possible, notamment avec le préchargement, fetchpriority et en évitant les images de fond CSS.
• Resource Load Duration : comment réduire le temps de téléchargement effectif de la ressource LCP via l'optimisation de la taille des fichiers, la configuration d'un CDN et les techniques de compression modernes.
• Element Render Delay : comment éliminer le délai entre le téléchargement de la ressource et son affichage à l'écran en limitant le blocage du main thread par le JavaScript et le CSS.