Core Web Vitals w sklepie internetowym — progi LCP, INP i CLS oraz różnice między platformami

Core Web Vitals to jeden z wielu sygnałów rankingowych Google, a to, jak wypadnie w nich Twój sklep, w dużej mierze zależy od platformy, na której działa. Właściciele sklepów zwykle zaczynają o nich czytać, gdy zobaczą czerwone liczby w Google Search Console albo usłyszą, że „Google karze za wolną stronę”. Rzeczywistość jest spokojniejsza, ale nie obojętna. Ogólne wprowadzenie do trzech metryk i ich pomiaru znajdziesz w artykule o Core Web Vitals. Tu zajmujemy się tym, co jest specyficzne dla e-commerce: katalogami z tysiącami zdjęć produktów, skryptami płatności i rekomendacji, banerami i popupami, które przesuwają układ strony w najgorszym możliwym momencie.

Trzy metryki i ich progi — mierzone na 75. percentylu

Core Web Vitals to trzy metryki wydajności, każda z dokładnie określonymi progami „dobry”, „wymaga poprawy” i „słaby”:

• LCP (Largest Contentful Paint) — czas wyrenderowania największego widocznego elementu strony. web.dev podaje: „A good LCP value is 2.5 seconds or less” (dobra wartość LCP to 2,5 sekundy lub mniej; tłumaczenie własne). Według tabeli progów wartość powyżej 4 000 ms jest słaba, a wszystko pomiędzy wymaga poprawy. W sklepie LCP wyznacza często główne zdjęcie produktu, slider promocyjny na stronie głównej albo pierwszy rząd siatki kategorii.
• INP (Interaction to Next Paint) — czas od interakcji użytkownika (kliknięcia, dotknięcia, naciśnięcia klawisza) do chwili, gdy przeglądarka faktycznie zaktualizuje ekran. Polska wersja web.dev podaje: „Wartość INP poniżej lub równa 200 milisekund oznacza, że strona dobrze reaguje. Wartość INP powyżej 200 milisekund i poniżej lub równa 500 milisekund oznacza, że responsywność strony wymaga poprawy”. Powyżej 500 ms strona „słabo reaguje”. To metryka wprost związana z przyciskiem „Dodaj do koszyka”, filtrami kategorii i wyborem wariantów.
• CLS (Cumulative Layout Shift) — miara nieoczekiwanych przesunięć układu strony. web.dev podaje: „Good CLS values are 0.1 or less. Poor values are greater than 0.25” (dobre wartości CLS to 0,1 lub mniej, słabe są większe niż 0,25; tłumaczenie własne). Wszystko pomiędzy wymaga poprawy. W sklepie winowajcą bywa zwykle baner zgody na cookies, popup z rabatem albo późno ładowana reklama, która wskakuje nad treść, gdy klient już zaczął przewijać.

Wszystkie trzy progi mierzy się na 75. percentylu odsłon, osobno dla urządzeń mobilnych i komputerów. web.dev pisze: „a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices”. Dla pojedynczej metryki web.dev wyjaśnia, że jeśli co najmniej 75% odsłon spełnia próg „dobry”, witryna ma dobry wynik w tej metryce. Żeby zaliczyć Core Web Vitals jako całość, strona musi spełnić próg we wszystkich trzech metrykach naraz: narzędzia powinny uznać stronę za zaliczoną, jeśli „it meets the recommended targets at the 75th percentile for all three of the Core Web Vitals metrics” (web.dev, Web Vitals, tłumaczenia własne, odczyt 2026-10-05).

Uwaga na polskie wersje web.dev. Polskie (?hl=pl) strony web.dev o LCP i CLS podają, że mierzy się „50. percentyl” (sprawdziliśmy 05.10.2026). To błąd tłumaczenia: angielskie oryginały tych stron i polska strona o INP mówią o 75. percentylu. Przy ustalaniu własnych celów kieruj się 75. percentylem.

INP zamiast FID — zmiana z 12 marca 2024

