Core Web Vitals: LCP, INP i CLS — jak je zmierzyć i poprawić

Core Web Vitals to trzy metryki Google opisujące realne wrażenia z korzystania ze strony: LCP (jak szybko pojawia się główna treść), INP (jak szybko strona reaguje na kliknięcie) i CLS (czy układ nie skacze pod palcem). Definicje znajdziesz wszędzie — problem zaczyna się wtedy, gdy PageSpeed Insights pokazuje jeden wynik, Search Console drugi, a Ty nie wiesz, któremu wierzyć. Ten poradnik rozplątuje właśnie ten węzeł: skąd biorą się dwa różne wyniki, co robić, gdy Twojej strony w ogóle nie ma w danych Google, i co sprawdzić osobno dla każdej z trzech metryk.

Trzy metryki, trzy progi i jeden percentyl

Strona zalicza Core Web Vitals, gdy LCP wynosi 2,5 sekundy lub mniej, INP 200 milisekund lub mniej, a CLS 0,1 lub mniej. Ocena nie dotyczy jednego wczytania, tylko 75. percentyla wszystkich wczytań, liczonego osobno dla urządzeń mobilnych i osobno dla desktopowych.

Tylko dla INP dokumentacja rozdziela osobno pasmo „wymaga poprawy” i „słaby”. 75. percentyl znaczy tyle, że trzy czwarte wczytań musi zmieścić się w progu — Twój telefon na szybkim łączu nie jest reprezentatywny, liczy się ogon wolniejszych sesji. INP zastąpiło FID (First Input Delay) i od 2024 roku jest stabilną metryką Core Web Vitals; FID zostało wycofane, więc każdy materiał operujący tym skrótem jako aktualną metryką jest nieaktualny. Same Core Web Vitals nie mówią przy tym nic o tym, czy z witryny da się korzystać z klawiatury albo czytnikiem ekranu — to osobny obszar, który porządkuje dostępność strony według EAA i WCAG.

Dlaczego PageSpeed Insights pokazuje co innego niż Search Console

Bo to dwa różne rodzaje pomiaru, a nie dwa ujęcia tego samego. Ocena Lighthouse w PageSpeed Insights to dane laboratoryjne: jedno wczytanie jednego adresu, na symulowanym łączu i symulowanym urządzeniu, w sterylnych warunkach. Raport Core Web Vitals w Google Search Console to dane polowe z CrUX (Chrome User Experience Report): realne wczytania realnych użytkowników Chrome, agregowane na 75. percentylu w ruchomym oknie 28 dni.

Dla oceny Google liczą się dane polowe. Dane laboratoryjne są narzędziem diagnostycznym — mówią, co naprawić, nie jak stronę widzi wyszukiwarka. Sam PageSpeed Insights pokazuje oba zestawy: górna sekcja to dane polowe z CrUX, dolna to test Lighthouse uruchomiony przed chwilą.

Co zrobić, gdy Twojej strony nie ma w danych CrUX

Jeśli witryna ma zbyt mało ruchu, CrUX nie zbierze dla niej danych i żadne narzędzie Google nie pokaże wyniku polowego — wtedy jedyną drogą jest własny pomiar. To najczęstsza sytuacja typowej strony firmowej i powód, dla którego właściciele takich witryn utykają na komunikacie o braku wystarczających danych.

Własny pomiar składa się z trzech elementów. Po pierwsze, biblioteka JS web-vitals wpięta w stronę — zbiera LCP, INP i CLS od Twoich użytkowników i wysyła je do narzędzia analitycznego; spięcie tych zdarzeń z systemem raportowym to zwykła integracja systemów w firmie, nie osobny projekt. Po drugie, rozszerzenie Web Vitals do Chrome, które pokazuje wartości na żywo podczas ręcznego przechodzenia po stronie. Po trzecie, testy na realnych urządzeniach — telefon ze średniej półki na sieci komórkowej, a nie tylko laptop deweloperski na światłowodzie.

Do tego dochodzą narzędzia laboratoryjne z historią pomiarów: WebPageTest, GTmetrix i DebugBear pozwalają porównać kolejne wdrożenia i wychwycić regresję, zanim zauważą ją użytkownicy.

Czy Core Web Vitals są czynnikiem rankingowym

