1. Strona główna
2. Dziennik
3. SEO

Core Web Vitals: jakie metryki obejmują i jak je sprawdzić

• Jacek Ślesicki
• 2 November 2026
• ok. 17 min czytania

Co to są Core Web Vitals?

Core Web Vitals to 3 podstawowe wskaźniki internetowe opisujące ładowanie, reakcję na interakcje i stabilność wizualną strony: LCP, INP oraz CLS. Przedstawiam je jako punkt wyjścia do diagnozy wygody korzystania z witryny. Zestaw opisuje dokumentacja web.dev, a wyniki pokazują PageSpeed Insights i Google Search Console.

Chcesz, żebym zajął się tym w Twojej firmie? Szczegóły znajdziesz w ofercie: Audyt SEO.

Strona może wyglądać poprawnie, a mimo to utrudniać czytanie: zdjęcie pojawia się późno, menu nie reaguje, reklama przesuwa akapit. Właśnie takie problemy pomagają rozdzielić CWV. Audyt SEO obejmuje szerszą diagnozę, ale te wskaźniki pozwalają nazwać konkretny objaw zamiast poprzestawać na stwierdzeniu „strona jest wolna”.

LCP, INP i CLS: co mierzy każdy wskaźnik?

LCP opisuje wyświetlenie największego elementu treści, INP responsywność interakcji, a CLS nieoczekiwane przesunięcia układu podczas korzystania ze strony.

Pełne nazwy to Largest Contentful Paint, Interaction to Next Paint i Cumulative Layout Shift. Każda metryka odpowiada na inne pytanie. Rozdzielam je, ponieważ przyspieszenie obrazu nie musi naprawić opóźnionego menu, a skrócenie pracy JavaScript nie zapewni miejsca na reklamę.

• LCP pomaga ocenić, jak szybko pojawia się główna treść widocznego obszaru strony.
• INP pomaga ocenić, jak sprawnie interfejs reaguje na działania użytkownika.
• CLS pomaga ocenić, czy elementy zmieniają położenie w sposób utrudniający korzystanie.
• FID jest wcześniejszą metryką responsywności, którą w zestawie CWV zastąpił INP.

Aktualny zestaw opisuje web.dev: Web Vitals. Sama znajomość skrótów nie wystarczy: do każdej liczby trzeba dopasować zachowanie strony.

Core Web Vitals: gdzie kończy się zakres pomiaru?

Core Web Vitals obejmują wybrane aspekty wydajności i stabilności, ale nie zastępują oceny treści, nawigacji ani dostępności strony.

Przykład: przycisk kontaktu może reagować natychmiast, lecz mieć niezrozumiałą etykietę. Dobry INP nie rozwiązuje tego problemu. Dlatego proponuję traktować CWV jako część większej kontroli, opisanej w materiale Co to jest SEO techniczne?. Wynik trzeba przełożyć na zadanie użytkownika: przeczytanie poradnika, znalezienie oferty albo wysłanie formularza.

Core Web Vitals: jakie są dobre wyniki?

Za dobre wartości przyjmuję progi dokumentacji: LCP do 2,5 s, INP do 200 ms i CLS do 0,1, oceniane na 75. percentylu. Progi podają web.dev oraz Google Search Console. Oceny telefonu i komputera należy czytać osobno, ponieważ dobry wynik jednej kategorii urządzeń nie opisuje automatycznie drugiej.

LCP, INP i CLS: progi oraz jednostki

Dobre progi dotyczą trzech różnych wielkości: czasu ładowania, opóźnienia reakcji i wyniku przesunięć układu.

Wskaźnik	Mierzony obszar	Jednostka	Dobry wynik
LCP	Wyświetlenie największego elementu treści	Sekundy	Do 2,5 s
INP	Reakcja wizualna na interakcje	Milisekundy	Do 200 ms
CLS	Nieoczekiwane przesunięcia układu	Bez jednostki	Do 0,1

Źródło progów: Web Vitals, aktualizacja 2024. CLS nie oznacza sekund ani procentu przesunięcia całej strony.

„pages should have a INP of 200 milliseconds or less.” - Philip Walton, Web Vitals, web.dev, aktualizacja 2024.

To zalecenie oznacza INP nieprzekraczający 200 ms. Nie należy jednak zamieniać każdego przekroczenia progu w alarm o identycznej wadze. Potrzebna jest jeszcze ocena zasięgu problemu i jego przyczyny.

75. percentyl: jak czytać ocenę?

Uporządkuj wyniki od najmniejszych do największych: 75. percentyl wskazuje wartość, której nie przekracza około 75% obserwacji, a nie ich średnią.

W uproszczonym przykładzie 100 pomiarów LCP wynik na poziomie 2,5 s oznacza, że około 75 pomiarów mieści się w tym czasie. Pozostałe mogą być gorsze. To przykład objaśniający statystykę, nie wynik konkretnego serwisu. Raport nie mówi, że każdy odwiedzający zobaczy treść równie szybko.

