Core Web Vitals w sklepie: LCP, INP i CLS po polsku, z przykładami

Core Web Vitals to trzy liczby, którymi Google opisuje, jak szybko strona się pokazuje, jak szybko reaguje na kliknięcia i czy nie przeskakuje podczas ładowania. Brzmi technicznie, ale za każdą z nich stoi konkretne doświadczenie klienta Twojego sklepu. Poniżej tłumaczymy je po polsku, pokazujemy, jak czytać raport w Search Console, i mówimy, od czego zacząć naprawę.

W skrócie

LCP poniżej 2,5 s: klient szybko widzi główne zdjęcie produktu. INP poniżej 200 ms: przycisk „do koszyka” reaguje od razu. CLS poniżej 0,1: strona nie skacze.
Raport w Search Console pokazuje dane od prawdziwych użytkowników z ostatnich 28 dni, pogrupowane według podobnych adresów. Jedna poprawka w szablonie naprawia całą grupę.
Kolejność napraw: najpierw LCP (zdjęcia, serwer, cache), potem CLS (wymiary obrazów, banery), na końcu INP (skrypty modułów).
Dane laboratoryjne z PageSpeed to podpowiedź, dane terenowe z Search Console to ocena. Liczy się ta druga.

Trzy wskaźniki po polsku

LCP: kiedy klient widzi to, po co przyszedł

Largest Contentful Paint to czas od wejścia na stronę do momentu, w którym pokaże się największy element widoczny na ekranie. W sklepie to zwykle zdjęcie produktu na karcie, baner na stronie głównej albo pierwsze zdjęcia na liście kategorii. Próg dobry to poniżej 2,5 sekundy. Powyżej 4 sekund Google uznaje wynik za słaby. Dla klienta LCP to moment, w którym przestaje patrzeć na białą stronę i zaczyna oglądać produkt.

INP: jak szybko sklep odpowiada na kliknięcie

Interaction to Next Paint mierzy opóźnienie między kliknięciem, dotknięciem albo wpisaniem znaku a widoczną reakcją strony. Google bierze pod uwagę najgorsze interakcje podczas wizyty. Próg dobry to poniżej 200 milisekund. W sklepie INP dotyczy wyboru wariantu, dodania do koszyka, otwarcia menu, filtrowania kategorii. Wysoki INP to sytuacja, gdy klient klika „do koszyka”, nic się nie dzieje przez sekundę, klika drugi raz i ma w koszyku dwie sztuki.

CLS: czy strona nie ucieka spod palca

Cumulative Layout Shift to miara tego, jak bardzo elementy przesuwają się podczas ładowania. Próg dobry to poniżej 0,1. Typowy obraz w sklepie: klient chce kliknąć produkt na liście, w tym momencie nad listą doładowuje się baner, lista zjeżdża w dół i klient klika inny produkt. Albo pasek z informacją o cookies wpycha się nad treść i wszystko przeskakuje.

Wskaźnik	Dobry	Wymaga poprawy	Słaby	Co czuje klient
LCP	do 2,5 s	2,5 do 4 s	powyżej 4 s	jak długo patrzy na pustą stronę
INP	do 200 ms	200 do 500 ms	powyżej 500 ms	czy przycisk reaguje od razu
CLS	do 0,1	0,1 do 0,25	powyżej 0,25	czy strona przeskakuje podczas ładowania

Skąd Google bierze te dane

Są dwa źródła i warto je rozróżniać. Pierwsze to dane laboratoryjne: PageSpeed Insights albo Lighthouse uruchamia Twoją stronę w symulowanych warunkach i mierzy. To pomiar powtarzalny, dobry do testowania zmian, ale nie mówi, co czują prawdziwi klienci. Drugie to dane terenowe z raportu Chrome User Experience, zbierane od użytkowników Chrome, którzy odwiedzili Twój sklep. To one trafiają do Search Console i to one liczą się dla Google w ocenie strony.

