Le LCP (Largest Contentful Paint) mesure le temps écoulé entre le début du chargement d'une page et le moment où le plus gros élément visible dans le viewport est rendu. Ce sont typiquement : une image hero, un bloc de texte H1 + paragraphe d'intro, un poster vidéo, une bannière. C'est la métrique la plus représentative de la « vitesse perçue » par l'utilisateur, et l'un des trois piliers des Core Web Vitals avec CLS et INP.
Les seuils Google : ≤ 2,5 s = bon, 2,5-4 s = à améliorer, > 4 s = mauvais — mesurés au 75e percentile sur les vrais utilisateurs Chrome (CrUX). Les causes typiques d'un mauvais LCP : image hero non optimisée (PNG 2 Mo au lieu d'un AVIF 80 Ko), fonts qui bloquent le rendu, JavaScript render-blocking, hébergement lent ou mal localisé, absence de SSG ou de CDN. Sur un site WordPress non optimisé, on voit régulièrement des LCP à 5-8 s sur mobile 4G — ce qui est éliminatoire en SEO compétitif.
Les optimisations qui marchent vraiment, par ordre d'impact : (1) servir l'image hero en AVIF/WebP avec `priority` et `fetchpriority="high"` (Next.js Image le fait nativement), (2) précharger les fonts critiques avec `preload` et utiliser `font-display: swap`, (3) passer en SSG ou ISR servi par CDN edge, (4) lazy-load tout ce qui n'est pas dans le viewport initial. On corrige ça pendant un audit gratuit ou un chantier dédié sur site sur-mesure.
Quick wins pour faire chuter votre LCP sous 2 s
- Image hero en AVIF/WebP + attributs `width/height` + `priority` (Next.js) ou `fetchpriority="high"`.
- Preload des fonts critiques + `font-display: swap` pour éviter le FOIT (texte invisible).
- [SSG](/glossaire/ssg/) ou [ISR](/glossaire/isr/) servi depuis un CDN edge (Vercel, Cloudflare) — supprime le TTFB serveur.
- Différer tout JS non-critique : analytics, chat widget, third-parties via `defer` ou chargement post-LCP.