• Percentyl opisuje położenie wyniku w rozkładzie, więc nie należy podpisywać go jako średniej.
• Ocena mobilna wymaga osobnej interpretacji od oceny użytkowników komputerów.
• Pojedynczy test nie reprezentuje wszystkich urządzeń, połączeń i zachowań czytelników.
• Wynik graniczny uzasadnia dalszą obserwację, szczególnie po zmianie szablonu lub reklam.

Przy porównaniu zapisuję więc nie tylko wartość, lecz także urządzenie, zakres adresów i okres danych. Bez tych informacji dwie poprawnie odczytane liczby mogą prowadzić do błędnego wniosku.

PageSpeed Insights i Search Console: gdzie sprawdzić stronę?

Pojedynczy adres proponuję sprawdzić w PageSpeed Insights, a zasięg problemu w grupach podobnych adresów w Google Search Console. Dokumentacja obu narzędzi rozróżnia poziomy raportowania. Przed porównaniem wyników sprawdź, czy oglądasz konkretny URL, cały origin czy grupę stron, oraz czy wybrano ten sam rodzaj urządzenia.

Dane rzeczywiste i test laboratoryjny: czym się różnią?

Dane rzeczywiste opisują wcześniejsze doświadczenia użytkowników, natomiast test laboratoryjny Lighthouse odtwarza ładowanie strony w określonych warunkach pomiaru.

Chrome UX Report, czyli CrUX, zasila część terenową PageSpeed Insights. Narzędzie prezentuje tam ruchome okno poprzednich 28 dni. Lighthouse służy do diagnozy aktualnej wersji strony. Te informacje opisuje dokumentacja PageSpeed Insights.

Przykład: po usunięciu ciężkiego elementu test laboratoryjny może pokazać poprawę, choć historyczne dane nadal obejmują wcześniejszą wersję. Z kolei dobry test początkowego ładowania nie odtwarza automatycznie późniejszego otwierania menu. TBT pomaga diagnozować blokowanie głównego wątku, ale nie jest pomiarem INP.

1. Wprowadź konkretny adres artykułu, kategorii lub oferty do PageSpeed Insights.
2. Sprawdź kategorię urządzenia i oznaczenie zakresu danych terenowych.
3. Zapisz problematyczny wskaźnik oraz okres, którego dotyczy raport.
4. Otwórz diagnostykę Lighthouse i poszukaj elementu wymagającego dalszego badania.
5. Porównaj problem z grupami adresów w Google Search Console.

Taka kolejność pozwala oddzielić pytanie „co odczuwają użytkownicy?” od pytania „gdzie szukać przyczyny?”. Nie trzeba wybierać jednego raportu jako jedynego prawdziwego.

CrUX: dostępność danych i zakres originu

Brak danych CrUX oznacza brak podstaw do oceny terenowej na podstawie CrUX w danym zakresie, a nie automatycznie dobry lub zły wynik. Dane terenowe mogą być dostępne we własnym systemie RUM.

Jeżeli brakuje próbek dla URL, PageSpeed Insights może pokazać dane całego originu, czyli określonego połączenia protokołu, hosta i portu. Przykładowo ocena artykułu może wtedy opierać się na szerszym zbiorze stron. Nie przedstawiam jej jako pomiaru wyłącznie tego tekstu.

Search Console grupuje podobne adresy; przykładowy URL nie musi mieć identycznego wyniku jak grupa. Wyjaśnia to pomoc raportu Core Web Vitals. Nowy poradnik bez danych można nadal sprawdzać laboratoryjnie i ręcznie, bez dopisywania mu nieistniejącej oceny terenowej.

Core Web Vitals: jak ustalić kolejność poprawek?

Najpierw połącz problematyczny wskaźnik z konkretnym elementem strony, potem określ zasięg szablonu i sprawdź przyczynę. Taką kolejność proponuję dla WordPress i Astro. Poradniki optymalizacyjne web.dev opisują osobne ścieżki diagnozy LCP, INP i CLS; jedna ogólna operacja „przyspieszania strony” nie zastępuje ustalenia, co faktycznie przeszkadza użytkownikowi.

LCP i INP: jak znaleźć przyczynę opóźnienia?

Zacznij od wskazania elementu LCP albo interakcji z opóźnioną reakcją, a następnie prześledź zadania i zasoby poprzedzające jej wyświetlenie.

Przykład pierwszy: największym elementem jest zdjęcie otwierające artykuł. Sprawdź jego rozmiar, moment rozpoczęcia pobierania i sposób osadzenia. Przykład drugi: największy jest blok tekstu, więc sama kompresja zdjęć nie odpowiada na diagnozę. Poradnik optymalizacji LCP rozdziela opóźnienia pobierania zasobu i jego renderowania.

