Core Web Vitals dla sklepu: LCP, INP i CLS bez żargonu

Core Web Vitals to trzy liczby, którymi Google ocenia, jak Twój sklep zachowuje się pod palcem klienta. Mierzą, jak szybko strona się ładuje, jak szybko reaguje na klik i czy układ nie skacze pod kursorem. Brzmi technicznie, a stoi za tym prosta sprawa. Klient, który czeka za długo albo klika w przycisk, który właśnie odjechał w dół, po prostu zamyka kartę. W tym tekście rozbieram każdy z trzech wskaźników na czynniki pierwsze, pokazuję darmowe narzędzia do pomiaru i wymieniam hamulce, które wyłapuję w sklepie za sklepem podczas audytu.

Piszę z perspektywy osoby, która sprawdza te metryki na żywych sklepach, a nie na slajdach. Dlatego mniej tu definicji ze słownika, a więcej tego, co realnie psuje wynik i co da się z tym zrobić.

Czym są Core Web Vitals i dlaczego sklep powinien je znać

Core Web Vitals to zestaw trzech mierzalnych wskaźników jakości doświadczenia użytkownika, które Google traktuje jako jeden z sygnałów oceny strony. Nie zastępują treści ani linków, ale przy zbliżonej jakości dwóch wyników potrafią przeważyć szalę. W sklepie sprawa jest poważniejsza niż na blogu, bo na karcie produktu spotykają się ciężkie zdjęcia, kilka skryptów marketingowych i koszyk, który musi działać od pierwszej sekundy.

Cała trójka mierzy trzy różne rzeczy i nie da się ich zastąpić jedną liczbą:

• LCP odpowiada na pytanie: jak szybko widzę najważniejszą rzecz na ekranie.
• INP odpowiada na pytanie: jak szybko strona reaguje, kiedy w nią klikam.
• CLS odpowiada na pytanie: czy układ stoi spokojnie, czy skacze mi pod ręką.

Google publikuje progi „dobre” dla każdego z nich, więc nie musisz ich zgadywać. W sklepach rzadko jednak widzę zielono na wszystkich trzech naraz. Zwykle jeden wskaźnik ciągnie pozostałe w dół, najczęściej przez nieoptymalizowane zdjęcia albo nadmiar zewnętrznych skryptów. Dlatego zamiast „poprawiać Core Web Vitals” w ogóle, lepiej najpierw ustalić, który z trzech wskaźników masz na czerwono, i ruszyć od niego.

Zaznaczę też od razu, że Core Web Vitals zmieniają się w czasie. Google co jakiś czas wymienia mierzone parametry, więc wiedza sprzed dwóch lat bywa już nieaktualna. Najlepszy przykład znajdziesz niżej, przy INP.

LCP, czyli jak szybko klient widzi to, co najważniejsze

LCP (Largest Contentful Paint) mierzy czas, po którym na ekranie pojawia się największy widoczny element. Na karcie produktu to zwykle główne zdjęcie albo duży nagłówek, na stronie głównej najczęściej baner. Google uznaje wynik za dobry, gdy LCP wypada poniżej 2,5 sekundy. Powyżej tej granicy klient ma już wrażenie, że strona się „myśli”, a część osób w tym czasie wraca do wyników wyszukiwania.

W sklepach LCP psuje się najczęściej z kilku powtarzalnych powodów:

• Ciężkie zdjęcie główne. Plik produktowy w pełnej rozdzielczości, wrzucony prosto z aparatu, potrafi ważyć kilka megabajtów. Przeglądarka musi go pobrać, zanim cokolwiek narysuje.
• Brak nowoczesnych formatów grafiki. Stare formaty są cięższe od formatów takich jak WebP czy AVIF przy tej samej jakości obrazu. To prosta zmiana, a różnicę widać natychmiast.
• Wolny serwer lub przeciążony hosting. Jeśli sama odpowiedź serwera przychodzi z opóźnieniem, żadna optymalizacja grafiki tego nie nadrobi.
• Renderowanie blokowane przez skrypty. Gdy przeglądarka najpierw musi przemielić zewnętrzne skrypty, dopiero potem pokazuje obraz.

Co z tym robić w praktyce. Kompresuj zdjęcia produktowe i podawaj je w rozmiarze, w jakim faktycznie się wyświetlają. Przejdź na nowoczesny format grafiki i ładuj główny obraz priorytetowo, zamiast zostawiać go na końcu kolejki. To zwykle pierwszy ruch, który wykonuję, kiedy widzę LCP na czerwono, bo daje najszybszy efekt przy najmniejszym ryzyku dla sklepu.

