LCP

Le Largest Contentful Paint mesure la vitesse de chargement telle que l'internaute la perçoit : le moment où le contenu principal de la page apparaît. Plutôt que de chronométrer le chargement complet, il retient le rendu du plus grand élément visible dans la fenêtre, mesuré depuis le début de la navigation. C'est l'un des trois Core Web Vitals, avec l'INP pour la réactivité et le CLS pour la stabilité visuelle.

Les seuils

LCP	Évaluation
2,5 s ou moins	Bon
De 2,5 à 4 s	À améliorer
Plus de 4 s	Mauvais

La valeur à surveiller est le 75e centile des chargements de page, mesuré séparément sur mobile et sur ordinateur. Autrement dit, au moins trois visites sur quatre doivent atteindre le seuil pour que la page soit jugée bonne.

Les éléments pris en compte

Le navigateur retient comme candidats les images <img>, les éléments <image> placés dans un SVG, les vidéos (l'image d'affiche ou la première image affichée), les éléments dont l'image de fond est chargée par la fonction CSS url(), et les blocs qui contiennent du texte. Seule la partie visible dans la fenêtre compte ; les marges, les bordures et les zones coupées sont exclues.

L'élément retenu peut changer pendant le chargement, au fur et à mesure que de plus grands éléments s'affichent. Le navigateur cesse d'en signaler de nouveaux dès que l'internaute interagit avec la page, par un appui, un défilement ou une frappe au clavier.

Les quatre phases du LCP

Pour trouver ce qui ralentit une page, Google propose de découper le LCP en quatre phases :

1. le TTFB, délai avant la réception du premier octet du document HTML ;
2. le délai avant que le navigateur commence à charger la ressource LCP, souvent une image ;
3. la durée de chargement de cette ressource ;
4. le délai de rendu de l'élément une fois la ressource chargée.

À titre de repère, Google suggère environ 40 % du temps pour le TTFB, environ 40 % pour le chargement de la ressource, et moins de 10 % pour chacun des deux délais.

Améliorer le LCP

L'image principale doit être visible dans le HTML initial, et non injectée plus tard par JavaScript. Elle ne doit jamais être chargée en différé (lazy loading), ce qui retarderait inutilement son affichage. L'attribut fetchpriority="high" demande au navigateur de la charger en priorité :

<img src="/images/atelier.webp" fetchpriority="high" width="1200" height="600" alt="Atelier de menuiserie">

Si l'image n'est appelée que depuis une feuille de style, un préchargement la rend visible plus tôt :

<link rel="preload" as="image" fetchpriority="high" href="/images/atelier.webp" type="image/webp">

Les autres pistes portent sur chaque phase : un serveur qui répond vite et peu de redirections, des images compressées et bien dimensionnées dans un format moderne, un CDN, une mise en cache efficace, moins de CSS et de scripts bloquants dans l'en-tête, et un rendu côté serveur pour les pages construites en JavaScript. Réserver fetchpriority="high" à une ou deux images : au-delà, l'attribut perd son intérêt.

Mesurer le LCP

Les données de terrain viennent du Chrome User Experience Report ; PageSpeed Insights les affiche, et le rapport Core Web Vitals de la Google Search Console les regroupe par ensembles d'URL similaires. Les outils de laboratoire, comme Lighthouse ou les outils de développement de Chrome, servent à reproduire et diagnostiquer un problème. Ce sont toutefois les données de terrain qui reflètent l'expérience réelle des visiteurs. Un temps de chargement complet élevé peut coexister avec un bon LCP, et inversement.

Le poids du LCP dans le classement

Google recommande d'obtenir de bons Core Web Vitals et indique qu'ils correspondent à ce que ses systèmes de classement cherchent à récompenser. Il précise aussi qu'une bonne expérience de page ne garantit pas les premières positions : la recherche Google cherche toujours à afficher le contenu le plus pertinent, même si son expérience de page est moyenne. Un LCP rapide améliore l'expérience des visiteurs, il ne remplace pas un contenu qui répond à la requête.