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 correspond au temps de rendu du plus grand élément de contenu (image, vidéo ou bloc de texte) affiché dans la partie visible de l'écran. La valeur du LCP est le temps en millisecondes entre la requête de la page et le moment où cet élément s'affiche au-dessus de la ligne de flottaison.

Certains l'appellent « last contentful paint ». Pourtant, seul le plus grand élément compte : un élément plus petit affiché plus tard ne change rien.

Histoire du Largest Contentful Paint

Pourquoi ne pas mesurer la vitesse de chargement comme « le temps que met la page à charger » ?

Parce que sur la plupart des sites modernes, impossible de dire quand la page a fini de charger. Avec le lazy loading et le chargement progressif, une page peut continuer à charger tant que le visiteur reste dessus. Un instant précis dans le temps ne décrit pas la vitesse d'une page.

Une page peut sembler lente à plusieurs moments pendant son chargement. Le serveur répond tard (Time to First Byte), rien ne s'affiche pendant un moment (First Contentful Paint), ou le hero reste un bloc gris alors que le reste est là (Largest Contentful Paint). Ou le premier clic ne fait rien.

Le LCP a été choisi parce qu'il suit ce que voit le visiteur. Dès que le LCP a lieu, la plupart des visiteurs considèrent que la page est prête, même si des scripts tournent encore. Cette métrique a été conçue pour répondre à une question : « Quand le contenu d'une page est-il visible ? ».

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 à des moments différents. Le FCP se déclenche dès que le navigateur affiche le premier pixel de contenu, qu'il s'agisse d'une petite barre de navigation ou d'un spinner de chargement. Le LCP se déclenche quand le plus grand élément significatif s'affiche dans le viewport.

Le FCP indique que la page a commencé à charger. Le LCP indique que la page semble chargée, et c'est pourquoi Google a fait du LCP un Core Web Vital.

Sur la plupart des sites, optimisez le LCP en priorité. Le FCP intervient toujours avant le LCP, donc un LCP rapide s'accompagne généralement d'un FCP rapide. En revanche, un FCP rapide ne dit pas grand-chose du LCP : une page peut afficher son en-tête à 0,8 seconde et son image hero à 4 secondes.

Pourquoi le LCP compte

En tant que Core Web Vital, le LCP compte pour le SEO. Il compte encore plus pour les visiteurs : personne n'aime attendre, et la majorité du trafic se fait sur mobile, là où les pages chargent plus lentement.

• Classement. Le LCP fait partie des Core Web Vitals de Google, et Google utilise la vitesse des pages comme facteur de classement.
• Visiteurs. Un visiteur qui reste devant un écran blanc ou un bloc gris à la place du hero s'en va. Le test de Vodafone ci-dessous le démontre en chiffres.
• Google Ads. L'expérience sur la page de destination fait partie du Quality Score. Une page de destination lente rend chaque clic plus cher.

Étude de cas : Vodafone (gain de 31 % sur le LCP, 8 % de ventes en plus)

Vodafone Italie a réparti son trafic à 50/50 entre l'ancienne page de destination et une version plus rapide, au design et au fonctionnement identiques. La version rapide faisait son rendu côté serveur plutôt que dans des widgets côté client, servait une image hero redimensionnée, différait les images sous la ligne de flottaison et utilisait des fichiers SVG et PNG plus légers. Le LCP est passé de 8,3 à 5,7 secondes (31 % plus rapide) et les ventes ont augmenté de 8 %. (Étude de cas Vodafone sur web.dev)

Test : Google Flights (fetchpriority a fait gagner 700 ms)

Lors d'un test sur la page de Google Flights, l'ajout de fetchpriority="high" sur l'image LCP a fait passer le LCP de 2,6 à 1,9 seconde. Sans cet attribut, Chrome demande les images avec une priorité basse et n'augmente cette priorité qu'une fois que le layout confirme la présence de l'image dans le viewport. Sur une page chargée, cela représente des centaines de millisecondes d'attente. 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. L'élément doit être affiché dans la partie visible de l'écran (le viewport) avant la première interaction de l'utilisateur avec la page.

Il doit s'agir de :