Przykład trzeci: kliknięcie przycisku filtrów uruchamia kosztowne przeliczanie interfejsu. Wtedy analizuj obsługę zdarzenia i zajętość głównego wątku. Dokładanie pamięci podręcznej na serwerze nie musi usunąć tej przyczyny. Dokumentacja INP wskazuje znaczenie opóźnienia wejścia, obsługi zdarzenia i prezentacji następnej klatki.

WordPress i Astro: co sprawdzić w szablonie?

Zacznij od szablonów artykułu i kategorii, a następnie sprawdź obrazy, fonty, skrypty oraz elementy wspólne dla wielu adresów.

Proponuję następującą listę kontrolną, niezależnie od technologii:

1. Szablon artykułu powinien przejść test z typową treścią, obrazami i aktywnymi dodatkami.
2. Szablon kategorii wymaga sprawdzenia siatki wpisów, miniaturek oraz mechanizmu filtrowania.
3. Element LCP wymaga identyfikacji w pomiarze, zamiast założenia, że zawsze jest zdjęciem.
4. Interaktywne menu wymaga próby otwarcia i zamknięcia podczas pracy pozostałych skryptów.
5. Każda poprawka wymaga ponownego sprawdzenia funkcji, które mogła zmienić.

Nie polecam migracji wyłącznie na podstawie nazwy CMS. W WordPress trzeba ocenić konkretny motyw i dodatki, w Astro wynikowy interfejs oraz dołączone skrypty. Oba środowiska należy mierzyć w wersji rzeczywiście udostępnianej czytelnikom. Sama zmiana technologii nie jest dowodem usunięcia przyczyny.

Reklamy i CLS: jak szukać przesunięć układu?

Zacznij od odtworzenia przesunięcia i sprawdź, czy obraz, reklama lub osadzony materiał mają zarezerwowane miejsce przed załadowaniem.

Przykład czwarty: reklama nad tekstem pojawia się później i spycha akapit. Przykład piąty: obraz bez określonych wymiarów rozszerza układ dopiero po pobraniu. Przykład szósty: osadzony film zmienia wysokość kontenera. Dla tych sytuacji poradnik optymalizacji CLS opisuje rezerwowanie przestrzeni i kontrolę treści dodawanych dynamicznie.

Proponuję również test porównawczy na kopii strony: ten sam adres z konkretnym skryptem i bez niego. Wyłączaj po jednym elemencie, aby zachować czytelny związek przyczyny ze skutkiem. Potem sprawdź poprawkę z reklamami i pozostałymi funkcjami włączonymi. Usunięcie funkcji tylko na czas pomiaru nie rozwiązuje problemu wersji użytkowej.

Core Web Vitals a SEO: czego nie gwarantują?

Dobrych Core Web Vitals nie traktuję jako gwarancji pozycji ani zamiennika treści odpowiadającej na zapytanie. Google Search Central potwierdza wykorzystanie CWV w systemach rankingowych, ale odrzuca gwarancję wysokich miejsc wynikającą z dobrych raportów. Podobnie wynik Lighthouse opisuje test wydajności, a nie obietnicę ruchu z wyszukiwarki.

Wynik Lighthouse i widoczność w Google

Wynik 100 punktów Lighthouse nie jest równoznaczny z zaliczeniem terenowej oceny CWV ani z wysoką pozycją strony.

„Core Web Vitals are used by our ranking systems.” - Google Search Central, Understanding page experience in Google Search results, aktualizacja 2026.

W tym samym dokumencie Google zaznacza, że dobry raport nie gwarantuje czołowych pozycji. Dlatego proponuję łączyć ocenę wydajności z oceną odpowiedzi na zapytanie. Źródło: Google Search Central: jakość strony w wynikach wyszukiwania.

Przykład siódmy: szybka strona oferty zawiera ogólny opis, lecz nie wyjaśnia zakresu usługi. Poprawa CLS tego nie uzupełni. Przykład ósmy: właściciel analizuje szybkość adresu, którego nie znajduje w wyszukiwarce. W takim przypadku potrzebna jest również osobna diagnoza indeksowania.

• Wydajność strony opisuje warunki korzystania z treści, a nie kompletność odpowiedzi.
• Indeksowanie wymaga osobnej kontroli, którą omawia materiał Jak zaindeksować stronę w Google?.
• Zmiana adresu wymaga rozumienia przekierowań, wyjaśnionych w tekście Co to jest przekierowanie 301?.
• Brak widoczności wymaga szerszej diagnozy, opisanej w poradniku Dlaczego strony nie ma w Google?.

Nie przypisuję każdej zmiany ruchu wdrożeniu technicznemu. Bez porównania okresów, zmian treści i pozostałych działań byłoby to zgadywanie.