Jeśli artykuł albo szkolenie wymienia FID (First Input Delay) jako jedną z trzech metryk Core Web Vitals, korzystasz z nieaktualnej wiedzy. Google ogłosił na blogu web.dev: „Today's the day! After years of work, we're finally ready to make Interaction to Next Paint (INP) a stable Core Web Vital metric” (nadszedł ten dzień: po latach pracy INP staje się stabilną metryką Core Web Vitals; tłumaczenie własne), a zmiana ma rozwiązać „many of the shortcomings of First Input Delay (FID)”, czyli wiele słabości FID (web.dev, ogłoszenie INP, odczyt 2026-10-05). Wpis nosi datę 12 marca 2024 roku. W tym samym wpisie Chrome ogłosił wycofanie FID: jego narzędzia przestały gwarantować dostępność tej metryki, a aplikacje korzystające z API CrUX i PageSpeed Insights miały czas na przejście na INP do 9 września 2024 roku. Polska strona web.dev o INP określa go wprost: „INP to następca wskaźnika opóźnienie przy pierwszym działaniu (FID)”.

Różnica nie jest kosmetyczna. FID mierzył tylko opóźnienie przed rozpoczęciem obsługi pierwszej interakcji, i tylko pierwszej. INP obserwuje wszystkie interakcje przez cały czas wizyty i podaje najdłuższą z nich, pomijając wartości odstające. Sklep, w którym dodanie pierwszego produktu do koszyka działa płynnie, ale filtrowanie kategorii po przewinięciu strony zaczyna się ślimaczyć, mógł dobrze wypadać w FID i źle w INP. Jeśli Twój dostawca raportów albo wtyczka SEO wciąż pokazuje FID jako główną metrykę responsywności, narzędzie nie zostało zaktualizowane od marca 2024 roku.

Ile to naprawdę waży w rankingu Google

Core Web Vitals wpływają na ranking, ale nie przebiją trafniejszej treści. Należą do page experience, czyli grupy sygnałów, którymi Google opisuje jakość korzystania ze strony. Polska dokumentacja Search Central stawia sprawę jasno: „Wyszukiwarka Google zawsze stara się wyświetlić najtrafniejszą treść, nawet jeśli jakość strony jest poniżej normy. Jednak w przypadku wielu zapytań dostępnych jest wiele przydatnych treści. W takich przypadkach dobra jakość stron może przyczynić się do sukcesu w wyszukiwarce”. I dalej: „Nie ma jednego sygnału. Nasze podstawowe systemy rankingowe analizują różne sygnały wpływające na ogólną jakość strony”.

Ta sama strona precyzuje rolę samych Core Web Vitals: „Nasze systemy rankingowe używają Core Web Vitals”, ale „Poza Core Web Vitals inne aspekty związane z jakością stron nie wpływają bezpośrednio na podwyższenie pozycji witryny w wynikach wyszukiwania”. Najważniejsze zdanie dla właściciela sklepu, który patrzy na raport w Search Console: „uzyskanie dobrych wyników w raportach takich jak Raport dotyczący Core Web Vitals w Search Console lub w zewnętrznych narzędziach nie gwarantuje, że Twoje strony znajdą się na wysokich pozycjach wyników wyszukiwania Google” (odczyt 2026-10-05).

Wniosek praktyczny: CWV to realny, ale ograniczony sygnał. Działa głównie jako języczek u wagi, gdy konkurujesz z witrynami o podobnej jakości treści. Zielony wynik w Search Console nie zrekompensuje słabej treści produktowej ani braku indeksacji, a dobra treść przy słabym CWV wciąż może wygrywać ze słabszą treścią przy dobrym CWV. To nie powód, żeby ignorować wydajność, tylko żeby nie traktować jej jako jedynej dźwigni SEO.

Dane polowe i dane z testu — skąd biorą się liczby

Dane od realnych użytkowników i wynik testu mówią o wydajności co innego, i potrzebujesz obu:

• Dane polowe (field data) pochodzą od realnych użytkowników. web.dev opisuje je jako dane z monitorowania wszystkich użytkowników, którzy odwiedzają stronę, i pomiaru wybranych metryk dla doświadczenia każdego z nich. Źródłem jest CrUX (Chrome User Experience Report), który developer.chrome.com nazywa zbiorem danych pokazującym, jak realni użytkownicy Chrome doświadczają popularnych miejsc w sieci (tłumaczenia własne, odczyt 2026-10-05). To dane CrUX, a nie pomiar robota indeksującego, zasilają raport Core Web Vitals w Search Console.
• Dane z testu (lab data) powstają, według tego samego źródła, przez wczytanie strony w kontrolowanym środowisku, przy z góry ustalonych warunkach sieci i urządzenia. To wynik testu w PageSpeed Insights albo lokalnego uruchomienia Lighthouse: powtarzalny, ale oderwany od łączy i telefonów Twoich klientów.

