Core Web Vitals: co mierzą, jak je sprawdzić i czy wpływają na pozycje

Krótka odpowiedź: co to są Core Web Vitals

Core Web Vitals (po polsku podstawowe wskaźniki internetowe) to trzy pomiary Google, które opisują, jak strona działa u prawdziwych użytkowników: jak szybko się ładuje (LCP), jak szybko reaguje na kliknięcia (INP) i czy elementy nie skaczą podczas przeglądania (CLS). Dobry wynik to LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1.

Google pisze wprost, że systemy rankingowe korzystają z Core Web Vitals. Pisze też, że dobry wynik nie gwarantuje pozycji na górze wyników, a wyszukiwarka stara się pokazać najtrafniejszą treść nawet przy gorszym doświadczeniu strony. Wyniki swojej strony sprawdzisz za darmo w Search Console i w PageSpeed Insights.

LCP, INP i CLS: co mierzą i jakie są progi

LCP (Largest Contentful Paint) to czas, po którym na ekranie pojawia się największy element widocznej części strony, zwykle zdjęcie główne albo duży blok tekstu. Klient widzi wtedy, że strona „już jest”.

INP (Interaction to Next Paint) mierzy, jak szybko strona reaguje na kliknięcie myszą, dotknięcie ekranu i naciśnięcie klawisza. Przewijanie i najechanie kursorem się nie liczą. Pod uwagę bierze wszystkie interakcje w czasie wizyty, a wynikiem jest najdłuższa z nich, z pominięciem pojedynczych skrajnych przypadków. Typowy objaw złego INP: klient klika „Dodaj do koszyka” i przez chwilę nic się nie dzieje.

CLS (Cumulative Layout Shift) opisuje nieoczekiwane przesunięcia treści. Czytasz tekst, ładuje się baner i wszystko zjeżdża w dół, a palec trafia w inny przycisk niż zamierzony.

INP zastąpił wcześniejszy wskaźnik FID w marcu 2024 roku. FID mierzył tylko opóźnienie pierwszej interakcji na stronie, INP obejmuje wszystkie. Jeśli poradnik nadal przedstawia FID jako aktualny wskaźnik Core Web Vitals, ta jego część jest nieaktualna. Google zapowiada, że stabilne wskaźniki zmieniają się nie częściej niż raz w roku.

Skąd Google bierze dane

Ocena opiera się na danych od prawdziwych użytkowników przeglądarki Chrome, zbieranych w raporcie na temat użytkowania Chrome (CrUX). Liczy się więc to, jak strona działa u klientów, na ich telefonach i łączach. Szybkie otwieranie na Twoim komputerze w biurze niewiele o tym mówi.

Trzy zasady warto zapamiętać:

• 75% wizyt. Strona ma dobry wynik, jeśli próg osiąga co najmniej 75% wizyt. Wolniejsze telefony i słabszy zasięg też wchodzą do tej puli.
• 28 dni. Dane obejmują ostatnie 28 dni i są aktualizowane codziennie, więc efekt poprawki widać stopniowo, a pełny dopiero po 28 dniach.
• Telefon i komputer osobno. Strona może mieć dobre wyniki na komputerach i słabe na telefonach.

Przy małym ruchu Google może nie mieć dość pomiarów dla pojedynczych stron. Wtedy pokazuje wynik dla wszystkich stron pod tym samym protokołem i hostem, na przykład https://www.example.com, albo nie pokazuje żadnego.

Raport Core Web Vitals w Search Console krok po kroku

Raport pokazuje stan całego serwisu, osobno dla urządzeń mobilnych i komputerów. Jak dodać stronę do Search Console i jakie inne raporty tam znajdziesz, opisujemy w przewodniku po Google Search Console.

1. Otwórz raport Core Web Vitals i wybierz Urządzenie mobilne albo Komputer.
2. Spójrz na trzy stany: „Słabej jakości”, „Wymagana poprawa” i „Dobrej jakości”. Pod wykresem jest tabela z problemami, na przykład za długim LCP na telefonach.
3. Kliknij wiersz problemu. Zobaczysz grupy adresów URL, czyli zestawy podobnych stron, na przykład wszystkie karty produktów. Wynik dotyczy całej grupy. Stan grupy to stan jej najsłabszego wskaźnika: dobry INP nie uratuje grupy ze słabym CLS.
4. Kliknij przykładowy adres, żeby zobaczyć inne strony z grupy. Są posortowane według liczby wyświetleń, więc te na górze najmocniej wpływają na wynik.
5. Przekaż raport programiście. Pomoc Search Console zaleca zacząć od adresów „Słabej jakości”, a potem zająć się problemami, które dotyczą większości stron albo stron najważniejszych dla Ciebie.
6. Po wdrożeniu poprawek kliknij „Rozpocznij śledzenie” na stronie problemu. Search Console przez 28 dni obserwuje dane i sprawdza, czy problem wrócił. Kliknięcie nie wywołuje ponownego indeksowania. Postęp pokaże przycisk „Sprawdź szczegóły”.

Komunikat „Brak dostępnych danych” oznacza, że usługa jest nowa w Search Console albo strona ma za mało wizyt w Chrome. Wtedy sprawdzaj pojedyncze adresy w PageSpeed Insights.

Jeśli stan wielu stron zmienił się, choć nikt nic nie ruszał, pomoc podaje typowe powody: strony były na granicy progu, a przeważył wzrost ruchu, wolniejszy serwer zdjęć albo zmiana po stronie użytkowników, na przykład nowa wersja przeglądarki.

PageSpeed Insights: dane od użytkowników a test laboratoryjny

PageSpeed Insights pokazuje dwie różne rzeczy: dane od użytkowników i wynik testu laboratoryjnego.

