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

Comment le LCP est-il calculé ?

Chrome mesure le LCP d'un chargement de page entre le moment où le visiteur demande la page et celui où le plus grand élément dans le viewport est affiché. Il signale un nouveau candidat chaque fois qu'il affiche un élément plus grand, jusqu'au premier tap, scroll ou appui sur une touche de la part du visiteur ; le dernier donne la valeur du LCP.

L'élément LCP peut donc changer : le titre est le plus grand pendant un instant, puis la photo hero le remplace. « Last contentful paint » est à moitié vrai et « least contentful paint » est faux : seul le dernier candidat compte, et c'est toujours le plus grand affiché jusque-là. Google évalue le 75e percentile de ces valeurs sur 28 jours.

Pourquoi le LCP se base-t-il sur le plus grand élément ?

Sur une page moderne, il n'y a pas un instant précis où le chargement est terminé : le lazy loading et les scripts continuent d'effectuer des requêtes tant que le visiteur reste sur la page. Le LCP mesure le moment où le plus grand élément, le contenu principal, est affiché à l'écran. L'équipe des métriques de vitesse de Chrome l'a conçu autour d'une question : « quand le contenu principal de la page devient-il visible pour l'utilisateur ? »

LCP vs FCP : quelle est la différence ?

Le First Contentful Paint (FCP) est le moment où le navigateur affiche le premier texte ou la première image. Le Largest Contentful Paint (LCP) est le moment où il affiche le plus grand élément dans le viewport. Le FCP indique que la page a commencé à charger. Le LCP indique que la page semble chargée.

Un FCP rapide avec un LCP tardif pointe vers l'image LCP ou vers un élément qui la masque. Quand les deux sont en retard, commencez par le serveur et les fichiers du head.

Pourquoi le LCP est-il important ?

La plupart des sites qui échouent aux Core Web Vitals échouent sur le LCP : dans le rapport CrUX de septembre 2026, 68,3 % des origines avaient un bon LCP, contre 81,7 % pour le CLS et 85,4 % pour l'INP. Google utilise le LCP des vrais visiteurs Chrome dans ses signaux de classement liés à l'expérience sur la page.

Quels éléments peuvent être l'élément LCP ?

L'élément LCP est le plus grand de ces éléments dans le viewport : un <img>, un <image> dans un <svg>, le poster ou la première image d'une vidéo, un élément avec un arrière-plan CSS url(), ou un bloc de texte.

Chrome ignore les éléments avec une opacité de 0, les images qui couvrent tout le viewport et les images à faible entropie : depuis Chrome 112, une image avec moins de 0,05 bit de données d'image par pixel affiché est considérée à faible entropie. La taille d'un candidat suit trois règles :

• Seule la partie située dans le viewport compte, sans le padding, la bordure ni la marge.
• Pour le texte, on compte le plus petit rectangle entourant ses lignes de texte.
• Pour une image, on retient la plus petite valeur entre sa taille réelle en pixels et sa taille à l'écran.

Une apparition en fondu depuis une opacité de 0 est comptabilisée quand le fondu se termine ; toute la durée du fondu s'ajoute donc au LCP.

Comment identifier l'élément LCP ?

Ouvrez le panneau Performance dans les DevTools de Chrome : avant même d'enregistrer quoi que ce soit, il indique l'élément LCP de la page. PageSpeed Insights et Lighthouse l'affichent sous l'encadré LCP breakdown, et CoreDash rapporte le LCP par élément pour les vrais visiteurs. Vérifiez séparément mobile et desktop : sur un smartphone, un titre peut être plus grand que la partie visible de la photo.

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

Un bon LCP est de 2,5 secondes ou moins pour au moins 75 % des chargements de page. Entre 2,5 et 4 secondes, il doit être amélioré, et au-delà de 4 secondes, il est médiocre.

Le LCP au p75 (75e percentile) représente le temps que trois chargements sur quatre atteignent ou améliorent. Consultez d'abord l'onglet mobile de PageSpeed Insights : les field data affichées en haut indiquent le p75 des 28 derniers jours. Lorsque la Search Console signale « Problème LCP : plus de 2,5 s (mobile) », un groupe d'URL dépasse 2,5 secondes pour les visiteurs sur mobile ; Identifier et corriger les problèmes de LCP permet de remonter de ce rapport à la cause. Dans Lighthouse, le LCP pèse pour un quart du score de Performance, mais Google base son classement sur le LCP obtenu par les vrais visiteurs.

Que révèlent les données des vrais visiteurs sur un LCP lent ?

D'après le State of Web Vitals, les sites dont l'image LCP provient d'une feuille de style réussissent moins souvent le LCP sur mobile que ceux dont l'image se trouve dans le HTML : 77 % contre 84 %. C'est une corrélation. Dans ces mêmes données, 70 % des sites WordPress réussissent le LCP sur mobile, contre 95 % des sites Shopify.

