Core Web Vitals: LCP, INP, CLS - jak je poprawić

Core Web Vitals to trzy metryki, którymi Google mierzy realne doświadczenie użytkowników Twojej strony - i uwzględnia je w rankingu. Tłumaczymy po ludzku, co mierzą LCP, INP i CLS, gdzie sprawdzić swoje wyniki i jak je poprawić bez przepisywania strony.

Czym są Core Web Vitals?

Core Web Vitals (podstawowe wskaźniki internetowe) to zestaw trzech metryk, którymi Google mierzy, jak strona faktycznie zachowuje się u realnych użytkowników: jak szybko pokazuje główną treść, jak sprawnie reaguje na kliknięcia i czy elementy nie skaczą podczas ładowania. Od 2021 roku wchodzą w skład sygnałów rankingowych - a od strony biznesowej korelują wprost z konwersją i współczynnikiem odrzuceń.

Kluczowa rzecz: Google ocenia dane terenowe (z przeglądarek prawdziwych użytkowników Chrome - raport CrUX), a nie tylko laboratoryjne testy. Dlatego licz się z tym, że wynik „u Ciebie na szybkim łączu" bywa lepszy niż to, co widzi Google.

LCP - jak szybko widać główną treść

LCP (Largest Contentful Paint) mierzy czas do wyświetlenia największego elementu w pierwszym ekranie - zwykle zdjęcia hero lub głównego nagłówka. Progi: dobrze ≤ 2,5 s, wymaga poprawy do 4 s, słabo powyżej.

Jak poprawić LCP?

  1. Szybki serwer (TTFB) - fundament: full page cache, PHP 8.4, NVMe; sam TTFB poniżej 200 ms załatwia zwykle pół sukcesu (jak ustawić cache);
  2. odchudź obraz hero - WebP/AVIF, realne wymiary, bez slidera; NIE ustawiaj lazy loadingu na obrazie hero (ma się ładować natychmiast, najlepiej z fetchpriority="high");
  3. ogranicz blokujące CSS/JS - wtyczki optymalizacyjne (LiteSpeed Cache, WP Rocket) generują krytyczny CSS i odraczają resztę;
  4. fonty - lokalny hosting fontów i font-display: swap, żeby tekst nie czekał na krój pisma.

INP - jak strona reaguje na interakcje

INP (Interaction to Next Paint) - następca FID od marca 2024 - mierzy opóźnienie reakcji na interakcje (kliknięcia, dotknięcia, klawisze) w całym cyklu życia strony. Progi: dobrze ≤ 200 ms, wymaga poprawy do 500 ms.

Jak poprawić INP?

  1. Mniej JavaScriptu - każdy skrypt śledzący, czat i widżet dokłada pracy głównemu wątkowi; usuń nieużywane, resztę ładuj po interakcji (opcje „delay JS");
  2. audyt wtyczek - w WordPressie jedna ciężka wtyczka (budowniczowie mega-menu, kalendarze, filtry) potrafi odpowiadać za większość opóźnień;
  3. rozbijaj długie zadania - to działka developera, ale efekt widać w zakładce Performance narzędzi Chrome;
  4. uważaj na animacje przy scrollu - modne efekty parallax bywają głównym winowajcą słabego INP na telefonach.

CLS - czy strona „skacze"

CLS (Cumulative Layout Shift) mierzy niestabilność układu: klasyczny scenariusz to tekst, który przeskakuje w dół, bo nad nim doładował się baner - a Ty właśnie kliknąłeś nie to, co chciałeś. Progi: dobrze ≤ 0,1.

Jak poprawić CLS?

  1. Wymiary obrazów - każdy obraz z atrybutami width/height (WordPress robi to sam, o ile motyw nie psuje) - przeglądarka rezerwuje miejsce zanim obraz się pobierze;
  2. rezerwuj miejsce na banery/reklamy/embedy - kontener o stałej wysokości zamiast wstrzykiwania „gdzie popadnie";
  3. fonty ze swap + dopasowany fallback - podmiana kroju nie powinna zmieniać wysokości tekstu;
  4. nie wstawiaj treści nad już widoczną - paski zgody cookies montuj jako nakładkę, nie element rozpychający stronę.

Gdzie sprawdzić swoje wyniki?

  • PageSpeed Insights (pagespeed.web.dev) - sekcja „Podstawowe wskaźniki internetowe" u góry to dane terenowe (jeśli strona ma wystarczający ruch), niżej test laboratoryjny z konkretnymi zaleceniami;
  • Search Console → Podstawowe wskaźniki internetowe - zbiorczy raport dla całej witryny z podziałem na grupy adresów mobile/desktop;
  • Chrome DevTools (F12) - panel Lighthouse i Performance do debugowania konkretnych elementów.

Mierz osobno różne typy podstron (główna, wpis bloga, karta produktu) - to różne szablony o różnych problemach.

Plan naprawy w rozsądnej kolejności

  1. Serwer i cache - TTFB < 200 ms (hosting z NVMe i LiteSpeed + full page cache) - poprawia LCP wszystkich podstron naraz;
  2. obrazy - WebP, wymiary, priorytet dla hero, lazy loading dla reszty;
  3. JavaScript - inwentaryzacja skryptów zewnętrznych i wtyczek, opóźnione ładowanie - główna dźwignia INP;
  4. stabilność układu - wymiary mediów i zarezerwowane kontenery - CLS;
  5. pomiar po 28 dniach - dane terenowe CrUX agregują ostatnie 28 dni, więc na potwierdzenie poprawy w Search Console trzeba miesiąc poczekać.

Najczęściej zadawane pytania

Jak mocno Core Web Vitals wpływają na pozycje?

To jeden z wielu sygnałów - świetna treść ze słabymi CWV nadal może wygrywać. Ale przy porównywalnej treści wygrywa szybsza strona; do tego dochodzi efekt pośredni: lepsze CWV = niższe odrzucenia = lepsze sygnały behawioralne = wyższa konwersja. Optymalizacja zwraca się niezależnie od rankingu.

Test laboratoryjny mam zielony, a dane terenowe czerwone - jak to możliwe?

Laboratorium testuje jedno urządzenie w jednym momencie; teren to Twoi realni użytkownicy - często na średnich telefonach i słabym LTE. Ufaj terenowi; laboratorium służy do diagnozy, nie oceny.

Co mogę zrobić bez programisty?

Zaskakująco dużo: szybki hosting, wtyczka cache/optymalizacyjna, konwersja obrazów do WebP, usunięcie zbędnych wtyczek i skryptów. To typowo 80% efektu. Resztę - krytyczny CSS, refaktor skryptów - zostaw specjaliście.

Podsumowanie

LCP = pokaż treść szybko, INP = reaguj natychmiast, CLS = nic nie może skakać. Trzy metryki, jeden wspólny mianownik: lekka strona na szybkim serwerze. Większość „czerwonych" wyników w polskim internecie naprawia kombinacja: hosting z NVMe i cache (znajdziesz go u nas), WebP i dyscyplina we wtyczkach - bez przepisywania strony od zera.

Powiązane poradniki

Wszystkie poradniki z kategorii: Szybkość i wydajność

Powiązane usługi McProdukt

Zobacz również