• Dane od użytkowników to wyniki od prawdziwych użytkowników z ostatnich 28 dni, te same co w Search Console. Tu jest ocena Core Web Vitals: strona ją zalicza, gdy wszystkie trzy wskaźniki są dobre dla 75% wizyt. Jeśli brakuje danych INP, wystarczą dobre LCP i CLS.
• Diagnostyka to test laboratoryjny programu Lighthouse z wynikiem od 0 do 100. W teście mobilnym Lighthouse symuluje telefon średniej klasy w sieci komórkowej, a w teście komputerowym komputer z łączem przewodowym. Pomaga znaleźć przyczyny, ale nie mierzy INP, bo nikt w teście nie klika.

Wynik 100 w teście nie jest celem samym w sobie. Google pisze, że dążenie do idealnego wyniku tylko z powodów SEO może nie być najlepszym wykorzystaniem czasu. Dla wyszukiwarki liczą się dane od użytkowników.

Dlaczego liczby w PageSpeed Insights i w Search Console się różnią? Search Console pokazuje wynik grupy podobnych stron, a PageSpeed Insights zwykle pojedynczego adresu, który może od grupy odstawać. PageSpeed Insights usuwa też z adresu parametry, a raport w Search Console je uwzględnia.

Czy Core Web Vitals wpływają na pozycje w Google

Tak, ale jako jeden z wielu sygnałów. W dokumentacji Google o wrażeniach z korzystania ze strony są cztery zdania, które warto znać:

• Core Web Vitals są używane przez systemy rankingowe Google.
• Nie ma jednego sygnału: systemy rankingowe patrzą na wiele sygnałów związanych z wrażeniami użytkownika.
• Google zawsze stara się pokazać najtrafniejszą treść, nawet jeśli wrażenia ze strony są słabe.
• Dobre wyniki w Search Console nie gwarantują pozycji na górze wyników.

Pozostałe elementy wrażeń ze strony, poza Core Web Vitals, według Google nie pomagają bezpośrednio w pozycjach. Google ocenia strony zwykle pojedynczo, choć ma też oceny dla całej witryny.

Skoro Google stawia trafność treści wyżej, przy nagłym spadku widoczności sprawdź też inne przyczyny. Całą ścieżkę opisujemy w tekście o tym, jak ustalić przyczynę spadku pozycji w Google.

Co najczęściej psuje wyniki i jak to poprawić

Wolne LCP

Google rozkłada LCP na cztery części: czas do otrzymania pierwszego bajtu HTML (z przekierowaniami, DNS i nawiązaniem połączenia), opóźnienie startu pobierania głównego zasobu, czas jego pobierania i czas do wyświetlenia. Najczęstsze poprawki: mniejsze zdjęcie główne w nowoczesnym formacie, wyłączenie leniwego ładowania tego zdjęcia (web.dev pisze wprost, żeby nigdy tak nie ładować obrazu LCP), oznaczenie go wysokim priorytetem, pamięć podręczna i CDN. To, jak szybko serwer odpowiada robotowi Google, pokazuje raport, który omawiamy w tekście o statystykach indeksowania w Search Console.

<img src="/baner.webp" width="1200" height="600" fetchpriority="high" alt="...">

Słabe INP

Za wolną reakcję odpowiada zwykle JavaScript, który zajmuje przeglądarkę długimi zadaniami. Na sklepach i stronach z wieloma wtyczkami warto przejrzeć dodatkowe skrypty i wyłączyć te, z których nikt nie korzysta. Programista znajdzie długie zadania w narzędziach dla programistów w Chrome.

Wysoki CLS

Według web.dev najczęstsze przyczyny to zdjęcia bez wymiarów, reklamy, osadzone filmy i ramki bez zarezerwowanego miejsca, treści doładowywane po wyświetleniu strony oraz czcionki internetowe. Poprawki: atrybuty width i height przy zdjęciach i filmach, stałe miejsce na baner lub reklamę, wcześniejsze ładowanie czcionek.

Pomoc Search Console podaje też prostą regułę dla osób bez wiedzy technicznej: strona razem z zasobami poniżej 500 KB i najwyżej 50 zasobów, żeby działała szybko na telefonach.

Nasze zalecenia: sprawdzaj też ważne karty produktów, patrz na dane od użytkowników obok wyniku Lighthouse i pamiętaj, że przez 28 dni po poprawce raport obejmuje też pomiary sprzed zmiany.

Co się zmienia w 2026 roku

Stan na 28 października 2026: trzy wskaźniki i ich progi są bez zmian. W tym roku doszły dwie nowości, obie eksperymentalne.

• Pomiar stron bez przeładowania. 13 października 2026 Chrome dodał do danych CrUX eksperymentalne wersje LCP, INP i CLS, które liczą też przejścia w aplikacjach zmieniających treść i adres bez przeładowania strony. Search Console korzysta z obecnych danych, dopóki te wskaźniki nie przestaną być eksperymentalne. Chrome celuje w maj 2027 roku, zależnie od opinii. Strony, które przy przejściu pod nowy adres wczytują z serwera nowy dokument HTML, jak wiele blogów i serwisów informacyjnych, nie powinny zobaczyć zmian.
• Dane o reklamach. We wrześniu 2026 Google dopisał do dokumentacji wrażeń ze strony eksperymentalne dane CrUX o reklamach, na przykład ich liczbie i gęstości. Google nie podał, że wpływają na pozycje.

Nie wiadomo, jaką wagę mają Core Web Vitals wśród innych sygnałów. Google tej liczby nie podaje. Jeśli chcesz sprawdzić szybkość strony razem z indeksowaniem i treścią, robimy to w ramach audytu SEO i GEO.