LCP trop lent : corriger le plus gros frein aux Core Web Vitals

Le LCP (Largest Contentful Paint) est le Core Web Vital qui pèse le plus dans le classement Google, et souvent le plus simple à corriger sans refonte. Réponse directe : le LCP mesure le temps avant l'affichage du plus gros élément visible (en général l'image hero) ; au-delà de 2,5 secondes, Google dégrade la page. Dans 90 % des cas, la cause est une image trop lourde, un rendu bloqué par le CSS/JS, un serveur lent (TTFB) ou des polices — dans cet ordre de fréquence. Voici comment identifier la vôtre et descendre sous le seuil.

Quel élément est votre LCP ?

On ne corrige pas ce qu'on ne mesure pas. Dans les DevTools Chrome, onglet Performance, lancez un enregistrement au chargement : l'outil marque l'élément LCP. C'est presque toujours l'image hero, une vidéo d'en-tête ou un gros titre. Cette identification conditionne tout — corriger la mauvaise image ne change rien au score.

Pourquoi une image plombe-t-elle le LCP (et comment y remédier) ?

Si votre LCP est une image, son poids est souvent le problème. Les correctifs, par ordre d'impact :

• Format moderne (WebP/AVIF) : 30 à 70 % de poids en moins qu'un JPEG.
• Dimensions justes : inutile de charger 3000 px pour un affichage sur 800 px.
• Préchargement pour que le navigateur la demande sans attendre le CSS :

<link rel="preload" as="image" href="/hero.avif" fetchpriority="high" />

Et surtout : ne mettez jamais l'image LCP en loading="lazy" — c'est l'erreur classique qui retarde d'une seconde l'élément le plus important.

Le rendu est-il bloqué par le CSS et le JS ?

Le navigateur ne peint rien tant qu'il télécharge des ressources bloquantes. Un gros CSS dans le <head> ou un script tiers synchrone retarde tout l'affichage. Les leviers : différer le JavaScript non essentiel (defer/async) et inliner le CSS critique pour que le haut de page s'affiche sans attendre la feuille complète.

Et si c'est le serveur (TTFB) ou les polices ?

Deux causes plus profondes :

• TTFB : si le serveur met une seconde à répondre avant le moindre octet, aucune optimisation d'image ne sauvera le LCP. On réduit par le cache, un hébergement adapté et un CDN. Un TTFB élevé est un plafond de verre.
• Polices : une police qui bloque le texte fait un LCP invisible une seconde. Parade : font-display: swap + préchargement des polices critiques.

Checklist LCP

• [ ] Élément LCP identifié (DevTools → Performance)
• [ ] Image LCP en AVIF/WebP, bien dimensionnée, preload + fetchpriority=high, pas de lazy
• [ ] JS non essentiel en defer/async, CSS critique inliné
• [ ] TTFB sous 200-500 ms (cache/hébergement/CDN)
• [ ] font-display: swap sur les polices
• [ ] Vérifié sur les données de terrain (CrUX / Search Console), pas seulement Lighthouse

Mesurer sur le terrain, pas seulement en labo

Lighthouse donne une estimation en conditions idéales. Ce que Google utilise pour le classement, ce sont les données de terrain (CrUX), mesurées chez de vrais visiteurs, souvent mobile et réseau moyen. Un bon score en labo mais mauvais sur le terrain trahit un problème de serveur ou de réseau que le labo ne voit pas.

Questions fréquentes

Quel est un bon score LCP ?

Google considère le LCP « bon » sous 2,5 s, « à améliorer » entre 2,5 et 4 s, et « mauvais » au-delà de 4 s — mesuré sur le terrain (75e centile des visites réelles, souvent sur mobile).

Le lazy loading peut-il ralentir le LCP ?

Oui, si on l'applique à l'image principale du haut de page. Le loading="lazy" doit être réservé aux images sous la ligne de flottaison. L'image LCP, elle, doit être préchargée en priorité, jamais différée.

Combien de temps pour corriger un LCP lent ?

Quand la cause dominante est identifiée (image, CSS/JS, TTFB ou polices), le correctif prend souvent de quelques heures à une demi-journée. Ce qui coûte du temps, c'est d'optimiser au hasard sans avoir isolé le vrai maillon.

Faut-il une refonte pour améliorer les Core Web Vitals ?

Rarement. Le LCP se corrige presque toujours par des optimisations ciblées (image, chargement, cache) sur le site existant. La refonte ne se justifie que si la base technique est morte ou impossible à faire évoluer.

Quand faire appel à HelpApp Pro

L'erreur habituelle est de tout optimiser un peu au lieu de corriger d'abord le maillon qui bloque. HelpApp Pro fait ce diagnostic ciblé et applique les correctifs prioritaires, sans refonte ni sur-ingénierie. Décrivez votre page via le devis en ligne, ou consultez notre page diagnostic technique.