Który wynik jest ważniejszy? Jeśli masz oba dla danej strony, web.dev odpowiada wprost: „field data is what you should use to prioritize your efforts” (to dane polowe powinny wyznaczać priorytety; tłumaczenie własne), bo pokazują, z czym naprawdę zmagają się użytkownicy. Dane z testu przydają się do znalezienia konkretnej przyczyny, np. skryptu blokującego renderowanie albo zbyt dużego zdjęcia, ale nie do oceny, czy sklep jako całość mieści się w progach CWV.

PageSpeed Insights (PSI) łączy obie perspektywy w jednym raporcie. Według dokumentacji Google „PSI provides both lab and field data about a page”, a dane realnych użytkowników „is powered by the Chrome User Experience Report (CrUX) dataset” i obejmują „previous 28-day collection period”, czyli kroczące okno ostatnich 28 dni. Wynik Lighthouse w PSI ma pasma: „A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor” (odczyt 2026-10-05). Dlaczego wynik 0–100 skacze między uruchomieniami i nie przesądza o zaliczeniu Core Web Vitals, opisujemy w artykule o PageSpeed Insights.

Raport Core Web Vitals w Google Search Console korzysta z tych samych danych polowych. Według pomocy Google grupuje adresy URL według stanu („Słabej jakości”, „Wymagana poprawa”, „Dobrej jakości”), według wskaźnika i według grup podobnych stron. Stan jest ustawiany na „najwolniejszy stan przypisany do niego dla danego typu urządzenia”, czyli wyznacza go najgorszy z trzech wskaźników, a nie najgorsza pojedyncza strona. Źródłem danych jest „raport na temat użytkowania Chrome”, więc to wciąż CrUX, a nie wynik testu (odczyt 2026-10-05).

Core Web Vitals według platformy — ponad dwukrotna różnica

Próg jest jeden dla wszystkich, ale szansa na jego osiągnięcie mocno zależy od platformy sklepu. HTTP Archive Web Almanac 2025 (rozdział 13 „Ecommerce”, dane z lipca 2025 roku, publikacja w styczniu 2026) policzył udział witryn z dobrym wynikiem CWV, czyli spełniających wszystkie trzy progi na 75. percentylu, w podziale na platformy e-commerce:

Rozdział zaznacza: „A site is considered 'good' on CWV when it passes all three thresholds”, a różnice między platformami tłumaczy jedną metryką: „LCP is the biggest differentiator” (LCP najbardziej różnicuje platformy; tłumaczenie własne). Dobrze to widać na WooCommerce. Jego słabym punktem jest właśnie LCP (45% dobrych wyników na desktopie, 39% na mobile w danych źródłowych), INP wypada dobrze (99% na desktopie, 88% na mobile), a CLS osiąga 68% na desktopie i 85% na mobile. Główny problem leży więc w czasie wyrenderowania najważniejszego elementu strony. Słabsze wyniki WooCommerce rozdział wiąże z jego „infinite customization nature” (nieograniczoną możliwością dostosowania), a lepsze wyniki innych platform z szybkimi motywami i ściśle kontrolowanymi ekosystemami aplikacji. Dla porównania Shopify ma w tych samych tabelach 86% dobrych wyników LCP na mobile i 92% na desktopie, INP 90% i 99%, a CLS 92% i 82% (Web Almanac 2025, rys. 13.10 i 13.11, odczyt 2026-10-05). Przy INP obie platformy wypadają podobnie, a przepaść otwiera się na LCP.

Dwa zastrzeżenia do tej tabeli. Po pierwsze, dane są globalne: Web Almanac rozpoznaje platformy narzędziem Wappalyzer na dużej próbie witryn z całego świata i nie ma osobnego zestawienia dla Polski. Po drugie, żadna edycja Web Almanac (ani 2024, ani 2025) nie podaje jednej liczby „odsetek sklepów internetowych z dobrym CWV”, tylko rozbicie na platformy. Traktuj tabelę jako wskazówkę, gdzie leży typowy problem danej technologii, a nie wyrok na Twój sklep: na tej samej platformie da się mieć wynik wyraźnie lepszy albo gorszy od średniej.

Co w sklepie najczęściej psuje LCP, INP i CLS

