Le LCP (Largest Contentful Paint) mesure le temps d'affichage du plus grand élément visible de la page : image hero, bloc de texte principal ou poster de vidéo. C'est la métrique de vitesse de chargement perçue des Core Web Vitals. Le seuil "Bon" de Google est inférieur à 2,5 secondes au 75e percentile des visites réelles. Un LCP lent vient presque toujours de quatre causes : serveur lent, ressources bloquantes, image découverte tardivement, image trop lourde.
Ce guide détaille comment mesurer le LCP, décomposer son temps en quatre sous-parties pour cibler le vrai problème, et appliquer les correctifs qui font réellement passer la métrique au vert.
Qu'est-ce que le LCP, concrètement ?
Le LCP répond à la question que se pose chaque visiteur : "la page s'affiche-t-elle vite ?". Techniquement, il mesure le délai entre le début de la navigation et le rendu du plus grand élément de contenu visible dans la zone d'affichage, tel que défini par la spécification officielle sur web.dev.
Les éléments candidats au LCP sont les images (<img>, images de fond via url()), les posters de <video> et les blocs de texte. Sur la grande majorité des sites, l'élément LCP est une image : le hero de la page d'accueil, le visuel produit d'une fiche e-commerce, l'image à la une d'un article.
Point important : le LCP est un des trois Core Web Vitals utilisés par le système Page Experience de Google comme signal de classement. Il est mesuré sur les visites réelles via le rapport CrUX, pas en laboratoire.
Quel est un bon score LCP en 2026 ?
Les seuils officiels sont inchangés depuis le lancement des Core Web Vitals, identiques sur mobile et desktop, à atteindre au 75e percentile des visites réelles.
| Statut | Seuil LCP |
|---|---|
| Bon | < 2,5 s |
| À améliorer | 2,5 - 4 s |
| Mauvais | > 4 s |
Le 75e percentile change tout : votre page peut s'afficher en 1,5 s sur votre fibre et échouer pour le quart de vos visiteurs sur réseau mobile ou appareil d'entrée de gamme. C'est la donnée field qui compte, pas votre ressenti.
Comment mesurer et diagnostiquer le LCP ?
Commencez par PageSpeed Insights : il affiche la donnée field (CrUX, 28 jours glissants) et la donnée lab (Lighthouse), identifie l'élément LCP et pointe les opportunités. Pour la vue site entier, le rapport Core Web Vitals de Search Console regroupe les URLs par type de page.
Le diagnostic efficace passe par la décomposition du LCP en quatre sous-parties, la méthode recommandée par l'équipe Chrome dans son guide d'optimisation du LCP :
- TTFB (Time to First Byte) : le temps de réponse du serveur.
- Load delay : le délai entre le premier octet et le début du chargement de la ressource LCP. Élevé quand l'image est découverte tardivement (CSS, JS, lazy loading).
- Load time : la durée de téléchargement de la ressource LCP. Élevé quand l'image est trop lourde.
- Render delay : le délai entre la fin du chargement et le rendu effectif. Élevé quand du CSS ou du JS bloque le rendu.
L'onglet Performance de Chrome DevTools et l'insight LCP breakdown donnent cette décomposition directement. En règle générale, une page bien optimisée passe l'essentiel de son LCP en TTFB et load time ; si load delay ou render delay dominent, il y a un correctif évident à appliquer.
Comment optimiser le LCP ? Les leviers par sous-partie
L'optimisation efficace cible la sous-partie dominante, pas "la vitesse en général".
Réduire le TTFB (serveur lent)
Un bon TTFB est inférieur à 800 ms selon le guide TTFB de web.dev. Les leviers : cache serveur ou cache de page (souvent le gain le plus massif sur CMS), CDN pour rapprocher le contenu des visiteurs, réduction des redirections en chaîne, et hébergement dimensionné. Aucune optimisation front ne compensera un serveur qui met 2 s à répondre : le TTFB est un plancher pour le LCP.
Éliminer le load delay (image découverte tardivement)
L'image LCP doit être découvrable dans le HTML initial, dès le premier scan du navigateur :
- Jamais de
loading="lazy"sur l'élément LCP. C'est l'erreur la plus répandue et la plus coûteuse. fetchpriority="high"sur l'image LCP pour la faire passer devant les autres ressources, comme documenté sur MDN.<link rel="preload">si l'image est une image de fond CSS ou chargée dynamiquement, donc invisible au scanner de préchargement.
Réduire le load time (image trop lourde)
Servez des formats modernes (AVIF ou WebP), dimensionnez les images à leur taille d'affichage réelle via srcset et sizes, et compressez agressivement : sur un hero, une qualité 70-80 est visuellement indiscernable de l'original. Un CDN d'images automatise l'ensemble.
Supprimer le render delay (rendu bloqué)
Inlinez le CSS critique, différez le CSS non critique et les scripts tiers, et évitez tout JavaScript synchrone dans le <head>. Si l'élément LCP est injecté par JavaScript (rendu client), envisagez le rendu serveur ou statique de la zone above the fold : le navigateur ne peut pas afficher ce qu'il n'a pas encore construit.
Quelles erreurs font échouer le LCP le plus souvent ?
Quatre patterns reviennent dans la majorité des audits : le lazy loading appliqué au hero (load delay), le carrousel ou slider en JavaScript qui retarde le rendu du premier visuel (render delay), l'image uploadée en 4000 px affichée en 800 px (load time), et le TTFB au-dessus de 1 s sur CMS sans cache de page. Vérifiez ces quatre points avant toute optimisation exotique.
Comment suivre le LCP dans le temps ?
Un audit ponctuel donne un instantané ; le LCP réel fluctue avec le trafic, les campagnes, les déploiements et les scripts tiers. Pour un suivi continu, WebCoreFlow interroge CrUX et PageSpeed Insights de façon programmée et historise le LCP de vos pages réelles, ce qui permet de détecter une régression avant qu'elle n'impacte 28 jours de fenêtre glissante.
Combien de temps pour voir un résultat ?
Comptez 28 jours sur la donnée field : c'est la fenêtre glissante de CrUX. Validez techniquement la correction en données lab immédiatement après le déploiement (l'élément LCP et ses sous-parties doivent avoir changé), puis laissez la fenêtre se renouveler avant de juger l'effet dans Search Console.
Sources et références
Analysez votre site en 30 secondes.
Obtenez votre score Core Web Vitals et un plan d'action concret pour grimper dans Google. Sans carte bancaire.
Questions fréquentes
- Qu'est-ce que le LCP (Largest Contentful Paint) ?
- Le LCP mesure le temps écoulé entre le début de la navigation et l'affichage du plus grand élément visible à l'écran : image hero, bloc de texte principal ou poster de vidéo. C'est la métrique officielle de vitesse de chargement perçue des Core Web Vitals de Google.
- Quel est un bon score LCP ?
- Un bon LCP est inférieur à 2,5 secondes, mesuré au 75e percentile des visites réelles (données CrUX), sur mobile comme sur desktop. Entre 2,5 et 4 s, le statut est \"À améliorer\" ; au-delà de 4 s, il est \"Mauvais\".
- Quelles sont les causes les plus fréquentes d'un LCP lent ?
- Quatre causes dominent : un serveur lent (TTFB élevé), des ressources CSS/JS qui bloquent le rendu, une image LCP découverte tardivement ou non priorisée, et une image trop lourde ou mal dimensionnée. Le diagnostic consiste à identifier laquelle des quatre sous-parties du LCP consomme le plus de temps.
- Le lazy loading peut-il dégrader le LCP ?
- Oui, c'est une erreur classique. Appliquer loading=\"lazy\" à l'image LCP retarde son chargement et dégrade directement la métrique. L'image LCP doit au contraire être chargée en priorité, avec fetchpriority=\"high\" et sans lazy loading.
- Comment identifier l'élément LCP d'une page ?
- PageSpeed Insights et l'onglet Performance de Chrome DevTools identifient l'élément LCP et détaillent ses quatre sous-parties (TTFB, load delay, load time, render delay). C'est le point de départ de toute optimisation ciblée.
- Combien de temps pour voir un LCP amélioré dans Search Console ?
- Environ 28 jours. Google calcule le LCP sur une fenêtre glissante de 28 jours de données réelles (CrUX). Validez la correction immédiatement en données lab, puis attendez le renouvellement de la fenêtre pour la donnée field.