Core Web Vitals w 2026 - LCP, INP i CLS po ludzku

Core Web Vitals to zestaw wskaźników Google opisujących, jak strona „czuje się” dla użytkownika: czy szybko się ładuje, czy płynnie reaguje i czy nie skacze pod palcem. Są częścią sygnałów rankingowych i - co ważniejsze - wprost wpływają na konwersję. Wolniejsza strona to wyższy współczynnik odrzuceń, krótszy czas wizyty i mniej dokończonych transakcji - dlatego optymalizacja wydajności zwraca się podwójnie: w SEO i w sprzedaży.

W tym przewodniku wyjaśniamy każdy z trzech wskaźników „po ludzku”, pokazujemy progi „dobrych” wyników, najczęstsze przyczyny problemów oraz konkretne kroki naprawcze - tak, żebyś mógł zacząć działać nawet bez zaplecza technicznego.

Czym są Core Web Vitals i dlaczego Google je liczy

Google chce serwować w wynikach strony, które są nie tylko trafne, ale i przyjemne w użyciu. Klasyczne metryki (np. czas ładowania całej strony) słabo oddawały realne doświadczenie, więc Google wybrał trzy wskaźniki, które najlepiej korelują z tym, jak użytkownik odbiera stronę: szybkość pojawienia się treści (LCP), responsywność na interakcje (INP) i stabilność układu (CLS). Razem tworzą część oceny „Page Experience”.

Ważne: Core Web Vitals nie zastąpią dobrej treści ani linków. Działają raczej jak „dogrywka” - przy dwóch porównywalnych stronach lepsze wskaźniki mogą przeważyć. A ponieważ wpływają też na konwersję, warto je poprawiać niezależnie od samego SEO.

Trzy wskaźniki, które trzeba znać

Jak poprawić LCP

LCP mierzy, kiedy pojawia się największy widoczny element nad „linią zgięcia” - zwykle obraz hero, baner lub duży nagłówek. Zły LCP najczęściej wynika z wolnego serwera (wysoki TTFB), ciężkiego, nieopóźnionego obrazu albo zasobów blokujących renderowanie. Działaj w tej kolejności:

• Optymalizuj największy element (zwykle obraz hero lub nagłówek) - kompresja, format WebP/AVIF, właściwy rozmiar.
• Używaj priority/preload dla kluczowego obrazu i unikaj ładowania go z opóźnieniem (lazy-loading na elemencie LCP to częsty błąd).
• Ogranicz czas odpowiedzi serwera (TTFB): cache, CDN, szybszy hosting.
• Eliminuj zasoby blokujące renderowanie (ciężki CSS/JS w <head>).
• Serwuj fonty lokalnie z preload zamiast łańcucha przekierowań do zewnętrznego CDN.

Jak poprawić INP

INP (Interaction to Next Paint) opisuje, jak szybko strona reaguje na działania użytkownika - kliknięcie, tapnięcie, wpisanie tekstu. Główny winowajca to JavaScript: gdy główny wątek przeglądarki jest zajęty wykonywaniem skryptów, interfejs „zawiesza się” na ułamki sekundy. Im więcej kodu i im cięższe skrypty third-party, tym gorszy INP.

• Zmniejsz ilość i ciężar JavaScriptu wykonywanego na starcie.
• Dziel długie zadania (long tasks) i odraczaj nieistotny kod (defer, dynamiczny import, requestIdleCallback).
• Uważaj na ciężkie skrypty third-party (czaty, widżety, trackery) - ładuj je leniwie lub po interakcji.
• Ogranicz pracę wykonywaną w handlerach zdarzeń (debounce, przeniesienie ciężkich operacji poza główny wątek).

Jak poprawić CLS

CLS karze za „skakanie” układu - gdy treść przesuwa się po załadowaniu i użytkownik klika nie to, co chciał. Najczęstsze przyczyny to obrazy bez zarezerwowanych wymiarów, reklamy/bannery wstrzykiwane nad treścią oraz fonty, które przy podmianie zmieniają wysokość tekstu.

• Ustaw wymiary (width/height) obrazów i osadzeń, żeby rezerwowały miejsce.
• Nie wstrzykuj treści nad istniejącą (np. banerów, cookie barów) po załadowaniu - rezerwuj dla nich miejsce z góry.
• Ładuj fonty tak, by ograniczyć przeskoki tekstu (font-display: swap + preload, dopasowane metryki fallbacku).
• Unikaj animacji zmieniających rozmiar/layout - preferuj transform i opacity.

Dane laboratoryjne kontra dane z terenu

To rozróżnienie myli najwięcej osób. Dane laboratoryjne (lab) pochodzą z jednorazowego, syntetycznego testu w kontrolowanych warunkach - tak działa Lighthouse. Dane z terenu (field, CrUX) to uśrednione wyniki realnych użytkowników z ostatnich 28 dni. Google do oceny rankingowej bierze pod uwagę dane z terenu.

Dlatego idealny wynik w Lighthouse nie gwarantuje dobrych Core Web Vitals w Search Console - Twoi użytkownicy mogą mieć wolniejsze łącza, starsze telefony albo wchodzić na cięższe podstrony. Optymalizuj „w labie”, ale weryfikuj „w terenie”.

Najczęstsze błędy, które psują wyniki

• Lazy-loading nałożony na obraz LCP (paradoksalnie opóźnia najważniejszy element).
• Testowanie tylko desktopa - Google priorytetowo ocenia mobile.
• Naprawianie pojedynczej podstrony zamiast szablonu, który generuje setki podobnych stron.
• Ignorowanie skryptów marketingowych, które potrafią dokładać sekundy do INP.
• Mylenie wyniku „Performance” w Lighthouse z Core Web Vitals - to powiązane, ale nie to samo.

Audyt Core Web Vitals krok po kroku

1. 1Zmierz stan wyjściowy w PageSpeed Insights (mobile i desktop) oraz w Google Search Console (dane z terenu).
2. 2Zidentyfikuj element LCP i jego czas - to zwykle najszybsza wygrana.
3. 3Sprawdź TTFB - jeśli serwer odpowiada wolno, żadna optymalizacja frontu w pełni tego nie nadrobi.
4. 4Przejrzyj raport „Reduce JavaScript / long tasks” pod kątem INP.
5. 5Znajdź źródła przesunięć układu (CLS) - obrazy bez wymiarów, late-loaded banery.
6. 6Wdróż poprawki na poziomie szablonu, nie pojedynczej strony.
7. 7Odczekaj ~28 dni i zweryfikuj dane z terenu w Search Console.

Czym zmierzyć

Dane „laboratoryjne” daje PageSpeed Insights i Lighthouse, a dane „z terenu” (realnych użytkowników) - raport Core Web Vitals w Google Search Console. Dodatkowo warto zajrzeć do rozszerzenia Web Vitals dla Chrome (podgląd na żywo). Audyto liczy te wskaźniki dla mobile i desktop w ramach audytu, wskazuje element LCP i podpowiada, co naprawić w pierwszej kolejności - sprawdź swoją stronę za darmo.