Le LCP (Largest Contentful Paint) mesure le temps nécessaire pour afficher le plus grand élément visible d'une page — généralement une image hero, une vidéo ou un bloc de texte. C'est l'un des trois Core Web Vitals de Google. Seuil optimal : moins de 2,5 secondes. Au-delà de 4s, Google considère la page comme thérapeut.
Le LCP remplace le traditionnel "temps de chargement" en se concentrant sur l'expérience réelle de l'utilisateur. Il track l'élément le plus visible et le plus lourd visuellement : (1) Images — JPEG/PNG/WebP dans srcset, lazy-loaded below the fold NON comptabilisé, (2) Vidéos — poster image ou première frame, (3) Blocs de texte — paragraphes avec font-size >= 20px. Le LCP est déclenché au premier viewport (zone visible sans scroll). Un site avec LCP de 1,8s génère +18% de conversions vs un site à 3,2s (Google Chrome UX Report, 2024).
Le LCP, c'est chronométrer le moment exact où le lecteur d'un journal voit la une entièrement chargée. Si vous voyez le titre mais pas la photo principale pendant 4 secondes, le LCP est à 4s — même si le reste de la page charge vite. C'est le temps du "premier impression" de votre page.
Le TTFB est le temps entre la requête et le premier byte reçu du serveur. Un TTFB élevé est la cause #1 des mauvais LCP. Benchmarks : (1) TTFB < 200ms = excellent, (2) 200-800ms = à améliorer, (3) > 800ms = critique. Causes d'un TTFB élevé : serveur saturé, absence de CDN, base de données non optimisée, hébergement mutualisé. Solutions : passage à un serveur dédié ou serverless (Vercel, Cloudflare Pages), activation du cache serveur (Redis, Memcached), implémentation d'un CDN edge (Cloudflare, Fastly) pour servir le contenu depuis le PoP le plus proche.
Les fichiers CSS et JS synchrones bloquent le rendu. Chaque ressource bloquante ajoute 100-300ms au LCP. Audit : Chrome DevTools Coverage montre quels fichiers sont non utilisés. Optimisations critiques : (1) Minifier et compressor CSS/JS (Brotli au lieu de gzip), (2) Deferred JS — async ou defer sur tous les scripts non-critiques, (3) Inline CSS critique — les styles above-the-fold inline dans le head, le reste en async load, (4) Preload fonts — link rel="preload" pour les polices critiques.
L'image LCP doit être servie en priorité. Stratégie : (1) Format moderne — WebP ou AVIF (40-60% plus petit que JPEG à qualité équivalente), (2) srcset responsive — servir l'image adaptée à la viewport (600w pour mobile, 1200w pour desktop), (3) Preload — link rel="preload" as="image" fetchpriority="high" pour l'image LCP, (4) Lazy loading seulement below-fold — l'image LCP ne doit jamais être lazy-loadée, (5) CDN images — avec resize automatique (Cloudflare Images, Cloudinary, imgix). Impact : passage de JPEG 400KB à WebP 150KB réduit le LCP de 800ms sur mobile 4G.
Site e-commerce (80K visites/mois, CA 1.2M€/an). LCP mesuré : 4,8s sur mobile (score Pagespeed : 52/100). Diagnostic : (1) Image hero PNG 1.2MB non optimisée, (2) 3 fichiers CSS mutualisés loaded en blocking, (3) TTFB serveur 1.2s (hébergement mutualisé). Actions : (1) Conversion hero en WebP 180KB avec srcset, (2) Ajout preload fetchpriority="high" sur l'image hero, (3) Inline CSS above-fold, (4) Déplacement vers Vercel (CDN edge), (5) Font preload woff2. Résultat : LCP 4.8s → 1.6s, score Pagespeed 52 → 94, conversion mobile +23%, CA annuel +280K€.
| Métrique | Benchmark | Impact |
|---|---|---|
| LCP excellent | < 2.5s | Position Google ranking favorable |
| LCP a ameliorer | 2.5s - 4.0s | Warning dans Search Console |
| LCP poor | > 4.0s | Penalisation ranking, -23% conversions |
| TTFB excellent | < 200ms | Reduction LCP de 500-800ms |
| WebP vs PNG | -40 a 60% taille | Reduction LCP de 600-1200ms mobile |
| Preload LCP image | +300ms plus rapide | Fetchpriority high = browser priority |