Largest Contentful Paint : seuils et causes
Le Largest Contentful Paint (LCP) est le temps que met le plus grand élément visible à l'écran, souvent l'image principale ou le titre, à s'afficher après l'ouverture de la page. Google le considère bon jusqu'à 2,5 secondes et mauvais au-delà de 4.
Ce temps se répartit entre quatre étapes : la réponse du serveur, la découverte de l'image, son téléchargement, puis son affichage. Savoir laquelle déborde dit où chercher. C'est l'un des points que mesure l'audit de performance web.
Ce que le LCP mesure exactement
Selon web.dev, l'élément retenu peut être une image, une image de fond, la première image d'une vidéo ou un bloc de texte, pourvu qu'il soit dans la partie visible de l'écran. Le chronomètre part quand le visiteur ouvre la page.
La partie visible n'est pas la même sur un téléphone et sur un ordinateur, si bien que l'élément retenu peut changer d'un appareil à l'autre. Google recommande de juger le LCP sur les trois quarts des visites, en séparant téléphones et ordinateurs.
Où passe le temps avant l'affichage
web.dev découpe le LCP en quatre étapes, et donne pour chacune la part du temps qu'elle devrait occuper sur une page en bonne santé.
- La réponse du serveur, environ 40 % du temps. Redirections, connexion, puis préparation de la page par le serveur. Un hébergement lent ou une page recalculée à chaque visite pèse ici.
- Le délai avant le téléchargement de l'image, moins de 10 %. Il s'allonge quand l'image n'apparaît qu'au fond d'une feuille de style ou d'un script, ou quand elle est chargée en différé alors qu'elle est visible dès l'ouverture. web.dev est catégorique : l'image principale ne doit jamais être chargée en différé.
- Le téléchargement de l'image, environ 40 %. Son poids, son format, sa taille par rapport à l'écran, et le serveur qui la fournit : une image servie depuis un autre domaine demande d'abord une connexion supplémentaire.
- L'affichage, moins de 10 %. L'image est arrivée mais n'apparaît pas encore, parce que des feuilles de style ou des scripts bloquent le rendu. Quand l'élément retenu est un titre, une police de caractères pas encore reçue peut le garder invisible.
Cette répartition sert de repère : si la réponse du serveur occupe à elle seule la plus grande partie du temps, alléger l'image ne suffira pas.
Ce que nous relevons sur les sites audités
35 %ont un LCP au-delà de 4 secondes, dans la zone que Google qualifie de mauvaise
Ce pourcentage porte sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026, ceux où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : le chiffre décrit nos audits, pas l'ensemble des sites.
Ce chiffre porte sur les visites réelles quand Google en publie pour le site, et sinon sur notre propre mesure, prise en conditions mobiles.
Terrain et laboratoire ne mesurent pas la même chose
Les données de terrain viennent de vraies visites. Google les publie dans le Chrome UX Report, à partir des navigateurs Chrome des internautes, et seulement pour les sites qui reçoivent assez de visiteurs pour former un échantillon fiable. Beaucoup de petits sites n'y figurent pas.
Une mesure en laboratoire charge la page dans des conditions fixes : même appareil simulé, même réseau, à chaque passage. Elle se reproduit, et elle existe pour tous les sites. Elle ne voit pas, en revanche, les redirections ou les connexions lentes que rencontrent certains visiteurs, d'où des écarts avec le terrain que web.dev signale lui-même.
Notre audit fait les deux. Chaque page analysée est mesurée dans un navigateur bridé au niveau d'un téléphone et d'un réseau ordinaire, et la note repose sur ces mesures. Quand Google publie des données de terrain pour le site, le rapport les donne en regard, et c'est sur elles que se juge le seuil de 4 secondes à l'échelle du site.
Ce que l'audit regarde autour du LCP
Un LCP trop long est un résultat. Le rapport relève aussi ce qui l'explique, pour que la correction vise la bonne étape.
- Le LCP de chaque page analysée, sur téléphone et sur ordinateur.
- Le temps de réponse du serveur, première des quatre étapes.
- Les feuilles de style, scripts et polices qui bloquent l'affichage.
- Le poids, le format et la largeur en pixels des images, comparés à la taille à laquelle elles sont affichées.
- Le signalement anticipé de la ressource principale au navigateur, qui lui évite de la découvrir tard.
Ce qui se règle simplement, ce qui demande un projet
Quand le temps se perd sur l'image, la correction est souvent courte : une image au bon format et à la bonne taille, chargée tout de suite plutôt qu'en différé, et signalée au navigateur dès le code de la page.
Quand il se perd au serveur, ou quand le contenu n'apparaît qu'une fois le JavaScript exécuté, il faut un projet : un hébergement plus adapté, un cache des pages, ou une façon de construire les pages qui envoie le contenu tout prêt au navigateur.
Un LCP lent est souvent le symptôme d'un site lent partout. Le guide sur les causes d'un site lent les reprend dans l'ordre où la page les rencontre.
Ce que cette vérification ne dit pas
Nous mesurons depuis nos propres conditions : un navigateur, un profil de téléphone fixé, les pages analysées. Les données de terrain, nous les lisons quand Google les publie pour votre site ; quand il n'en publie pas, le rapport le dit.
Le LCP dépend de ce que la page affiche au moment de la mesure. Un visuel qui change d'une visite à l'autre, un contenu personnalisé ou un bandeau de consentement peuvent modifier l'élément retenu et le temps mesuré.
À lire ensuite
Site lent : les causes, dans l'ordre
Un site lent l'est rarement pour une seule raison. Les causes dans l'ordre où la page les rencontre, et ce que l'audit mesure à chaque étape.
Lire le guide →