CoreDash a mesuré les chargements de page réels sur 149 projets au cours des 28 jours précédant le 7 novembre 2026. Globalement, leur p75 de LCP était d'environ 1,8 seconde sur mobile et 1,7 seconde sur desktop. Pour un LCP d'image sur mobile, le p75 de chaque phase s'élevait à 580 ms pour le time to first byte, 350 ms pour le resource load delay, 130 ms pour la resource load duration et 550 ms pour l'element render delay. Chaque valeur représente le p75 de cette seule phase ; la somme des quatre ne donne donc pas le LCP.

Pour vos propres visiteurs, ouvrez le LCP dans CoreDash sur mobile et consultez le Phase breakdown.

Phase breakdown de CoreDash : la barre la plus longue indique la partie à corriger en premier.

Quelles sont les quatre parties (phases) du LCP ?

Le LCP d'une image se décompose en quatre parties successives : time to first byte, resource load delay, resource load duration et element render delay. Un LCP basé sur du texte ne comporte que la première et la dernière : l'attente des feuilles de style et d'une police web compte comme render delay.

De gauche à droite : l'attente du HTML, l'attente avant la requête de l'image, le téléchargement, et l'attente avant l'affichage de l'image.

D'après le State of Web Vitals, le time to first byte représente la part la plus importante du LCP sur mobile pour deux sites sur trois ; le téléchargement de l'image ne l'est que pour environ un site sur cinquante. Compresser l'image LCP est le premier réflexe, mais sur la plupart des sites, cela ne réduit que la plus petite partie.

Lighthouse et DevTools affichent ces phases dans l'encadré LCP breakdown (anciens noms : « Largest Contentful Paint element », « LCP by phase »).

Sur une page de test reproduisant un site WordPress d'agence immobilière avec Elementor et un slider, corriger une phase à la fois a fait passer le LCP sur un mobile bridé de 6,70 à 2,18 secondes. Convertir la photo en WebP a raccourci le téléchargement de 2,5 secondes, dont 1,9 seconde a simplement basculé dans l'element render delay, car une animation d'apparition bloquait la photo jusqu'à la fin de son fondu. LCP breakdown détaille chaque étape.

Comment identifier ce qui ralentit le LCP ?

Commencez par les field data sur mobile : quelles pages échouent au LCP pour les vrais visiteurs (la Search Console les regroupe), et laquelle des quatre phases y est la plus longue (CoreDash affiche les deux). Surveillez aussi la tendance : un saut brutal signale un déploiement, une hausse progressive l'accumulation de scripts tiers. Testez ensuite l'une de ces pages :

1. PageSpeed Insights, onglet mobile : le test LCP le plus rapide, avec le LCP des field data et un audit Lighthouse.
2. Chrome DevTools : enregistrez une trace dans le panneau Performance sur un mobile bridé et ouvrez LCP breakdown dans la barre latérale Insights. Diagnostiquer le LCP avec Chrome DevTools détaille l'analyse de la trace.

Le panneau Performance avant l'enregistrement : le LCP local, le p75 des field data et l'élément LCP.

Ce snippet consigne chaque candidat LCP avec son délai et son élément ; le dernier est le LCP. Au-delà d'une vérification rapide, utilisez la bibliothèque web-vitals.

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 });

Lighthouse charge la page une seule fois, sur un mobile simulé, alors que Google classe d'après le 75e percentile de 28 jours de visites réelles. C'est le schéma que je retrouve sur presque tous les audits : la machine du développeur passe, le p75 de CrUX échoue. Dans PageSpeed Insights, les lignes du LCP breakdown proviennent d'un chargement de test rapide ; elles ne correspondent donc pas à la somme de son LCP. Lab data et field data explique à quoi sert chaque chiffre.

Comment optimiser un LCP lent ?

Corrigez d'abord la plus grande des quatre phases. Sur la plupart des sites, il s'agit du time to first byte : commencez donc par un cache de page. Vient ensuite l'image LCP que le navigateur découvre trop tard ; un fichier image plus léger est généralement ce qui aide le moins.

Un serveur lent (time to first byte)

Activez un cache de page dans l'extension de cache ou chez l'hébergeur pour que le serveur renvoie une copie enregistrée de la page. Les utilisateurs connectés, un cookie de panier et un paramètre d'URL inconnu contournent souvent cette copie, et chaque redirection ajoute un aller-retour réseau. Côté développeur : mettez aussi le HTML en cache sur le CDN. Chaque composante du temps serveur est détaillée dans le guide Time to first byte.

Une image découverte trop tard par le navigateur (resource load delay)

Une balise <img> dans le HTML est demandée alors même que le HTML arrive encore. Une photo en arrière-plan d'une section, dans le script d'un slider ou avec loading="lazy" attend la feuille de style, le script ou le layout. Désactivez le lazy loading pour la première image, utilisez un élément image plutôt qu'un arrière-plan, et faites de la première slide une simple image.

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

Sur une page de test pour un hôtel, la même photo était affichée à 2,02 secondes sous forme d'<img> avec fetchpriority="high", et à 3,64 secondes avec loading="lazy". Lors d'un test sur Google Flights, fetchpriority="high" a fait passer le LCP de 2,6 à 1,9 seconde (web.dev). J'ai mesuré un LCP jusqu'à 30 % plus rapide grâce à cela. L'optimisation échoue quand une extension de lazy loading déplace l'URL dans data-src, ou quand un logo deux fois trop grand s'empare du fetchpriority="high" que WordPress accorde à la première grande image. Un preload, pour une photo qui ne peut pas être dans le HTML, nécessite lui aussi fetchpriority="high". LCP request discovery détaille la marche à suivre par plateforme.