Różnice między oboma bywają duże. Sklep może mieć dobry wynik w PageSpeed, a słabe dane terenowe, bo klienci wchodzą z telefonów na słabym zasięgu. Albo odwrotnie: PageSpeed pokazuje czerwień, a dane terenowe są dobre, bo większość klientów ma już stronę w cache po poprzednich wizytach. Ostatnie słowo mają dane terenowe.

Uwaga

INP nie da się dobrze zmierzyć w laboratorium, bo wymaga prawdziwych kliknięć. PageSpeed pokaże w tym miejscu TBT (Total Blocking Time) jako przybliżenie. Jeśli Search Console pokazuje słaby INP, musisz sam przejść przez sklep na telefonie i wyłapać, które kliknięcia się zacinają.

Jak czytać raport w Search Console

W Search Console wejdź w sekcję Doświadczenie, dalej Podstawowe wskaźniki internetowe. Zobaczysz dwa raporty: na urządzenia mobilne i na komputery. Zajmij się mobilnym, bo tam wyniki są zwykle gorsze, a ruchu więcej.

Krok po kroku

Spójrz na wykres słabych, wymagających poprawy i dobrych adresów. To liczba adresów z Twojego sklepu w każdej grupie na przestrzeni czasu. Spadki i wzrosty wiążą się z wdrożeniami. Jeśli wykres pogorszył się w konkretnym tygodniu, sprawdź, co wtedy zmieniono w sklepie.
Otwórz listę problemów. Każdy wiersz to jeden wskaźnik i jedna grupa adresów, np. „Problem z LCP: dłużej niż 2,5 s (urządzenia mobilne)”. Obok liczba adresów, których dotyczy.
Kliknij problem i zobacz grupy adresów. Search Console grupuje strony, które zachowują się podobnie, i podaje przykładowy adres. Grupa „karty produktów” z 3000 adresów to jeden problem w szablonie, nie 3000 problemów.
Sprawdź przykładowy adres w PageSpeed Insights. Dostaniesz diagnozę: który element to LCP, co blokuje, co przesuwa układ. Napraw w szablonie i sprawdź, czy poprawa dotyczy całej grupy.
Zgłoś weryfikację. Po wdrożeniu kliknij „Rozpocznij weryfikację” przy problemie. Google obserwuje przez 28 dni i oznacza problem jako rozwiązany, jeśli dane terenowe się poprawiły.

Pamiętaj, że dane w Search Console to średnia krocząca z 28 dni. Po wdrożeniu poprawki wykres zacznie się ruszać po kilku dniach, a pełny efekt zobaczysz po około miesiącu. Nie wprowadzaj w tym czasie kolejnych dużych zmian, bo nie będziesz wiedzieć, która zadziałała.

Co naprawiać w pierwszej kolejności

Najpierw LCP, bo tu jest najwięcej do zyskania

W sklepie LCP to zazwyczaj zdjęcie. Trzy najczęstsze przyczyny słabego LCP to zdjęcie za duże dla miejsca, w którym się wyświetla, wolna odpowiedź serwera (bez cache każda karta produktu to dziesiątki zapytań do bazy) oraz skrypty i style ładowane przed zdjęciem, które je blokują. Co pomaga: zdjęcia w WebP lub AVIF w rozmiarze dopasowanym do ekranu, cache po stronie serwera, atrybut priorytetu dla głównego zdjęcia produktu, wyniesienie niekrytycznych skryptów na koniec ładowania. Kolejność działań przy wolnym sklepie opisaliśmy w tekście o tym, dlaczego sklep jest wolny i jak dojść do PageSpeed 90+.

Potem CLS, bo to zwykle szybka naprawa

CLS psują elementy bez zarezerwowanego miejsca. Zdjęcie bez podanych wymiarów najpierw zajmuje zero pikseli, potem wypycha treść. Baner wstawiany skryptem po załadowaniu strony. Czcionka webowa, która po załadowaniu ma inną szerokość niż zastępcza, przez co teksty się przełamują. Pasek cookies wstawiany nad treścią zamiast nakładany na nią. Naprawa to zwykle kilka linii w szablonie: atrybuty width i height przy obrazach, stała wysokość kontenerów na banery, ustawienie zamiany czcionki bez przeskoku, pasek cookies jako warstwa, nie jako element wpychany w układ.