Tak, ale nie w takim sensie, w jakim się to zwykle sprzedaje. Dokumentacja Google dla wyszukiwarki (developers.google.com/search/docs/appearance/page-experience) stwierdza wprost: „Core Web Vitals are used by our ranking systems”. W tym samym miejscu pada jednak drugie zdanie: „There is no single signal” — nie istnieje pojedynczy „page experience ranking system”, a wyniki Core Web Vitals są jednym z wielu sygnałów.

Uczciwy wniosek jest niesymetryczny. Dobre wyniki niczego nie gwarantują: strona z idealnym LCP, INP i CLS, ale słabą treścią, nie wygra z lepszą odpowiedzią na pytanie użytkownika. Złe wyniki potrafią za to kosztować — i to podwójnie: jako sygnał brany pod uwagę przez systemy rankingowe oraz jako realna bariera dla użytkownika, który zamyka kartę, zanim strona zareaguje. Dlatego Core Web Vitals traktuj jako higienę techniczną, nie jako dźwignię pozycji.

Ścieżka diagnostyczna osobno dla LCP, INP i CLS

Każda z trzech metryk psuje się z innego powodu, więc wspólna lista porad w rodzaju „kompresuj obrazy” nie wystarczy. Poniżej kolejność, w której naprawdę warto sprawdzać.

Złe LCP

1. W PageSpeed Insights sprawdź, który element został oznaczony jako LCP — zwykle jest to grafika główna, baner albo duży nagłówek.
2. W Chrome DevTools otwórz panel Performance, nagraj wczytanie i w sekcji Timings znajdź znacznik LCP: zobaczysz, w której sekundzie zaczyna się pobieranie tego zasobu.
3. W zakładce Network sprawdź, czy plik LCP nie czeka w kolejce za arkuszami stylów i skryptami oraz czy przypadkiem nie ma ustawionego leniwego ładowania.
4. Oceń sam zasób: format, waga, wersja dopasowana do szerokości ekranu, priorytet pobierania.
5. Zmierz czas odpowiedzi serwera — WebPageTest pokaże rozbicie na TTFB, transfer i renderowanie. Jeśli serwer odpowiada wolno, żadna optymalizacja grafiki tego nie nadrobi.

Złe INP

1. Włącz rozszerzenie Web Vitals do Chrome i klikaj po stronie tak, jak robi to użytkownik: menu, filtry, koszyk, formularz. Rozszerzenie pokaże wartość INP dla konkretnej interakcji.
2. Powtórz najgorszą interakcję z nagrywaniem w panelu Performance i poszukaj długich zadań blokujących główny wątek.
3. Sprawdź, który skrypt te zadania wywołuje. Na stronach firmowych to prawie zawsze kod zewnętrzny, nie własny.
4. Zablokuj po kolei podejrzane skrypty (request blocking w zakładce Network) i powtórz pomiar — zobaczysz, ile kosztuje każde z narzędzi.
5. W danych polowych sprawdź, na których podstronach INP jest najgorszy. Formularz i wyszukiwarka produktów wypadają zwykle gorzej niż strona główna.

Złe CLS

1. W DevTools włącz podświetlanie obszarów przesunięcia układu — od razu zobaczysz, które bloki skaczą.
2. Sprawdź obrazy, ramki i osadzone odtwarzacze bez zadeklarowanych wymiarów. To najczęstsza pojedyncza przyczyna.
3. Przyjrzyj się fontom: podmiana kroju po wczytaniu potrafi przesunąć całe akapity.
4. Wypisz wszystko, co dokłada się do strony po jej wyrenderowaniu — baner zgody, pasek promocyjny, okno czatu, rekomendacje produktów.
5. Mierz na wąskim ekranie. Na desktopie CLS bywa zerowy, a na telefonie ten sam układ rozjeżdża się przy każdym wczytaniu.

Skrypty zewnętrzne: czat, piksele i baner zgody

Na typowej stronie firmowej najczęstszą przyczyną złego INP i CLS nie jest własny kod, tylko skrypty dokładane przez marketing i narzędzia zewnętrzne. Każde takie narzędzie — piksel reklamowy, mapa, widżet opinii, testy A/B, okno czatu, platforma zarządzania zgodami — dokłada pracę na głównym wątku dokładnie w tym momencie, gdy użytkownik zaczyna klikać.