Warto sprawdzić jeszcze jedną rzecz, którą łatwo przeoczyć. Czasem największym elementem na karcie produktu wcale nie jest zdjęcie, tylko blok tekstu albo nagłówek doładowywany skryptem. Wtedy przyspieszanie grafiki nic nie da, bo wąskim gardłem jest coś innego. Dlatego najpierw patrzę, który dokładnie element narzędzie wskazuje jako LCP, a dopiero potem dobieram poprawkę. To różnica między celną zmianą a zgadywaniem.

INP, czyli jak szybko strona reaguje na klik (i dlaczego FID już nie istnieje)

INP (Interaction to Next Paint) mierzy, ile czasu mija od działania użytkownika, na przykład kliknięcia w przycisk „Dodaj do koszyka”, do momentu, w którym przeglądarka pokazuje efekt tego działania. Google uznaje wynik za dobry poniżej 200 milisekund. Powyżej tej granicy klient klika, nic się nie dzieje, więc klika jeszcze raz, a potem ma wrażenie, że sklep się zaciął.

Tu pojawia się rzecz, którą trzeba zapamiętać. INP zastąpił wcześniejszy wskaźnik FID (First Input Delay), który Google wycofał w marcu 2024 roku. Jeśli czytasz starszy poradnik albo dostajesz raport, w którym ktoś nadal opisuje FID jako aktualny parametr Core Web Vitals, to znak, że materiał jest przestarzały. Dziś liczy się INP i tylko INP, bo mierzy reakcję na wszystkie interakcje w trakcie wizyty, a nie tylko na pierwszą.

Co najczęściej psuje INP w sklepie:

• Nadmiar zewnętrznych skryptów. Piksele reklamowe, czaty, narzędzia analityczne i widżety opinii rywalizują o ten sam wątek przeglądarki. Im więcej ich naraz, tym dłużej trwa reakcja na klik.
• Ciężkie skrypty motywu i wtyczek. Rozbudowane szablony i nadmiar dodatków potrafią obciążyć przeglądarkę przy każdej interakcji.
• Wszystko ładowane od razu. Gdy strona próbuje uruchomić cały kod na starcie, pierwsze kliknięcia trafiają w zajętą przeglądarkę.

Najwięcej da tu przegląd skryptów zewnętrznych. Sprawdzasz, które naprawdę są potrzebne, które można ładować z opóźnieniem, a które wiszą w kodzie od dawna i nikt już z nich nie korzysta. Ten nadmiar trackerów powtarza się w sklepie za sklepem i prawie zawsze jest co usunąć.

Jest jeszcze jedna pułapka, którą widzę regularnie. INP najmocniej obrywa na telefonie, bo procesor smartfona jest słabszy od komputera, a sklep serwuje obu urządzeniom dokładnie ten sam ciężki kod. Na desktopie wynik bywa zielony, a na mobile ten sam przycisk reaguje z wyraźnym opóźnieniem. Dlatego INP testuj przede wszystkim na wersji mobilnej, bo to ona decyduje o ocenie i to na niej kupuje dziś większość klientów.

CLS, czyli czy układ stoi spokojnie, czy skacze pod ręką

CLS (Cumulative Layout Shift) mierzy stabilność układu, czyli to, jak bardzo elementy strony przesuwają się w trakcie ładowania. Google uznaje wynik za dobry poniżej 0,1. Im wyżej, tym częściej dzieje się klasyczna scenka. Chcesz kliknąć „Kup teraz”, w tej samej chwili doładowuje się baner lub grafika, przycisk odjeżdża w dół, a Ty klikasz w coś zupełnie innego. To nie tylko irytuje, ale w sklepie potrafi przełożyć się na przypadkowe kliknięcia i porzucony zakup.

Skąd bierze się skaczący układ:

• Zdjęcia i ramki reklamowe bez zarezerwowanego miejsca. Gdy przeglądarka nie zna wymiarów obrazu z góry, najpierw rysuje tekst, a po doładowaniu grafiki rozpycha layout.
• Czcionki doładowywane z opóźnieniem. Tekst najpierw renderuje się zapasową czcionką, potem podmienia na docelową, co zmienia wysokość bloków.
• Banery, paski zgód i powiadomienia wskakujące nad treścią. Element, który pojawia się na górze już po starcie, spycha całą resztę w dół.