Pomiar po wdrożeniu: jak ocenić efekt?

Zacznij od powtórzenia diagnostyki w porównywalnych warunkach, zapisz datę wdrożenia i dopiero potem obserwuj dane terenowe.

Rozdzielam trzy pytania: czy zmieniono kod, czy zniknął objaw i czy poprawę widać u użytkowników. To trzy różne dowody. Przy poprawce menu sprawdź reakcję menu; przy reklamie obserwuj przesunięcia treści. Nie oceniaj wykonania zadania wyłącznie po kolorze całego raportu.

Do opisu zmiany proponuję dopisać adresy kontrolne oraz sposób cofnięcia wdrożenia. Taki zapis ułatwia późniejsze ustalenie, czy kolejna aktualizacja przywróciła problem. Jeśli potrzebujesz omówienia diagnozy, napisz przez formularz kontaktowy i dołącz adres strony oraz raport.

Najczęściej zadawane pytania

Przy interpretacji Core Web Vitals rozdzielam wskaźniki, źródła danych i zakres raportu. PageSpeed Insights oraz Google Search Console mogą pokazywać różne fragmenty tego samego problemu. Poniższe odpowiedzi dotyczą dodatkowych sytuacji diagnostycznych, w tym brakującego INP, terminu kontroli po wdrożeniu i dokumentowania wyników.

INP: czy ocena CWV jest możliwa bez tego wskaźnika?

Tak, PageSpeed Insights dopuszcza zaliczenie oceny przy niewystarczających danych INP, jeśli dostępne LCP i CLS mają dobre wyniki. To wyjątek opisany w dokumentacji narzędzia, a nie potwierdzenie dobrej responsywności niezmierzonych interakcji.

Core Web Vitals: kiedy sprawdzić efekt poprawki w danych terenowych?

Efekt obserwuj przez kolejne dni, uwzględniając 28-dniowe okno danych PageSpeed Insights; nie oczekuj pełnej wymiany historii w dniu wdrożenia. Po upływie całego okna porównanie jest czytelniejsze, ale dostępność próbek i zmiany ruchu nadal wpływają na interpretację.

PageSpeed Insights: czy do testu potrzebny jest dostęp administracyjny?

Nie, podstawowy test publicznego adresu w PageSpeed Insights można uruchomić bez dostępu do panelu zarządzania witryną. Dostęp będzie potrzebny do wdrażania poprawek; proponuję przekazać wykonawcy raport wraz z adresem i opisem objawu.

Core Web Vitals: czy samo otwarcie strony wystarczy do testu menu?

Nie, otwarcie strony bez użycia menu nie odtwarza interakcji, której responsywność chcesz sprawdzić w diagnozie INP. Przejdź rzeczywisty scenariusz użytkownika: otwórz menu, wybierz pozycję i obserwuj reakcję interfejsu.

Core Web Vitals: jak opisać zgłoszenie dla programisty?

Zacznij od adresu, urządzenia i problematycznego wskaźnika, następnie dodaj raport oraz kroki odtworzenia objawu. Proponuję także wskazać oczekiwane zachowanie, na przykład brak przesunięcia akapitu po wczytaniu reklamy, zamiast ogólnego polecenia „popraw szybkość”.

Źródła i literatura

Podstawą definicji, progów i interpretacji raportów jest dokumentacja web.dev oraz Google. Rozdzielam dokumenty opisujące metryki od instrukcji narzędzi i stanowiska dotyczącego wyszukiwarki: PageSpeed Insights, Lighthouse i Google Search Console pełnią różne funkcje. Daty aktualizacji publikacji nie są datami pomiaru konkretnej witryny.

Definicje i raportowanie

Dokumentacja metryk i narzędzi pozwala sprawdzić znaczenie wartości oraz zakres prezentowanych danych.

1. Philip Walton, Web Vitals - aktualizacja 2024; definicje, progi i percentyle.
2. Google, About PageSpeed Insights - aktualizacja 2024; dane terenowe i laboratoryjne.
3. Google Search Console, raport Core Web Vitals - zasady grupowania adresów i interpretacji raportu.
4. Google Search Central, podstawowe wskaźniki internetowe - aktualizacja 2025; znaczenie wskaźników dla jakości strony.

Optymalizacja i wyszukiwanie

Poradniki techniczne opisują diagnozę przyczyn, a dokumentacja wyszukiwarki wyjaśnia ograniczenia wniosków dotyczących pozycji.

• Optimize Largest Contentful Paint - analiza ładowania największego elementu.
• Optimize Interaction to Next Paint - diagnoza opóźnionych interakcji.
• Optimize Cumulative Layout Shift - ograniczanie przesunięć układu.
• Understanding page experience in Google Search results - aktualizacja 2026; związek jakości strony z wyszukiwaniem.