Comment Largest Contentful Paint se décompose en quatre parties corrigibles

Qu'est-ce que le LCP (Largest Contentful Paint) et qu'est-ce qu'un bon score ?

Google note Largest Contentful Paint comme bon à 2.5 secondes ou moins, à améliorer entre 2.5 et 4.0 secondes et mauvais au-delà de 4.0 secondes, lu au 75e centile des chargements de page et noté séparément pour mobile et desktop (web.dev, "Largest Contentful Paint (LCP)", mis à jour le 4 septembre 2025). La métrique marque le moment où la plus grande image ou le plus grand bloc de texte visible dans le viewport a fini de s'afficher, ce qui est la meilleure approximation dont dispose le navigateur pour le moment où un visiteur juge que la page est arrivée. Comparez votre chiffre à 2.5 secondes au p75 d'abord, car une moyenne qui passe avec un p75 qui échoue reste une page qui échoue.

La taille est jugée à l'intérieur du viewport uniquement, et pour les images le navigateur retient la taille visible ou la taille intrinsèque, la plus petite des deux.

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

La spécification LCP retient cinq types d'éléments, le gagnant sur votre page est donc l'un d'eux et rien d'autre. Tout ce qui sort de cette liste, éléments canvas et dégradés CSS compris, ne peut pas prendre le titre, quelle que soit la surface d'écran occupée.

Élément éligible	Ce que le navigateur mesure
<img>	Taille visible ou intrinsèque, la plus petite des deux
<image> dans un <svg>	Même règle que pour <img>
<video>	L'image du poster, ou la première frame peinte
Tout élément avec une image de fond url()	La surface peinte de l'élément
Éléments de type bloc contenant des noeuds de texte	Le plus petit rectangle englobant tous les noeuds de texte

Identifiez le vôtre avant de toucher à quoi que ce soit. Les Chrome DevTools nomment l'élément gagnant dans le panneau Performance, et les outils de terrain l'attachent à chaque échantillon, ce qui compte car les deux s'accordent rarement.

Quelles sont les quatre sous-parties du Largest Contentful Paint ?