Receptura jest dość przewidywalna. Rezerwuj miejsce na obrazy i ramki, podając ich wymiary. Dbaj o stabilne ładowanie czcionek i nie pozwalaj, żeby elementy wskakiwały nad treść po tym, jak klient już zaczął czytać. CLS to wskaźnik, który najłatwiej zlekceważyć, bo „przecież działa”, a jednocześnie jeden z najbardziej irytujących dla kupującego z telefonem w ręku.

Zwróć też uwagę na baner zgody na pliki cookie. To częsty winowajca, którego mało kto łączy z CLS. Jeśli baner doładowuje się z opóźnieniem i wpycha się nad treść albo pod nią, przesuwa cały widok dokładnie w momencie, gdy klient sięga po pierwszy klik. Ten sam mechanizm dotyczy pasków z promocją darmowej dostawy i wyskakujących powiadomień o zapisie do newslettera. Każdy element, który pojawia się na stronie po jej starcie, jest podejrzany i warto sprawdzić, czy nie rusza układu.

Jak zmierzyć Core Web Vitals za darmo i nie pomylić się w odczycie

Nie potrzebujesz płatnych narzędzi, żeby poznać swoje wyniki. Google daje komplet za darmo, a poszczególne narzędzia wzajemnie się uzupełniają:

• PageSpeed Insights. Wpisujesz adres podstrony, dostajesz wynik dla wersji mobilnej i komputerowej oraz konkretne wskazówki, co ciągnie metryki w dół. To najszybszy start.
• Raport CrUX (Chrome User Experience Report). Zbiera dane od realnych użytkowników Chrome. To na nim opierają się tak zwane dane terenowe, czyli te, które naprawdę wpływają na ocenę strony.
• Google Search Console. Ma osobny raport „Core Web Vitals”, który grupuje adresy URL według tego, czy mają wynik dobry, wymagający poprawy czy słaby. Sprawdza się w sklepie, bo pokazuje problem na całych typach stron naraz, na przykład na wszystkich kartach produktu.

Najważniejsza rzecz przy odczycie to różnica między dwoma rodzajami danych.

Dane terenowe a dane laboratoryjne

Dane terenowe pochodzą od prawdziwych użytkowników, z ich urządzeń i łączy, zebrane przez pewien okres. To one liczą się przy ocenie strony, bo opisują realne doświadczenie klientów, a nie warunki testowe. Jeśli sprzedajesz w całej Polsce, część osób wchodzi na słabszym telefonie i wolniejszym łączu, a dane terenowe to uwzględniają.

Dane laboratoryjne to pojedynczy pomiar w kontrolowanych warunkach, wykonany tu i teraz przez narzędzie. Sprawdzają się do diagnozy, bo natychmiast pokazują, co poprawić, i pozwalają zobaczyć efekt zmiany od razu po wdrożeniu. Nie czekasz wtedy tygodniami, aż uzbierają się dane od użytkowników.

W praktyce łączę jedno z drugim. Danymi laboratoryjnymi szukam przyczyny i testuję poprawki, a danymi terenowymi z CrUX i Search Console sprawdzam, czy zmiana faktycznie dotarła do realnych klientów. Jeśli sklep jest nowy albo ma mały ruch, danych terenowych może po prostu nie być. Zostają wtedy same dane laboratoryjne. To normalne, trzeba tylko wiedzieć, że na takim wyniku nie postawisz pełnych wniosków o tym, co czują użytkownicy.

Jedna uwaga o metodzie, która oszczędza złudzeń. Mierz zawsze ten sam adres kilka razy, najlepiej o różnych porach. Wynik laboratoryjny potrafi się wahać między pomiarami, bo zależy od chwilowego obciążenia serwera i sieci. Pojedynczy słaby odczyt nie zawsze oznacza realny problem, a pojedynczy dobry nie znaczy, że sklep jest szybki dla wszystkich. Dopiero powtarzalny wzorzec mówi prawdę.

Najczęstsze hamulce wydajności w polskich sklepach

Kiedy zestawię audyty z różnych platform, lista winowajców jest zaskakująco powtarzalna. Te same rzeczy psują wynik w sklepie za sklepem, niezależnie od branży:

• Nieoptymalizowane zdjęcia produktów. Najczęstszy hamulec ze wszystkich. Pliki w pełnej rozdzielczości, kilkukrotnie większe niż miejsce, w którym się wyświetlają. Uderzają głównie w LCP, a przy doładowywaniu bez rezerwacji miejsca także w CLS.
• Brak nowoczesnych formatów grafiki. Sklep dalej serwuje ciężkie pliki w starych formatach, choć WebP czy AVIF dają ten sam obraz przy mniejszej wadze.
• Nadmiar skryptów zewnętrznych. Reklamy, analityka, czaty, widżety opinii, mapy. Każdy dorzucony skrypt to dodatkowa praca dla przeglądarki i ryzyko dla INP.
• Przeskakujący układ. Zdjęcia i ramki bez zarezerwowanego miejsca oraz banery wskakujące nad treść, które rozjeżdżają stronę w trakcie ładowania.
• Ciężki motyw i nadmiar wtyczek. Rozbudowane szablony z mnóstwem funkcji, z których realnie korzysta ułamek, obciążają każdą podstronę.

To są problemy do naprawienia bez przebudowy całego sklepu. Kompresja i konwersja zdjęć, przegląd skryptów zewnętrznych oraz rezerwacja miejsca na elementy to ruchy techniczne, które porządkuję podczas naprawy punktów krytycznych, zwykle bez ruszania szaty graficznej. Pełną listę takich hamulców razem z priorytetami pokazuję w przykładowym raporcie audytu, żeby było widać, jak wygląda konkretna diagnoza, a nie ogólna lista życzeń.

Różne platformy mają tu swoje typowe słabe punkty. Na WooCommerce i PrestaShop, gdzie sklep stoi na własnym hostingu, najczęściej obrywa serwer i nadmiar wtyczek, bo każdy dodatek dokłada swój kod. Na SaaS w rodzaju Shopera, IdoSell czy Shopify nie ruszysz silnika, więc grasz tym, co masz pod ręką: zdjęciami, aplikacjami z marketplace’u i skryptami doklejanymi do szablonu. Mechanizm jest ten sam, zmienia się tylko miejsce, w którym najłatwiej zrobić bałagan.

Co wydajność ma wspólnego z konwersją i pozycją w Google

Core Web Vitals łączą dwie rzeczy, na których zależy każdemu sklepowi: sprzedaż i widoczność. Zacznijmy od sprzedaży, bo tu mechanizm jest najprostszy. Strona, która ładuje się wolno, reaguje z opóźnieniem albo skacze pod ręką, zniechęca klienta, zanim ten dojdzie do kasy. Część osób wychodzi już na karcie produktu, część dopiero w koszyku, ale efekt jest ten sam. Koszyk zostaje porzucony. Przyczyny porzucania koszyka bywają różne, od nieoczekiwanych kosztów na końcu po zbyt długi proces zakupu, ale niestabilny i wolny interfejs dokłada się do tego po cichu, bo frustracja narasta z każdym kliknięciem w martwy przycisk.

Druga strona to widoczność w wyszukiwarce. Google wykorzystuje Core Web Vitals jako jeden z sygnałów oceny strony. To nie jest przełącznik, który sam wywinduje Cię na pierwsze miejsce, bo treść i dopasowanie do zapytania nadal ważą więcej. Ale przy dwóch zbliżonych wynikach lepsze doświadczenie strony potrafi przeważyć. Pamiętaj też, że efekty zmian widać w różnym tempie. Poprawki techniczne, takie jak lżejsze zdjęcia czy uprzątnięte skrypty, dają efekt w wynikach szybciej niż klasyczne działania SEO, gdzie na realne ruchy w rankingu czeka się zwykle kilka miesięcy.

Jest jeszcze jeden powód, dla którego nie warto tego odkładać. Wydajność to nie jest jednorazowa robota. Z każdym nowym banerem, dodaną wtyczką czy kolejnym pikselem marketingowym wynik się pogarsza, więc sklep, który dziś świeci na zielono, za pół roku potrafi zjechać na czerwono. Dlatego traktuj Core Web Vitals jak parametr, który sprawdzasz cyklicznie, a nie jak zadanie do odhaczenia raz na zawsze. Dobry moment na taki przegląd to każda większa zmiana: nowy szablon, nowa kampania z dodatkowymi pikselami albo świeżo zainstalowana wtyczka.

Od czego zacząć

Jeśli masz zapamiętać z tego tekstu jedną rzecz, niech to będzie kolejność działania. Najpierw zmierz sklep w PageSpeed Insights i Search Console. Ustal, który z trzech wskaźników masz na czerwono, i dopiero potem bierz się za przyczyny, zaczynając od zdjęć i skryptów zewnętrznych, bo to one psują wynik najczęściej. Reszta to już porządkowanie po kolei. Jeśli chcesz, żeby ktoś zrobił ten przegląd za Ciebie i wskazał konkretne punkty do poprawy zamiast ogólników, na tym właśnie polega audyt sklepu internetowego, który prowadzę.