• 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, la première des deux étant retenue).
• Un élément avec une image d'arrière-plan chargée via la fonction CSS url(). Il est bien pris en compte, mais le preload scanner ne peut pas le voir, si bien que le navigateur découvre l'image trop tard. Plus de détails dans différer les images d'arrière-plan.

• Un élément de type bloc contenant des nœuds de texte ou d'autres éléments de texte inline (pour les éléments inline comme <span>, c'est l'élément de type bloc le plus proche, <div> ou <p>, qui est retenu).

Certains éléments sont ignorés : les éléments avec opacity: 0, les images qui couvrent tout le viewport (Chrome les traite comme un fond) et les images à faible entropie. Depuis Chrome 112, une image contenant moins de 0,05 bit de données par pixel affiché est ignorée et considérée comme un placeholder. Chrome fait évoluer ces règles régulièrement.

Comment la taille de l'élément LCP est calculée

Le navigateur calcule la taille de chaque candidat selon ces règles :

• 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 retenue est tronquée.
• Ni bordure, ni padding, ni marge : pour tous les éléments, les bordures, paddings et marges du texte et des images sont totalement ignorés.
• Taille du texte : les éléments de texte correspondent au plus petit rectangle pouvant entourer le ou les nœuds de texte.
• Taille de l'image : pour les images, le navigateur retient la plus petite valeur entre les dimensions intrinsèques (largeur et hauteur d'origine) et les dimensions d'affichage (taille à l'écran) pour calculer la taille de l'élément LCP.
• Seule la première taille compte : en cas de modification du layout ou de changement de taille d'un élément, seule la première taille est prise en compte pour le LCP.
• Les éléments supprimés restent inclus : lorsqu'un élément est retiré du DOM, il reste un candidat LCP.

L'élément LCP peut changer pendant le chargement

Le rendu d'une page se fait par étapes ; l'élément LCP change donc souvent pendant le chargement. Jusqu'à la première interaction utilisateur, le navigateur remonte chaque nouveau candidat LCP. Dès qu'un nouvel élément s'affiche, qu'il est visible dans le viewport et plus grand que le candidat précédent, il devient le nouvel élément LCP.

Ce que révèlent les field data du LCP : chez CoreDash, nous analysons des millions d'entrées LCP par jour. Sur mobile, l'élément LCP est souvent un paragraphe ou un titre. Sur desktop, le viewport plus large permet d'afficher une image plus grande ; une même page a donc souvent un élément LCP différent selon l'appareil. Vérifiez les deux avant de décider quoi corriger.

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

Pour valider le LCP au sein des Core Web Vitals, au moins 75 % des visites doivent afficher un bon LCP : moins de 2,5 secondes. Entre 2,5 et 4 secondes, le score est à améliorer ; au-delà de 4 secondes, il est médiocre. Regardez d'abord l'onglet mobile dans PageSpeed Insights. Les field data en haut indiquent le p75 des 28 derniers jours.

Ce que montrent les données de CoreDash

LCP image vs LCP texte

Les pages dont l'élément LCP est une image affichent un LCP au p75 de 744 ms, soit près de deux fois plus lent que celles avec un LCP textuel (388 ms). Cet écart vient principalement du retard avec lequel le navigateur découvre et demande l'image (voir les quatre phases ci-dessous).

L'impact du preloading et du lazy loading

Les images LCP préchargées affichent un p75 de 364 ms et aucun chargement classé médiocre. Les images LCP chargées en lazy loading montent à 720 ms, avec 4,3 % de chargements médiocres, et les images non préchargées atteignent 752 ms. N'utilisez jamais le lazy loading sur l'image LCP. Assurez-vous qu'elle soit demandée au plus tôt : directement dans le HTML avec fetchpriority="high", ou préchargée si ce n'est pas possible.

LCP sur mobile vs desktop

Le LCP sur mobile (764 ms au 75e percentile) est deux fois plus lent que sur desktop (380 ms). Les réseaux mobiles sont plus lents et les smartphones ont moins de puissance CPU. Google évalue le mobile et le desktop séparément, et c'est sur mobile que la plupart des sites échouent. Commencez donc par là.

Le LCP sur le web

Dans le rapport CrUX d'août 2026, 68,1 % des origines obtenaient un bon LCP, contre 66,7 % un an plus tôt. C'est toujours le score le plus bas des trois Core Web Vitals (INP à 85,3 %, CLS à 81,5 %) ; pour la plupart des sites, c'est donc le LCP qui fait la différence entre réussite et échec.

