LCP (Largest Contentful Paint) mierzy czas, jaki upływa między początkiem ładowania strony a momentem, w którym największy widoczny element w viewporcie zostaje wyrenderowany. Typowo są to: obraz hero, blok tekstu H1 + akapit wstępu, poster wideo, banner. To metryka najbardziej reprezentatywna dla „odczuwalnej szybkości” przez użytkownika i jeden z trzech filarów Core Web Vitals obok CLS i INP.
Progi Google: ≤ 2,5 s = dobry, 2,5–4 s = wymaga poprawy, > 4 s = zły — mierzone na 75. percentylu na realnych użytkownikach Chrome (CrUX). Typowe przyczyny złego LCP: nieoptymalizowany obraz hero (PNG 2 MB zamiast AVIF 80 KB), fonty blokujące rendering, JavaScript render-blocking, wolny lub źle zlokalizowany hosting, brak SSG lub CDN. Na nieoptymalizowanej stronie WordPress regularnie spotyka się LCP rzędu 5–8 s na mobile 4G — co jest dyskwalifikujące w konkurencyjnym SEO.
Optymalizacje, które naprawdę działają, w kolejności skutku: (1) serwowanie obrazu hero w AVIF/WebP z `priority` i `fetchpriority="high"` (Next.js Image robi to natywnie), (2) preload krytycznych fontów z `preload` i `font-display: swap`, (3) przejście na SSG lub ISR serwowane z edge CDN, (4) lazy-load wszystkiego, co nie jest w początkowym viewporcie. Poprawiamy to podczas bezpłatnego audytu lub dedykowanego projektu na stronie na zamówienie.
Quick winy, aby zbić LCP poniżej 2 s
- Obraz hero w AVIF/WebP + atrybuty `width/height` + `priority` (Next.js) lub `fetchpriority="high"`.
- Preload krytycznych fontów + `font-display: swap`, aby uniknąć FOIT (niewidocznego tekstu).
- [SSG](/glossaire/ssg/) lub [ISR](/glossaire/isr/) serwowane z edge CDN (Vercel, Cloudflare) — eliminuje TTFB serwera.
- Odraczanie całego niekrytycznego JS: analytics, widget czatu, third-party przez `defer` lub ładowanie po LCP.