Każda z trzech metryk ma w e-commerce swój typowy mechanizm problemu. Rozdział Web Almanac 2025 wskazuje jako typowe źródła: dla LCP obrazy hero, siatki produktów oraz CSS i JavaScript blokujące renderowanie; dla INP ciężki JavaScript, tagi zewnętrzne i rywalizację o główny wątek przeglądarki; dla CLS późno ładowane zdjęcia produktów, widgety personalizacji i banery promocyjne. Procentowego rozbicia przyczyn dla polskich sklepów żadne ze sprawdzonych źródeł nie publikuje. W praktyce wygląda to tak:

• LCP psuje zwykle to, co ta metryka mierzy: czas dostarczenia największego widocznego elementu. W sklepie to najczęściej główne zdjęcie produktu albo hero banner na stronie głównej, a przyczyną bywa za duży plik, zły format, brak priorytetu ładowania (preload) albo serwer, który wolno odpowiada, zanim przeglądarka zacznie cokolwiek renderować.
• INP psuje nagromadzenie JavaScriptu uruchamianego w odpowiedzi na działania klienta: skrypty płatności, kalkulatory kosztu dostawy, czaty, rekomendacje „podobne produkty”. Wszystkie nasłuchują tych samych kliknięć i konkurują o główny wątek przeglądarki. Klient klika „Dodaj do koszyka”, a strona jest akurat zajęta czymś innym.
• CLS psuje treść wstawiana bez zarezerwowanego miejsca, gdy strona już się wyrenderowała: banery zgody na cookies, popupy z rabatem, późno ładowane reklamy albo obrazy bez określonych wymiarów, które „doskakują” i przesuwają wszystko poniżej.

Mechanizm jest za każdym razem ten sam: coś ładuje się później, niż powinno, albo zajmuje wątek przeglądarki dłużej, niż powinno. Naprawa zaczyna się od wskazania konkretnego elementu, a do tego służą dane z testu, nie dane polowe.

Plan na 30 dni — jak podejść do poprawy

1. Tydzień 1 — zmierz, zanim zaczniesz poprawiać. Uruchom test szybkości strony Digital Vantage dla strony głównej, listy kategorii i karty produktu. To trzy różne szablony z różnymi problemami. Równolegle sprawdź raport Core Web Vitals w Search Console, żeby widzieć dane polowe, a nie tylko wynik jednorazowego testu.
2. Tydzień 2 — LCP. Ustal, który element jest „największym widocznym elementem” na każdym z trzech szablonów. Sprawdź jego format, rozmiar pliku i to, czy ma priorytet ładowania. Sprawdź też czas odpowiedzi serwera: zoptymalizowane zdjęcie nie pomoże, jeśli backend odpowiada wolno.
3. Tydzień 3 — INP. Przejrzyj, które skrypty ładują się i wykonują na stronach produktów i w koszyku. Te, które nie są potrzebne od razu (czaty, piksele marketingowe, widgety opinii), mogą ładować się z opóźnieniem, po pierwszej interakcji użytkownika.
4. Tydzień 4 — CLS. Przejdź przez strony z włączonym spowolnieniem sieci (throttlingiem) i sprawdź, co przesuwa układ: banery cookies, popupy, obrazy bez wymiarów. Zarezerwuj dla nich miejsce z góry, zamiast wstawiać je po fakcie.
5. Po 30 dniach — zmierz jeszcze raz. Porównaj wynik testu i dane w Search Console z punktem wyjścia. Dane polowe obejmują kroczące okno ostatnich 28 dni, więc pełny obraz zmiany zobaczysz dopiero po około czterech tygodniach od wdrożenia, a nie następnego dnia.

Część tych działań zrobisz samodzielnie, jeśli masz dostęp do kodu szablonu i kogoś, kto umie go edytować. Inne, zwłaszcza zmiany po stronie serwera, CDN dla obrazów czy przebudowa ładowania skryptów, zwykle wymagają programisty. Rzetelnej, publicznie dostępnej średniej ceny takiej optymalizacji w Polsce nie ma, dlatego nie podajemy kwoty. Koszt zależy od liczby szablonów w sklepie, liczby wpiętych zewnętrznych skryptów i od tego, czy problem leży w kodzie, czy w hostingu. Jeśli wolisz zlecić to komuś, kto najpierw zmierzy, a potem wyceni konkretny zakres, napisz do nas.