Un fichier image trop lourd (resource load duration)

Servez les dimensions nécessaires à l'écran, en WebP ou AVIF ; une extension d'image comme Imagify ou ShortPixel se charge de la conversion. Un arrière-plan de section ou un slider envoie un seul et même fichier à tous les écrans, alors qu'un <img> avec un srcset permet au smartphone d'en choisir un plus petit :

<img src="hero-828.webp"
     srcset="hero-480.webp 480w, hero-828.webp 828w, hero-1200.webp 1200w"
     sizes="100vw" width="1200" height="800" fetchpriority="high" alt="...">

Une image LCP hébergée sur un autre domaine attend l'ouverture d'une connexion dédiée : déplacez-la sur votre propre domaine, et n'ajoutez un preconnect que si c'est impossible. Optimiser l'image LCP détaille les formats et les dimensions.

Une image qui attend d'être affichée (element render delay)

L'image LCP est téléchargée, mais la page la retient encore : animation d'apparition, slider masquant ses slides jusqu'à l'exécution de son script, scripts différés jusqu'au premier tap, ou snippet anti-flicker d'un test A/B. Désactivez l'animation d'apparition de la première section et affichez la première slide directement dans le HTML. Si la photo doit obligatoirement apparaître en fondu, démarrez-la quasi visible dans la feuille de style :

.hero {
  animation: fadeIn 1s both;
}
@keyframes fadeIn {
  from { opacity: 0.01; }
  to { opacity: 1; }
}

Avec Motion (Framer Motion) dans React, attribuez initial={false} à l'élément LCP. Dans une trace, la long task qui s'intercale entre le téléchargement et l'affichage est bien plus souvent due à un tag manager ou à un script de consentement qu'à votre propre code.

La photo attend aussi chaque requête render blocking. Maintenez chaque feuille de style render blocking sous les 15 ko compressés, fusionnez les plus petites et supprimez @import. Le Critical CSS, recommandation habituelle sur ce point, affiche la page avec une partie du CSS puis la restyle quand le reste arrive, sans compter que le CSS inliné est retéléchargé à chaque page vue. Un LCP textuel utilisant une police web peut attendre la police (Font display). Les réglages par page builder se trouvent dans LCP breakdown.

WordPress

• Cache de page : WP Rocket, LiteSpeed Cache ou l'hébergeur. Testez la page en étant déconnecté.
• Première image : Optimize Critical Images de WP Rocket, Exclude Leading Images de Perfmatters ou Viewport Images de LiteSpeed Cache la préservent du lazy loading. Dans Elementor, utilisez un widget Image plutôt qu'un arrière-plan de Container. L'extension de ce site, WP Core Web Vitals, apprend quelle est l'image LCP par taille d'écran auprès des visiteurs et la charge en premier, avec une priorité haute.
• Render delay : dans Elementor, réglez Advanced > Motion Effects > Entrance Animation sur None pour la première section. WP Rocket, Perfmatters et LiteSpeed Cache peuvent bloquer les scripts jusqu'au premier tap ou scroll ; si le script qui affiche la photo en fait partie, la photo attend cette action. Excluez les scripts du page builder de ce différé. Laissez le critical CSS et Remove Unused CSS désactivés : ils apportent plus d'ennuis que d'avantages.

Shopify

Le serveur, son cache et les formats d'image dépendent de Shopify ; les redirections et le thème dépendent de vous. Dawn, Horizon et les thèmes dérivés attribuent fetchpriority="high" à l'image de la première section : faites de la bannière la première section. Dans Theme settings > Animations, l'option « Reveal sections on scroll » de Dawn démarre son fondu depuis un état quasi visible ; avec un autre thème, désactivez-la et comparez l'element render delay. Une section hero construite en JavaScript par une application démarre tard quoi que fasse le thème : utilisez une section du thème.

La correction du LCP a-t-elle touché les vrais visiteurs ?

CoreDash affiche l'impact d'une correction jour après jour dans les données des vrais visiteurs : filtrez sur les pages modifiées, sur mobile. La Search Console examine les 28 derniers jours ; ainsi, deux semaines après la mise en ligne d'une correction, la moitié des données correspond toujours à l'ancien site. Il faut jusqu'à 28 jours pour que les signaux passent au vert.

Relancez Lighthouse et comparez les quatre phases avec le run précédant la correction : si l'une a baissé et qu'une autre a augmenté d'autant, l'image attend désormais autre chose.

Certains problèmes de LCP nécessitent plus qu'un réglage : un serveur ou un thème impossible à changer, ou une attente qui se déplace vers la phase suivante après chaque correction. Lors d'une power hour Core Web Vitals, nous analysons ensemble vos field data et la trace de votre template le plus lent, puis nous fixons quelle phase corriger en premier et comment procéder sur votre plateforme.