Na końcu INP, bo wymaga najwięcej szukania

Słaby INP to prawie zawsze nadmiar JavaScriptu. Każdy moduł dokłada skrypty, które reagują na kliknięcia, śledzą zachowanie, odpalają animacje. Gdy klient dotknie przycisku, przeglądarka musi najpierw skończyć to, co robi, zanim zareaguje. Diagnoza wymaga nagrania wydajności w narzędziach deweloperskich Chrome na telefonie albo z emulacją. Szukasz długich zadań powyżej 50 ms i sprawdzasz, z którego skryptu pochodzą. Naprawa: wyłączenie nieużywanych modułów, ładowanie skryptów tylko na stronach, gdzie są potrzebne, przesunięcie skryptów analitycznych i marketingowych po pierwszej interakcji.

Z naszej praktyki

Sklep z artykułami dla zwierząt miał w Search Console 2800 adresów z problemem LCP i 2800 z CLS, w obu przypadkach grupa „karty produktów”. Przyczyna LCP: zdjęcie główne wgrywane w 2000 pikselach i wyświetlane w 600, bez cache. Przyczyna CLS: blok z opiniami ładowany po stronie i wypychający przycisk koszyka. Włączyliśmy skalowanie i WebP, cache Smarty i cache po stronie serwera, a blokowi opinii daliśmy stałą wysokość. Po 28 dniach obie grupy przeszły do „dobrych”, a INP, którego nie ruszaliśmy, też się poprawił, bo mniejsza strona szybciej się wykonuje.

Google nie mierzy, jak szybki jest Twój serwer. Mierzy, jak długo Twój klient czeka.

Czego nie robić

Nie optymalizuj pod wynik PageSpeed, ignorując Search Console. Wynik laboratoryjny 95 przy słabych danych terenowych nic Ci nie da.
Nie ukrywaj zdjęć na pierwszym ekranie za leniwym ładowaniem. Leniwe ładowanie jest dla elementów poniżej, główne zdjęcie produktu ma się ładować od razu, z priorytetem.
Nie włączaj wszystkich opcji wydajności w panelu PrestaShop naraz. Część z nich psuje moduły. Włączaj po jednej, sprawdzaj sklep.
Nie dokładaj skryptów „na chwilę”. Każdy piksel reklamowy, czat i widżet to kilkadziesiąt milisekund INP. Po pół roku jest ich dwadzieścia.

Pytania, które słyszymy najczęściej

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

Tak, są jednym z sygnałów rankingowych, choć treść i linki ważą więcej. Przy podobnych stronach konkurentów lepsze wskaźniki mogą przeważyć. Ważniejszy jest jednak wpływ na konwersję: wolny sklep sprzedaje mniej niezależnie od pozycji.

Dlaczego Search Console nie pokazuje danych dla mojego sklepu?

Raport wymaga odpowiedniej liczby wizyt użytkowników Chrome. Przy małym ruchu Google nie ma danych i raport jest pusty. Wtedy kieruj się pomiarami laboratoryjnymi i własnym testem na telefonie.

Co zrobić, gdy po poprawkach wynik znów się pogorszył?

Sprawdź, co zmieniło się w sklepie w ostatnich tygodniach: nowy moduł, baner, skrypt reklamowy, aktualizacja motywu. Wydajność psuje się przez dokładanie, nie sama z siebie. W opiece nad sklepem mierzymy to co tydzień właśnie z tego powodu.

Czy potrzebuję osobnego narzędzia do pomiaru INP?

Na start wystarczą Search Console i narzędzia deweloperskie Chrome. Przy większym sklepie przydaje się skrypt zbierający wskaźniki od prawdziwych użytkowników z podziałem na typ strony i urządzenie, bo Search Console grupuje adresy dość ogólnie.

Chcesz wiedzieć, które z trzech wskaźników ciągną Twój sklep w dół i w jakiej kolejności to naprawić? W audycie wydajności dostajesz listę konkretnych zmian z szacunkiem efektu. Zobacz, co zawiera audyt.

Zamów audyt Core Web Vitals