Le crawl de l'HTTP Archive apporte ce que CrUX ne collecte pas. Dans le Web Almanac 2025, l'élément LCP est une image sur 76 % des pages mobiles, et environ 16 % des pages la chargent en lazy loading. Seules 17 % des pages mobiles avec une image LCP utilisent fetchpriority="high". Et environ 2 % la préchargent.

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

D'après Google, le Largest Contentful Paint se décompose en 4 sous-parties. Chaque phase requiert un correctif différent : commencez donc par identifier laquelle est lente. Un Time to First Byte (TTFB) lent nécessite un travail côté serveur, tandis qu'un resource load delay élevé demande des modifications dans le HTML.

Le temps LCP est la somme de ces quatre phases :

• Time to First Byte (TTFB) : le temps de réponse du serveur. Il englobe tout : la résolution DNS, la connexion TCP/TLS et la réception du premier octet du document HTML par le navigateur. Un TTFB lent décale tout le reste. La cause classique est un HTML non mis en cache, qui force le serveur à reconstruire la page en PHP ou Node à chaque visite. Un CDN qui ne met pas en cache le HTML n'accélère que les images.
• Resource Load Delay : le délai entre la fin du TTFB et le début effectif du téléchargement de la ressource LCP par le navigateur. Un délai important signifie que le navigateur a découvert la ressource LCP trop tard. Cela provient souvent d'images d'arrière-plan en CSS (invisibles pour le preload scanner) ou d'un rendu côté client (où l'élément LCP n'apparaît qu'après l'exécution du JavaScript). Placez l'élément LCP dans le HTML initial, et préchargez l'image LCP uniquement si ce n'est pas faisable autrement.
• Resource Load Duration : le temps nécessaire pour télécharger la ressource LCP (l'image, la police ou la vidéo). Cette phase dépend du poids du fichier et du réseau : AVIF ou WebP, un srcset pour que les smartphones reçoivent une image adaptée à leur écran. Sur la plupart des sites, c'est la plus courte des quatre phases.
• Element Render Delay : le délai entre la fin du téléchargement de la ressource LCP et son affichage complet à l'écran. L'image est téléchargée, mais le navigateur ne peut pas encore l'afficher. Du CSS render blocking et du JavaScript qui bloque le main thread en sont les causes habituelles. Cas d'école : un script d'A/B testing qui masque la page tant qu'il n'a pas fini de charger.

Google a analysé des navigations réelles sur Chrome avec un LCP basé sur une image et a découpé le LCP au p75 selon ces phases. Voici l'origine médiane de chaque groupe :

Sur les sites dont le LCP est médiocre, le TTFB et le load delay représentent à eux deux plus de 3,5 secondes. Le téléchargement de l'image ne prend que 350 ms. La plupart des origines avec un LCP médiocre consacrent moins de 10 % de leur LCP au téléchargement de l'image LCP.

Pour identifier et corriger chacune de ces phases étape par étape, lisez Identifier et corriger les problèmes de Largest Contentful Paint (LCP).

Erreurs courantes sur le LCP

Erreur 1 : charger l'image LCP en lazy loading

L'attribut loading="lazy" ordonne au navigateur d'attendre que l'image soit proche du viewport avant de lancer le téléchargement. Or, l'image LCP se trouve déjà dans le viewport : le navigateur doit donc d'abord calculer le layout pour s'en apercevoir, et seulement ensuite démarrer le téléchargement. Les thèmes et page builders l'ajoutent souvent à toutes les images, y compris au hero. Supprimez-le de l'image LCP. C'est tout. Selon le Web Almanac 2025, environ 16 % des pages font cette erreur. Lisez le guide pour corriger une image LCP chargée en lazy loading.

Erreur 2 : l'image LCP est découverte trop tard

Un carrousel ou un hero au rendu côté client n'injecte l'URL de l'image qu'après le parsing du CSS ou l'exécution du JavaScript. Cela fait perdre des centaines de millisecondes avant même que le téléchargement ne débute. La meilleure solution reste une balise <img> standard dans le HTML. Quand ce n'est pas possible, ajoutez une directive de préchargement dans le <head> :

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

Le navigateur lance le téléchargement immédiatement. Un preload seul n'augmente pas la priorité : conservez fetchpriority="high" dessus, sinon l'image attendra toujours derrière les feuilles de style et les scripts. Plus d'informations dans le guide sur le préchargement de l'image LCP.

Erreur 3 : une image d'arrière-plan CSS comme élément LCP

Le preload scanner ne peut pas détecter une propriété background-image: url(...). Le navigateur ne découvre l'image qu'après avoir téléchargé le HTML, récupéré le CSS et appliqué la règle à l'élément concerné. Cela allonge le resource load delay. La solution consiste à utiliser une balise <img> classique à la place, avec l'attribut fetchpriority="high" :

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

Désormais, le preload scanner la découvre directement dans le HTML, et fetchpriority="high" la place en tête de file. Plus de détails dans le guide sur la priorisation des ressources.

Comment mesurer le Largest Contentful Paint

Mesurer le Largest Contentful Paint en JavaScript

La méthode la plus rapide est un PerformanceObserver. Ce snippet affiche la valeur et l'élément LCP dans la console :

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

Pour aller au-delà d'un simple contrôle rapide, utilisez la bibliothèque Web Vitals.

Mesurer le Largest Contentful Paint (LCP) dans Chrome DevTools

1. Ouvrez Chrome DevTools en appuyant sur Ctrl+Shift+I (ou Cmd+Option+I sur Mac).
2. Allez dans le panneau Performance. Il affiche directement le LCP de la page en cours, avec l'élément LCP associé.
3. Cliquez sur le bouton de rechargement dans le panneau pour enregistrer un profil. Le marqueur LCP dans la trace indique l'élément LCP et ses quatre phases.

Le guide complet, détaillant les éléments à analyser dans la trace, se trouve dans diagnostiquer le LCP avec Chrome DevTools.

Mesurer le Largest Contentful Paint avec les outils lab et field

Les lab data et les field data répondent à des besoins différents. Vous avez besoin des deux.

• Les field data (RUM et CrUX) servent à Google pour déterminer si vous validez le test. Elles reflètent l'expérience réelle des utilisateurs. Commencez par là pour savoir si vous avez un problème.
• Les lab data (Lighthouse, etc.) correspondent à un test contrôlé. Google ne s'en sert pas pour le classement, mais elles sont indispensables pour le débogage : elles expliquent pourquoi il y a un problème.

Les outils :

Améliorer le Largest Contentful Paint

Prenez votre template le plus lent sur mobile et analysez ses quatre phases LCP : CoreDash les affiche par page pour les visiteurs réels, DevTools pour un chargement unique. Dans les field data présentées plus haut, le TTFB et le load delay sont les principaux coupables sur presque tous les sites au LCP médiocre. Commencez donc par là.

Convertir l'image hero en AVIF est le premier réflexe de tout le monde. Sur un site avec un LCP de 4 secondes, le téléchargement complet prend environ 350 ms : un fichier plus léger n'en fera gagner qu'une fraction. Faites-le, mais en dernier.

Phase par phase :

• TTFB : mettez le HTML en cache, sur le serveur ou sur le CDN. Pour en savoir plus, consultez le guide d'optimisation du TTFB.
• Resource Load Delay : une balise <img> dans le HTML, pas de loading="lazy", fetchpriority="high". Voir comment corriger le Resource Load Delay.
• Resource Load Duration : un fichier plus léger, dimensionné pour l'appareil. Voir comment optimiser l'image LCP. Vous pouvez aussi découvrir comment nous avons réduit le LCP de 70 % sur un projet réel.
• Element Render Delay : moins de CSS render blocking, scripts différés, aucun snippet anti-flicker. Voir comment corriger l'Element Render Delay.

Guides associés

Chaque phase du LCP a son guide dédié :

• Identifier et corriger les problèmes de LCP : trouvez quelle phase est lente avec DevTools, WebPageTest et CoreDash.
• Diagnostiquer le LCP avec Chrome DevTools : le marqueur LCP dans un profil Performance.
• Optimiser l'image LCP : formats, dimensions et srcset.
• Resource Load Delay : faire demander l'image LCP au plus tôt.
• Resource Load Duration : le téléchargement en lui-même.
• Element Render Delay : quand l'image est reçue mais pas encore affichée.