Core Web Vitals LCP : pourquoi le premier écran de votre landing page met trop de temps à s’afficher

Le LCP (Largest Contentful Paint) mesure le temps qu'il faut, depuis l'arrivée sur la page, pour que le plus grand élément visible au premier écran s'affiche entièrement. Sur une landing page, ce n'est presque jamais un bouton ou un petit logo : c'est l'image hero, une vidéo de fond, ou parfois simplement le bloc de titre s'il occupe plus d'espace que tout le reste. Au-delà de 2,5 secondes, Google classe la page en zone « à améliorer » ou « mauvaise » — et le visiteur, lui, n'a pas besoin d'un score pour sentir qu'il attend encore que la page finisse de s'afficher.

Ce que le LCP mesure — et ce qu'il ne mesure pas

Le LCP fait partie des trois Core Web Vitals de Google, aux côtés du CLS (stabilité visuelle) et de l'INP (réactivité aux interactions), que nous détaillons dans un autre article. Contrairement au temps de chargement total ou au onLoad du navigateur, le LCP ne s'intéresse qu'à un seul repère : le moment où l'élément le plus grand du viewport visible devient pleinement rendu. Un site peut continuer à charger des scripts, des polices ou des sections plus bas dans la page pendant plusieurs secondes après un bon LCP — cela n'a plus d'impact sur ce score précis, mais peut en avoir sur l'INP ou le ressenti global.

Le seuil qui compte : 2,5 secondes, au 75ᵉ centile

Google fixe trois paliers : un LCP inférieur à 2,5 secondes est jugé « bon », entre 2,5 et 4 secondes il « nécessite une amélioration », au-delà de 4 secondes il est « mauvais ». Ce n'est pas une moyenne : Google évalue le 75ᵉ centile des visites réelles mesurées sur une fenêtre glissante de 28 jours (les données CrUX, Chrome User Experience Report) — autrement dit, il faut qu'au moins trois visiteurs sur quatre, avec leur connexion et leur appareil réels, obtiennent un LCP sous la barre des 2,5 secondes. Un test de laboratoire en fibre optique sur un poste de développeur ne dit donc pas grand-chose : ce sont vos visiteurs mobiles, en 4G, sur un appareil d'entrée de gamme, qui déterminent le score qui compte pour le référencement.

Pourquoi ce n'est pas qu'un score technique

Une étude de Qingzhu Gao, Prasenjit Dey et Parvez Ahammad, présentée en 2017 et menée par crowdsourcing à grande échelle sur des centaines de pages de sites marchands, a comparé les métriques classiques de chargement (comme le onLoad ou le temps au premier octet) à la perception réelle des utilisateurs sur la vitesse d'affichage du contenu visible au premier écran. Résultat : ces métriques traditionnelles concordent avec le jugement humain dans moins de 60 % des cas, alors qu'un modèle centré sur le rendu visible « au-dessus de la ligne de flottaison » explique la perception des utilisateurs avec une précision proche de 87 % (Gao, Dey & Ahammad, 2017). C'est précisément ce que le LCP a été conçu pour approximer : non pas « la page a-t-elle fini de charger », mais « le visiteur voit-il enfin quelque chose de substantiel ». Sur une landing page, ce quelque chose est souvent l'argument principal — le titre et l'image qui doivent convaincre en quelques secondes, comme nous le développons dans notre article sur la ligne de flottaison.

Les causes les plus fréquentes sur une landing page

• Une image hero trop lourde ou mal formatée — un JPEG ou PNG exporté à la taille d'écran desktop, servi tel quel au mobile, ou sans compression moderne (WebP, AVIF).
• Un temps de réponse serveur (TTFB) trop long — hébergement mutualisé surchargé, absence de mise en cache, ou rendu dynamique côté serveur à chaque requête au lieu d'un site statique pré-généré.
• Des ressources qui bloquent le rendu — CSS ou polices chargées de façon synchrone avant que le navigateur ne puisse peindre quoi que ce soit à l'écran.
• Une image découverte trop tard par le navigateur — chargée via JavaScript, en arrière-plan CSS non préchargé, ou cachée derrière un carrousel qui ne révèle la première image qu'après exécution d'un script.
• Une police web qui retarde l'affichage du titre — si le titre est le plus grand élément visible et que la police personnalisée bloque son rendu, c'est elle qui détermine le LCP, pas l'image.

Corriger le LCP sans sacrifier le design

La priorité va toujours à l'élément qui déclenche la mesure : identifiez-le dans l'onglet Performance de Chrome DevTools ou via PageSpeed Insights, qui l'entoure directement sur une capture d'écran. Si c'est l'image hero, servez-la en format moderne (WebP ou AVIF) et à la taille réellement affichée sur mobile grâce à des attributs srcset, ajoutez fetchpriority="high" pour indiquer au navigateur qu'elle est prioritaire, et surtout ne la chargez jamais en lazy puisqu'elle est visible dès l'arrivée sur la page — le lazy loading, utile plus bas dans le scroll, est contre-productif sur l'élément qui définit le LCP. Si c'est le bloc de titre qui domine visuellement (mise en page texte-seul, sans hero visuel), vérifiez que la police ne bloque pas le rendu : une police système en repli immédiat, ou une police web avec font-display: swap, évite d'attendre un fichier de police avant d'afficher le texte. Next.js gère une bonne partie de cela nativement via son composant Image (compression, formats modernes, dimensionnement automatique) — nous détaillons la configuration complète dans notre article sur le déploiement Next.js sur Vercel.

Le piège du skeleton screen et des animations d'entrée

Nous le mentionnons dans notre article sur les skeleton screens : un contenu qui apparaît progressivement via une animation JavaScript (fade-in, décalage, effet de reveal au scroll) retarde artificiellement le moment où le navigateur considère l'élément comme « peint », même si le fichier image est déjà téléchargé. Une animation d'entrée de 400 à 600 ms sur le titre ou l'image hero peut ainsi dégrader un LCP par ailleurs excellent. La solution n'est pas de bannir toute animation, mais de réserver les effets d'entrée aux sections situées sous la ligne de flottaison, et de laisser le bloc hero s'afficher immédiatement, sans transition d'opacité initiale.

Cas particulier : vidéo de fond en hero

Une landing page qui utilise une vidéo en boucle comme fond de hero — fréquent sur les templates Agence locale ou Restaurant & Réservation (démo) pour donner de l'ambiance — doit afficher une image de « poster » (l'attribut poster de la balise video, légère et préchargée) pendant que la vidéo elle-même continue de se charger en arrière-plan. C'est cette image statique, pas le premier frame de la vidéo, qui doit constituer l'élément LCP : compressée et servie en priorité, elle donne un rendu visuel immédiat pendant que la vidéo — nettement plus lourde — prend le temps qu'il lui faut sans pénaliser le score.

Vérifier le résultat sur le terrain, pas seulement en local

Un LCP correct en local, sur un poste de développement rapide et une connexion filaire, ne garantit rien sur le terrain. Google Search Console (rapport « Signaux Web essentiels ») remonte les données CrUX réelles de vos visiteurs une fois le trafic suffisant, tandis que PageSpeed Insights combine un test de laboratoire et, quand elles existent, les données réelles du site. Comme pour la vitesse de chargement générale que nous couvrons ailleurs, l'enjeu dépasse le seul score SEO : au-delà de 2,5 à 3 secondes avant de voir l'argument principal de la page, une partie mesurable des visiteurs quitte avant même d'avoir eu l'occasion de se laisser convaincre par le reste de la page.