Przejdź do treści
WydajnośćHot

Core Web Vitals 2025 — wynik PageSpeed, który ma znaczenie

Konkretny przewodnik: LCP, INP, CLS. Co optymalizować jako pierwsze i jak mierzyć efekty.

20 kwi 2025·8 min czytania

Core Web Vitals to zestaw trzech wskaźników, które Google używa do oceny doświadczenia użytkownika na stronie. Od 2024 roku INP (Interaction to Next Paint) zastąpił FID jako oficjalny wskaźnik interaktywności. W 2025 roku pomiaru CWV dokonuje się na realnych użytkownikach — dane z Lighthouse to tylko wskazówka, nie decydujący wynik.

LCP — Largest Contentful Paint

LCP mierzy czas od załadowania strony do wyrenderowania największego elementu widocznego w oknie — najczęściej hero image lub nagłówka H1. Dobry wynik to poniżej 2,5 sekundy. Złe LCP wynika głównie z trzech powodów: obraz hero jest za ciężki, font blokuje renderowanie, lub serwer odpowiada wolno.

  • Dodaj `<link rel="preload" as="image">` dla hero image w `<head>` — skraca LCP o 300–800ms
  • Konwertuj obrazy do WebP lub AVIF — zmniejsza rozmiar o 40–60% bez utraty jakości
  • Użyj `fetchpriority="high"` na img LCP — przeglądarka pobiera go priorytetowo
  • Wyeliminuj render-blocking CSS — inline krytyczne style, resztę ładuj async
  • CDN z edge nodes blisko użytkownika skraca TTFB, co bezpośrednio poprawia LCP

INP — Interaction to Next Paint

INP mierzy czas od interakcji użytkownika (kliknięcie, tap, wpisanie) do wyrenderowania kolejnej klatki. Dobry wynik to poniżej 200ms. Problemy z INP najczęściej wynikają z długich zadań JavaScript blokujących główny wątek przeglądarki.

  • Podziel długie zadania JS na mniejsze przy użyciu `scheduler.yield()` lub `setTimeout(0)`
  • Lazy-load ciężkie biblioteki — GSAP, chart.js, player wideo — dopiero gdy są potrzebne
  • Unikaj synchronicznych operacji DOM w event handlerach — używaj requestAnimationFrame
  • Profiluj z Chrome DevTools Performance tab — szukaj zadań powyżej 50ms (Long Tasks)
  • Rozważ przeniesienie obliczeń do Web Worker jeśli masz złożone operacje nieblokujące UI

CLS — Cumulative Layout Shift

CLS mierzy sumę nieoczekiwanych przesunięć elementów w trakcie ładowania strony. Dobry wynik to poniżej 0,1. Najczęstsze przyczyny to brakujące wymiary obrazów, fonty bez size-adjust, i dynamicznie wstrzykiwana treść (bannery cookie, reklamy).

  • Zawsze podawaj width i height na elementach `<img>` — przeglądarka rezerwuje miejsce przed pobraniem
  • Użyj `font-display: optional` lub `size-adjust` w @font-face — eliminuje FOUT/FOIT
  • Dla dynamicznych treści (bannery, skeletons) rezerwuj miejsce z min-height
  • Unikaj wstawiania treści nad fold po załadowaniu strony — to najgorszy CLS
  • Animacje CSS transform/opacity nie generują CLS — używaj ich zamiast animowania top/left/margin

Narzędzia do pomiaru

PageSpeed Insights pokazuje dane z Chrome User Experience Report (crUX) — to dane z realnych użytkowników Chrome w ciągu ostatnich 28 dni. Lighthouse w DevTools to dane z laboratorium (twój komputer + twoja sieć). Oba są potrzebne, ale crUX jest decydujący dla rankingu Google.

  • PageSpeed Insights (pagespeed.web.dev) — sprawdź wynik dla mobile i desktop osobno
  • Search Console → Core Web Vitals — raport dla całej domeny w czasie
  • Chrome DevTools → Performance → Web Vitals — szczegółowy profil
  • web-vitals npm library — zbieranie metryk z realnych użytkowników do GA4
  • GTmetrix — waterfall requests, filmstrip, analiza LCP element

Kolejność optymalizacji

Jeśli masz ograniczony czas, zacznij od LCP — ma największy wpływ na ranking i doświadczenie użytkownika. Następnie CLS, bo złe przesunięcia są frustrujące. INP na końcu, chyba że strona jest wyjątkowo interaktywna. Zawsze mierz po każdej zmianie — niektóre optymalizacje mogą pogorszyć inne wskaźniki.

Kluczowe wnioski

  • 1.LCP poniżej 2,5s — preload hero image, WebP, CDN
  • 2.INP poniżej 200ms — unikaj Long Tasks, lazy-load JS
  • 3.CLS poniżej 0,1 — podawaj wymiary img, font-display: optional
  • 4.Mierz crUX (PSI), nie tylko Lighthouse — Google używa danych realnych
  • 5.Optymalizuj w kolejności: LCP → CLS → INP