Google décompose Largest Contentful Paint en time to first byte (temps jusqu'au premier octet), resource load delay (attente avant le début du téléchargement), resource load duration (durée du téléchargement de la ressource) et element render delay (attente avant l'affichage de l'élément), quatre intervalles consécutifs dont la somme fait la métrique entière. L'équipe Chrome publie une part cible pour chacun dans "Optimize Largest Contentful Paint" (web.dev, mis à jour le 31 mars 2025) : environ 40% pour time to first byte, moins de 10% pour resource load delay, environ 40% pour resource load duration et moins de 10% pour element render delay. Mesurez les parts avant de choisir un correctif, car une sous-partie déjà dans son budget ne peut pas vous rendre les secondes qu'il vous faut.

Sous-partie	Ce qu'elle couvre	Part cible	Ce qui la ralentit	Le correctif
Time to first byte	Du début de la navigation à l'arrivée du premier octet de la réponse HTML	~40%	Chaînes de redirections, réponses d'origine non mises en cache, traitement backend lent, distance jusqu'à l'origine	Supprimer les redirections, servir du HTML en cache depuis les noeuds edge d'un CDN, réduire le temps de traitement backend
Resource load delay	Du premier octet au moment où le navigateur commence à télécharger la ressource LCP	<10%	L'image n'est référencée que dans le CSS ou le JS, le preload scanner ne la voit donc jamais ; loading="lazy" sur le hero ; rendu côté client qui l'injecte tard	Mettre l'image LCP dans le HTML initial, ajouter <link rel="preload" fetchpriority="high"> quand elle n'est atteignable que via CSS ou JS, retirer le lazy loading du hero
Resource load duration	Le téléchargement de la ressource LCP elle-même, du début à la fin	~40%	Images surdimensionnées ou non compressées, formats anciens, concurrence sur la bande passante, absence d'en-têtes de cache	Compresser et redimensionner, servir de l'AVIF ou du WebP, servir depuis un CDN, poser des durées de cache longues, intégrer les petites ressources en inline
Element render delay	De la fin du téléchargement au moment où l'élément est réellement peint	<10%	Feuilles de style et scripts bloquant le rendu, tâches longues sur le thread principal, hydratation qui retient le premier affichage	Différer ou intégrer en inline le CSS et le JS bloquants, faire le rendu côté serveur, découper les tâches longues

Comment un Largest Contentful Paint de 4.2 secondes se répartit-il entre les quatre parties ?

La décomposition transforme un chiffre inutile en une cible évidente, car la métrique est une simple somme :

LCP = time to first byte + resource load delay + resource load duration + element render delay

Prenez une page dont le LCP p75 est de 4.2 secondes, ce qui est mauvais. Les données de terrain le répartissent en 0.9s de time to first byte, 2.0s de resource load delay, 1.0s de resource load duration et 0.3s d'element render delay. Appliquez les parts cibles à 4.2 secondes pour obtenir le budget de chaque sous-partie.

Sous-partie	Mesuré	Part de 4.2s	Budget à 4.2s	Verdict
Time to first byte	0.9s	21%	1.68s	Dans le budget
Resource load delay	2.0s	48%	0.42s	4.8x au-dessus
Resource load duration	1.0s	24%	1.68s	Dans le budget
Element render delay	0.3s	7%	0.42s	Dans le budget

Trois des quatre sont saines. L'image du hero n'est demandée que deux secondes pleines après l'arrivée du HTML, ce qui désigne la découverte : l'image est derrière une règle CSS, derrière un script, ou derrière loading="lazy". La compresser davantage attaquerait les 1.0s qui vont déjà bien et laisserait la page en mauvais.

Corrigez le problème de découverte et le resource load delay tombe à environ 0.2s. La nouvelle somme est 0.9 + 0.2 + 1.0 + 0.3 = 2.4s, qui passe. Un changement, 1.8 secondes, aucune image réencodée. Reportez la même décomposition sur Cumulative Layout Shift et Interaction to Next Paint, et servez-vous-en pour décider ce qui compte comme un bon LCP pour une page précise.

Pourquoi l'élément LCP change-t-il entre mobile et desktop ?

L'élément LCP est ce qui est le plus grand dans le viewport de ce visiteur, donc une mise en page qui se réagence selon les breakpoints donne le titre à un élément différent sur chaque appareil. Une photo de hero desktop de 1200px de large peut être masquée par une media query sur mobile, où le bloc de texte du titre devient à la place le plus grand élément peint. Les deux chiffres ne partagent alors aucun mécanisme : le LCP desktop est dominé par resource load duration, le LCP mobile par time to first byte et element render delay, car le texte ne demande aucun téléchargement séparé.

C'est le piège derrière la plupart des chantiers LCP ratés. Une équipe précharge l'image du hero, voit le LCP desktop s'améliorer et voit le p75 mobile refuser de bouger, car sur mobile cette image n'a jamais été l'élément LCP. Google note mobile et desktop séparément, alors déboguez-les séparément : tirez l'élément LCP par format d'appareil depuis les données de terrain et attendez-vous à deux correctifs différents. Quand le texte prend le titre, une police web bloquant le rendu déplace toute la métrique vers element render delay et aucun travail sur les images n'y touche.

Même page, élément LCP différent

DesktopLa photo hero, large de 1200px, gagne par taille ; le LCP est dominé par resource load duration

MobileUne media query masque le hero, le bloc de texte du titre gagne alors à sa place ; le LCP est dominé par time to first byte et render delay

Pourquoi le lazy loading d'une image de hero dégrade-t-il le LCP ?

Appliquer loading="lazy" à l'image LCP ajoute toujours du resource load delay, car le preload scanner l'ignore pendant l'analyse du HTML et le téléchargement attend que la mise en page s'exécute et place l'élément près du viewport. L'équipe Chrome le dit sans détour dans "Optimize Largest Contentful Paint" (web.dev, mis à jour le 31 mars 2025) : "a lazy-loaded LCP image will always lead to unnecessary resource load delay", soit : une image LCP chargée en lazy entraînera toujours du resource load delay inutile. L'attente n'achète rien, puisqu'un hero au-dessus de la ligne de flottaison est déjà dans le viewport.

Les dégâts arrivent par les valeurs par défaut. Un CMS ou une bibliothèque de composants qui appose loading="lazy" sur chaque image a raison pour les 40 sous la ligne de flottaison et tort pour la seule qui est en haut. Mettez loading="eager" et fetchpriority="high" sur le hero, gardez le lazy loading partout ailleurs, puis confirmez dans les données de terrain plutôt que dans un test en laboratoire.

Comment voir le LCP qu'ont réellement eu vos visiteurs ?

Les données de terrain sont la seule source qui rapporte l'élément LCP et la décomposition en sous-parties depuis de vrais appareils sur de vrais réseaux, et c'est pour cela que le real user monitoring, la mesure des visiteurs réels, se trouve sous chaque chiffre de cette page. Un test en laboratoire renvoie un LCP reproductible pour une machine que vous avez configurée ; le p75 qui décide de votre verdict Core Web Vitals vient des visites que vous avez réellement reçues.

Le poids est la contrainte, car un script de mesure qui retarde la page corrompt la métrique qu'il rapporte. Flowsery collecte les données de terrain via un seul script de moins de 10 KB, sans cookie et hébergé dans l'UE, sans échantillonnage des données, si bien que le p75 vient de toutes les sessions et non d'un sous-ensemble. Il enregistre la session à côté des temps et signale les rage clicks, les dead clicks, les erreurs JavaScript et les abandons, ce qui transforme un p75 lent en un replay que vous pouvez regarder.

Questions fréquentes

Largest Contentful Paint est-il mesuré avant ou après l'interaction de l'utilisateur ?

Le navigateur cesse de rapporter de nouveaux candidats LCP à la première interaction de l'utilisateur, qu'il s'agisse d'un scroll, d'un tap ou d'une frappe au clavier. Rien de ce qui est peint après ce point ne devient l'élément LCP, quelle que soit sa taille. Cette coupure garde la métrique liée au chargement initial plutôt qu'au contenu que le visiteur a fait défiler jusqu'à l'écran.

L'élément LCP doit-il rester sur la page ?

Non. Une fois qu'un élément est enregistré comme largest contentful paint, il garde le titre même s'il sort du viewport au scroll ou quitte entièrement le DOM, sauf si un élément plus grand s'affiche ensuite. Une image d'accueil qui disparaît après 500ms fixe quand même votre LCP, et dans un carrousel la première diapositive gagne tandis que les suivantes ne changent rien.

Pourquoi mon LCP en laboratoire est-il rapide et mon LCP de terrain mauvais ?

Les outils de laboratoire mesurent un appareil sur une connexion que vous avez configurée, et les données de terrain mesurent les appareils que votre audience possède vraiment. Un LCP Lighthouse de 1.6s et un p75 de terrain de 4.2s sont deux réponses correctes à des questions différentes. Vérifiez un correctif en laboratoire, décidez si la page passe sur le terrain.

Un CDN corrige-t-il le Largest Contentful Paint ?

Un CDN réduit deux des quatre sous-parties : time to first byte, en servant le HTML depuis un noeud edge proche du visiteur, et resource load duration, en servant l'image de la même façon. Il ne fait rien pour le resource load delay causé par une découverte tardive, ni pour l'element render delay causé par des scripts bloquant le rendu. Décomposez votre LCP d'abord et la réponse est déjà visible.

Une vidéo peut-elle être l'élément LCP ?

Oui. Les éléments vidéo sont éligibles, et le navigateur mesure l'image du poster ou la première frame peinte. Poser un poster sur une vidéo au-dessus de la ligne de flottaison donne au navigateur quelque chose à peindre avant l'arrivée des données vidéo ; sans poster, le titre LCP passe à ce qui est le plus grand par ailleurs.

Combien d'échantillons faut-il pour qu'un chiffre de LCP veuille dire quelque chose ?

Assez pour que le 75e centile cesse de bouger quand un seul appareil atypique arrive. Une route à 40 visites par semaine produit un p75 qui oscille avec un unique visiteur sur un téléphone lent, alors agrégez au niveau du gabarit de page ou élargissez la fenêtre. Découper par pays et par appareil à la fois multiplie le trafic nécessaire, puisque chaque segment porte sa propre distribution.

Un dégradé CSS peut-il être l'élément LCP ?

La spécification du LCP reconnaît cinq types d'éléments : les images, les images SVG, les vidéos, les éléments avec une image de fond url() et les blocs de texte. Les dégradés CSS et les éléments canvas restent en dehors de cette liste, donc aucun des deux ne peut remporter le titre, même en couvrant tout le viewport.

Un titre peut-il devenir l'élément LCP à la place d'une image ?

Tout élément de bloc contenant des nœuds de texte est éligible, mesuré comme le plus petit rectangle englobant ces nœuds. C'est exactement ce qui se produit sur les layouts mobiles où une media query masque la photo hero et le bloc de texte du titre devient le plus grand élément peint.

Compresser l'image hero corrige-t-elle toujours un LCP lent ?

Seulement quand resource load duration est la sous-partie qui dépasse son budget. Dans l'exemple de 4.2 secondes de cette page, resource load duration restait déjà dans son budget à 1.0s pendant que resource load delay le dépassait de 4,8 fois, donc compresser davantage l'image aurait laissé la page tout aussi mauvaise. Vérifiez la répartition avant de toucher à l'image.

Quelle part du LCP resource load duration devrait-elle occuper ?

Environ 40%, la même part cible que time to first byte. Les deux sous-parties restantes, resource load delay et element render delay, devraient chacune rester sous 10% du total.