Baner zgody jest przypadkiem szczególnym, bo uderza w obie metryki naraz: przesuwa treść, jeśli nie ma zarezerwowanego miejsca, i blokuje wątek własnym skryptem. Jego układ ma też znaczenie dla dostępności strony, bo baner przykrywający treść bez możliwości zamknięcia klawiaturą jest problemem niezależnie od wyniku CLS.

Praktyczna reguła: każdy skrypt zewnętrzny musi mieć właściciela i uzasadnienie. Raz na kwartał przejdź listę i usuń to, czego nikt nie używa — narzędzia po zakończonych kampaniach potrafią zostawać w kodzie latami. Zanim dołożysz kolejne, sprawdź, czy tej samej danej nie da się pobrać przez integrację z systemem, który już masz, zamiast wstrzykiwać obcy kod do przeglądarki użytkownika. Gdy motyw i lista wtyczek dokładają więcej pracy, niż da się z nich wyciąć, decyzja przenosi się o poziom wyżej — na to, czy zostajesz przy WordPressie, czy przechodzisz na stronę dedykowaną.

Ile szybkość realnie znaczy dla sprzedaży

Najlepiej udokumentowanym punktem odniesienia jest badanie „Milliseconds Make Millions”, zlecone przez Google i wykonane przez Deloitte oraz agencję 55, opublikowane w 2020 roku na danych zebranych pod koniec 2019 roku. Objęło 37 marek europejskich i amerykańskich, ponad 30 mln sesji, z pomiarem czasów mobilnych przez 30 dni.

Wynik dla handlu detalicznego: poprawa czasu wczytywania o 0,1 sekundy wiązała się ze wzrostem konwersji o 8,4% i wartości koszyka o 9,2%. Dla branży turystycznej — konwersje wyższe o 10,1%, wartość koszyka o 1,9%.

Jedno zastrzeżenie jest tu ważniejsze niż same liczby: to badanie korelacyjne, nie eksperyment przyczynowy. Pokazuje, że szybsze sesje szły w parze z lepszymi wynikami sprzedażowymi — nie dowodzi, że skrócenie czasu o 0,1 s samo z siebie podniesie Twoją konwersję o tyle samo. Traktuj te wartości jako argument za tym, żeby wydajność w ogóle mierzyć, a nie jako prognozę zwrotu z inwestycji. W handlu warto przy okazji sprawdzić, ile z tych poprawek w ogóle da się wprowadzić na Twoim silniku — dostęp do szablonów i skryptów to jedno z kryteriów rozstrzygających, czy prowadzić sklep na abonament czy dedykowany.

Kiedy zobaczysz efekt poprawki i jak rozliczyć wykonawcę

Efektu nie zobaczysz od razu — dane polowe są liczone w ruchomym oknie 28 dni, więc raport w Search Console przez kilka tygodni po wdrożeniu miesza ruch sprzed poprawki z ruchem po niej. Zaraz po zmianie sprawdzaj więc własne pomiary (biblioteka web-vitals, rozszerzenie Web Vitals, testy laboratoryjne), a raport Google traktuj jako potwierdzenie, które przychodzi z opóźnieniem. Nagły spadek wyniku bezpośrednio po wdrożeniu to zwykle sygnał regresji, a nie szumu.

Drugi wniosek dotyczy umowy. Wydajność jest wymierna, więc powinna być zapisanym wymaganiem odbioru — nieopisany wcześniej zakres wraca jako koszt poprawek po starcie, dokładnie tym samym mechanizmem, który decyduje o tym, ile kosztuje aplikacja mobilna czy przebudowa sklepu. Wymaganie dotyczące Core Web Vitals wpisz do dokumentu, od którego zaczyna się rozmowa z wykonawcą, czyli do briefu dla software house.

Jeśli dopiero planujesz nową witrynę albo przebudowę obecnej, opisz jej zakres w kreatorze briefu — wymagania wydajnościowe najtaniej ustala się przed projektem, a nie po odbiorze. Gdy przebudowa obejmuje zmianę adresów albo platformy, obok wymagań wydajnościowych potrzebujesz drugiej listy kontrolnej: migracji strony bez utraty pozycji, bo lepsze LCP nie zrekompensuje zerwanego mapowania adresów.