Quand nous ouvrons une page, la question que nous nous posons n’est pas « quand a-t-elle fini de tout charger ? » mais « quand est-ce que je vois ce que je cherchais ? ». Le Largest Contentful Paint, LCP, est la métrique des Core Web Vitals qui répond exactement à cette question : elle mesure le moment où le contenu principal de la page apparaît à l’écran. C’est la métrique la plus liée à la perception de la vitesse, et aussi celle qui sépare le plus souvent un site « vert » d’un site qui échoue à l’évaluation de Google.
Ce que mesure le LCP
Le LCP est le temps écoulé entre le début de la navigation et le moment où le plus grand élément visible dans le viewport est affiché. Il ne repose pas sur un événement technique comme le chargement complet du document, mais sur ce que voit l’utilisateur : sur la plupart des pages, le plus grand élément est l’image principale, le titre de l’article, la photo du produit ou un bloc de texte en évidence.
Les seuils, évalués au 75e percentile des visites réelles, sont les suivants : en moins de 2,5 secondes, le résultat est bon ; entre 2,5 et 4 secondes, il est à améliorer ; au-delà de 4 secondes, il est médiocre. Comme pour les autres métriques, ce qui compte, c’est qu’au moins trois visites sur quatre se situent dans le seuil, pas la moyenne.
Comment le navigateur choisit l’élément LCP
L’élément LCP n’est pas décidé à l’avance. Pendant le chargement, le navigateur enregistre, image après image, quel est le plus grand élément affiché jusque-là : au début, ce peut être un titre, puis une image plus grande qui arrive plus tard. Chaque fois qu’un candidat plus grand apparaît, la valeur est mise à jour. L’enregistrement s’arrête à la première interaction de l’utilisateur, comme un toucher, un clic, une pression de touche ou un défilement.
Les candidats peuvent être des images, y compris celles utilisées comme arrière-plan via le CSS, des affiches de vidéo et des blocs de texte. Pour les images, ce qui compte est la surface réellement visible dans le viewport, et le navigateur exclut les éléments invisibles et les substituts contenant très peu d’information, comme les images floutées utilisées pendant le chargement. Une conséquence pratique : l’élément LCP peut être différent sur smartphone et sur desktop, parce que ce qui est visible et la place que cela occupe changent. Il faut donc l’identifier séparément pour les deux types d’appareil.
Pourquoi le LCP est une affaire de business
Tant que le contenu principal n’apparaît pas, l’utilisateur ne peut rien faire : il ne peut pas lire le titre, voir le produit ni savoir s’il est au bon endroit. C’est le moment où se produisent la plupart des abandons, surtout chez les personnes qui arrivent d’une campagne ou d’un résultat de recherche et qui ont des alternatives à un toucher de là. Un LCP lent se traduit par moins de pages vues, moins d’ajouts au panier et du budget publicitaire dépensé pour des visites qui n’atteignent jamais le contenu. Et, comme composante des Core Web Vitals, il pèse sur l’évaluation de l’expérience de page par Google.
Les quatre phases du LCP
La façon la plus utile de raisonner sur le LCP est de le décomposer en quatre phases, car chacune a des causes et des remèdes différents :
- TTFB : le temps qui précède l’arrivée du premier octet du document HTML.
- Délai de chargement de la ressource (resource load delay) : le temps entre le premier octet et le début du téléchargement de l’image LCP. Il est élevé quand le navigateur découvre l’image tard.
- Durée de chargement de la ressource (resource load duration) : le temps nécessaire pour télécharger l’image.
- Délai de rendu de l’élément (element render delay) : le temps entre la fin du téléchargement et le moment où l’élément est effectivement affiché, par exemple parce que le navigateur attend des feuilles de style ou des scripts.
À titre de repère, sur une page bien optimisée, le TTFB et le téléchargement de l’image prennent chacun environ 40 % du temps total, tandis que les deux délais restent sous les 10 %. Si l’une des phases est beaucoup plus grande qu’elle ne devrait l’être, c’est là que se trouve le problème. Dans l’exemple de la figure, le délai de chargement à lui seul est de 1,4 seconde : l’image était là, mais le navigateur l’a trouvée trop tard.
Les causes les plus courantes
- Un serveur lent. Sans cache de page, chaque visite attend que l’application génère le HTML : tout le reste démarre en retard. Nous en avons parlé dans l’article sur le TTFB et le cache de page.
- Une image découverte tard. Si l’image principale est un arrière-plan défini en CSS, est insérée par un slider JavaScript ou porte l’attribut
loading="lazy", le navigateur ne la demande qu’après avoir téléchargé et exécuté d’autres ressources. - Des images trop lourdes. Une photo de plusieurs mégaoctets, dans le même format pour desktop et smartphone, demande un temps de téléchargement qu’aucune optimisation du serveur ne peut compenser.
- Des ressources bloquant le rendu. Les feuilles de style et les scripts synchrones dans le
<head>empêchent le navigateur d’afficher la page, même quand l’image est déjà arrivée. - Le rendu côté client. Si le contenu principal est construit par JavaScript, l’élément LCP n’existe qu’une fois les scripts téléchargés, analysés et exécutés.
Comment l’améliorer
La règle la plus efficace est de laisser le navigateur trouver tout de suite l’image principale, et de lui dire qu’elle est importante. Il suffit qu’elle soit présente dans le HTML comme élément <img>, sans chargement différé, avec une priorité haute et dans un format et une taille adaptés à l’appareil :
<img
src="hero-1200.avif"
srcset="hero-800.avif 800w, hero-1200.avif 1200w, hero-1920.avif 1920w"
sizes="100vw"
width="1920" height="1008"
fetchpriority="high"
alt="…">
<!-- si l’image est un arrière-plan CSS, l’annoncer tôt -->
<link rel="preload" as="image" href="hero-1200.avif" fetchpriority="high">
- Réduire le TTFB avec un cache de page à l’origine, éventuellement associé à un CDN, et une application rapide même quand le cache ne peut pas intervenir.
- Alléger l’image avec des formats modernes comme AVIF et WebP, des tailles adaptées à chaque écran grâce à
srcsetet une compression calibrée. - Libérer le rendu en chargeant les scripts non essentiels sans blocage et en gardant légères les feuilles de style critiques.
- Soigner les polices quand l’élément LCP est du texte, en préchargeant la police principale et en utilisant une police de secours immédiate.
- Éviter les carrousels en haut de page : une image statique bien optimisée est presque toujours plus rapide qu’une diapositive initialisée par JavaScript.
Enfin, méfiez-vous des raccourcis : les techniques qui retardent tout le JavaScript ou qui suppriment le CSS automatiquement peuvent améliorer le LCP en laboratoire et dégrader d’autres métriques, comme nous l’avons vu en parlant de retarder le JavaScript jusqu’au premier clic.
Comment le mesurer
PageSpeed Insights affiche le LCP d’utilisateurs réels au 75e percentile à partir des données CrUX et, dans la section laboratoire, indique quel élément a été considéré comme le LCP. Dans le panneau Performance de Chrome DevTools, la décomposition du LCP par phase montre immédiatement laquelle des quatre pèse le plus. Sur le terrain, la bibliothèque open source web-vitals renvoie les mêmes phases pour les visites réelles :
import { onLCP } from 'web-vitals/attribution';
onLCP( ( { value, attribution } ) => {
console.log( 'LCP', Math.round( value ), 'ms', {
element: attribution.target,
ttfb: attribution.timeToFirstByte,
loadDelay: attribution.resourceLoadDelay,
loadDuration: attribution.resourceLoadDuration,
renderDelay: attribution.elementRenderDelay,
} );
} );Le laboratoire et le terrain peuvent donner des valeurs différentes : le test de laboratoire part toujours d’un cache vide et d’une seule taille d’écran, alors que les utilisateurs réels ont des ressources déjà en cache, des appareils différents et des connexions variables. C’est pourquoi le laboratoire sert à comprendre les causes, et les données d’utilisateurs réels à vérifier leur effet, en tenant compte de la fenêtre de 28 jours de CrUX.
En résumé
Le LCP mesure le moment où le contenu principal de la page apparaît : le plus grand élément visible, choisi par le navigateur pendant l’affichage de la page. Bon en moins de 2,5 secondes au 75e percentile, il se décompose en quatre phases, TTFB, délai de chargement de la ressource, durée de chargement de la ressource et délai de rendu de l’élément, qui indiquent précisément où intervenir.
D’après notre expérience, les problèmes les plus fréquents sont toujours les mêmes : un serveur sans cache de page et une image principale découverte tard ou trop lourde. Ce sont aussi ceux au retour le plus rapide : un TTFB bas et une image annoncée immédiatement, légère et à priorité haute suffisent souvent à ramener le LCP sous le seuil, avec un effet immédiat sur ce que voient les utilisateurs et sur le nombre de ceux qui restent.
