Core Web Vitals sklepów WooCommerce 2026 — przewodnik i metodologia raportu

Damian Zięba · 2 czerwca 2026 · 7 min czytania

Raport Core Web Vitals sklepów WooCommerce to systematyczny pomiar realnej szybkości sklepów oparty na danych terenowych (CrUX) i laboratoryjnych (Lighthouse/PageSpeed), prowadzony według stałej, powtarzalnej metodologii. Sens takiego raportu jest jeden: zamienić ogólne „sklep jest wolny" na liczby, które da się porównać między sklepami, między miesiącami i z konkurencją — a potem na ich podstawie podejmować decyzje techniczne, nie zgadywać.

Ten tekst nie jest definicją Core Web Vitals — jeśli dopiero zaczynasz, zacznij od wpisu Core Web Vitals w sklepie WooCommerce — co to i dlaczego wpływa na sprzedaż. Tutaj pokazuję jak zbudować rzetelny pomiar i raport: co mierzyć, czym, na jakiej próbie i jak zrobić to powtarzalnie.

Dlaczego Core Web Vitals w e-commerce to pieniądze, nie kosmetyka

W sklepie szybkość nie jest „miłym dodatkiem" — jest częścią lejka sprzedażowego. Każda sekunda opóźnienia w ładowaniu listingu, karty produktu czy koszyka to realna grupa użytkowników, która rezygnuje przed konwersją. Działają tu dwa mechanizmy naraz:

Ranking — Core Web Vitals to potwierdzony sygnał Page Experience. Przy zbliżonej trafności treści szybszy sklep ma przewagę w wynikach.
Konwersja — wolne ładowanie i „skaczący" układ (CLS) podnoszą współczynnik odrzuceń i porzuceń koszyka. To dotyczy ruchu z każdego źródła, także płatnego: za wolny landing płacisz w Google Ads podwójnie.

Dlatego pomiar CWV warto traktować jak pomiar przychodu. Jeśli chcesz oszacować, ile realnie tracisz na wolnym sklepie, policz to na kalkulatorze utraty sprzedaży — to dobry punkt wyjścia do uzasadnienia budżetu na optymalizację.

Co dokładnie mierzymy: LCP, INP, CLS + TTFB

Rdzeń to trzy oficjalne metryki Core Web Vitals plus jedna metryka diagnostyczna, która tłumaczy „dlaczego":

Metryka	Co opisuje	Próg „dobry"	Typowy winowajca w WooCommerce
LCP (Largest Contentful Paint)	Jak szybko pojawia się największy element (zwykle baner lub zdjęcie produktu)	≤ 2,5 s	Wolny serwer/TTFB, nieoptymalne zdjęcia, brak cache
INP (Interaction to Next Paint)	Jak szybko sklep reaguje na kliknięcia (filtry, „dodaj do koszyka")	≤ 200 ms	Ciężki JavaScript wtyczek, AJAX koszyka, buildery
CLS (Cumulative Layout Shift)	Stabilność układu — czy treść „skacze" podczas ładowania	≤ 0,1	Zdjęcia bez wymiarów, bannery cookie, late-loaded fonty
TTFB (Time to First Byte)	Czas reakcji serwera do pierwszego bajtu odpowiedzi	≤ 0,8 s	Hosting współdzielony, brak cache obiektowego, ciężkie zapytania

TTFB nie jest formalnie Core Web Vital, ale w raporcie sklepów jest kluczowy: w WooCommerce strony koszyka, konta i checkoutu są dynamiczne (nie dają się w pełni zcache'ować), więc to serwer i baza decydują o ich szybkości. Bez TTFB raport pokazuje objaw, ale nie przyczynę.

Skąd brać dane: pole (CrUX) vs laboratorium (Lighthouse)

Najczęstszy błąd amatorskich „raportów szybkości" to mieszanie dwóch niekompatybilnych źródeł danych. Rozróżnienie jest fundamentem rzetelnej metodologii:

Dane terenowe (field / CrUX) — pochodzą od realnych użytkowników Chrome (Chrome User Experience Report). To one decydują o ocenie Page Experience w Google. Pokazują 75. percentyl, czyli doświadczenie typowego, a nie idealnego użytkownika. Wada: dostępne tylko dla witryn z odpowiednim ruchem.
Dane laboratoryjne (lab / Lighthouse) — symulacja jednego wczytania w kontrolowanych warunkach (PageSpeed Insights, Lighthouse, narzędzia deweloperskie). Powtarzalne i dostępne dla każdego URL, ale to nie jest to, co widzą Twoi klienci — to scenariusz testowy.

W rzetelnym raporcie field jest źródłem prawdy o ocenie, a lab służy do diagnostyki i porównań tam, gdzie danych terenowych brakuje. Mieszanie ich w jednej tabeli bez oznaczenia to najczęstsza manipulacja.

Jak zmierzyć: narzędzia i dostęp do danych

Do powtarzalnego pomiaru wystarczy stały zestaw narzędzi:

PageSpeed Insights — łączy field (CrUX) i lab (Lighthouse) dla pojedynczego URL; ma publiczne API, więc da się go zautomatyzować dla całej listy sklepów.
CrUX (BigQuery / CrUX API) — dane terenowe na poziomie origin; pozwalają liczyć rozkłady i percentyle na większej próbie domen.
Google Search Console → raport Core Web Vitals — pokazuje, ile adresów Twojego sklepu jest „dobrych", „wymaga poprawy" lub „słabych" w polu.
WebPageTest / Lighthouse CI — kontrolowane, powtarzalne testy lab z pełnym waterfallem (przydatne do diagnozy LCP i TTFB).

Ważne: jeśli mierzysz swój sklep i chcesz wiedzieć, co dokładnie naprawić, sam wynik liczbowy nie wystarczy — potrzebujesz waterfallu i analizy przyczyn. To już zakres pełnego audytu SEO, który łączy wydajność z indeksacją i widocznością.

Metodologia rzetelnego raportu branżowego

Raport ma wartość tylko wtedy, gdy ktoś może go powtórzyć i dostać zbliżony wynik. Oto zasady, na których opieram metodologię pomiaru sklepów WooCommerce:

1. Próba i dobór sklepów

Określ jasno, co badasz: liczbę sklepów, kryterium kwalifikacji (np. wykrywalny WooCommerce, język polski, aktywny ruch), oraz to, czy próba jest losowa, czy celowa. Bez opisanej próby liczby są bez kontekstu — „średnie LCP" z 8 znajomych sklepów to anegdota, nie raport.

2. Co dokładnie testujemy (typy stron)

Sklep to nie jedna strona. Mierz reprezentatywne szablony osobno, bo zachowują się inaczej:

strona główna,
listing kategorii (z filtrami),
karta produktu,
koszyk / checkout (strony dynamiczne — tu liczy się TTFB).

Uśrednianie wszystkiego do jednej liczby na sklep ukrywa to, co najważniejsze: zwykle to listing i karta produktu generują przychód, a checkout jest najwolniejszy.

3. Anonimizacja i etyka

Jeśli raport jest publiczny, agreguj wyniki i nie wskazuj konkretnych sklepów „z palca" w negatywnym kontekście bez ich zgody. Publikuj rozkłady (ile procent sklepów jest w strefie „dobrej"), a nie listę wstydu. To kwestia zarówno etyki, jak i wiarygodności.

4. Powtarzalność i transparentność

Zapisz i opublikuj parametry pomiaru: datę, narzędzie i jego wersję, typ danych (field/lab), urządzenie (mobile vs desktop — domyślnie mobile, bo tam jest większość ruchu e-commerce), throttling sieci oraz liczbę przebiegów. Pomiar lab rób w kilku przebiegach i bierz medianę, bo pojedynczy run potrafi „dać czkawkę".

5. Stała kadencja

Jednorazowy snapshot mówi mało. Wartość rośnie, gdy raport powtarzasz w stałych odstępach (np. kwartalnie) tą samą metodą — wtedy widać trend, a nie szum.

Uwaga: ten przewodnik opisuje metodologię. Zagregowane wyniki dla rynku publikujemy osobno, gdy pomiar na opisanej tu próbie zostanie domknięty — celowo nie podaję tu liczb, których nie zmierzyliśmy.

Typowe wąskie gardła sklepów WooCommerce (i jak je naprawić)

Z perspektywy pomiaru większość słabych wyników sprowadza się do kilku powtarzalnych przyczyn:

Wolny serwer / wysoki TTFB → cache obiektowy (Redis), dobry hosting pod WooCommerce, optymalizacja zapytań. Jak wybrać środowisko, opisuję we wpisie hosting pod WooCommerce — jak wybrać.
Ciężkie zdjęcia produktów → format WebP/AVIF, poprawne wymiary, lazy-loading poniżej ekranu, preload obrazu LCP.
Nadmiar wtyczek i ciężki JavaScript → audyt wtyczek, ograniczenie buildera, defer/async skryptów (główna przyczyna słabego INP).
Brak rezerwacji miejsca na elementy → wymiary obrazów, stałe miejsce na bannery i cookie (poprawia CLS).
Dynamiczne strony bez optymalizacji → koszyk/checkout nie cache'ują się jak listing; tu pomaga szybki backend i odchudzenie fragmentów AJAX.

Konkretny plan działań krok po kroku znajdziesz w przewodniku jak przyspieszyć sklep WooCommerce.

Checklista: zanim opublikujesz raport (lub zmierzysz swój sklep)

Czy rozdzieliłeś dane field (CrUX) od lab (Lighthouse) i je oznaczyłeś?
Czy raportujesz 75. percentyl dla danych terenowych?
Czy testujesz osobno: stronę główną, listing, kartę produktu, checkout?
Czy mierzysz na urządzeniu mobilnym jako domyślnym?
Czy uwzględniasz TTFB obok LCP/INP/CLS?
Czy pomiar lab to mediana z kilku przebiegów, nie pojedynczy run?
Czy opisałeś próbę, datę, narzędzia i wersje (powtarzalność)?
Czy wyniki są zagregowane i anonimowe, jeśli raport jest publiczny?

FAQ — Core Web Vitals sklepów WooCommerce i metodologia pomiaru

Czym różni się ten raport od zwykłego testu PageSpeed?

Pojedynczy test PageSpeed to jeden URL, jedno wczytanie i głównie dane laboratoryjne. Raport to systematyczny pomiar wielu sklepów i typów stron, oparty przede wszystkim na danych terenowych (CrUX), z opisaną próbą i powtarzalną metodą — dzięki temu wyniki można porównywać i śledzić w czasie.

Dane terenowe (field) czy laboratoryjne (lab) — które są ważniejsze?

Do oceny — terenowe (CrUX), bo to one odzwierciedlają realnych użytkowników i wpływają na Page Experience w Google. Laboratoryjne służą do diagnostyki i porównań tam, gdzie danych terenowych brakuje. Rzetelny raport używa obu, ale ich nie miesza.

Dlaczego TTFB jest w raporcie, skoro to nie Core Web Vital?

Bo w WooCommerce strony dynamiczne (koszyk, konto, checkout) zależą głównie od serwera i bazy. TTFB tłumaczy, dlaczego LCP jest wysokie, i wskazuje, czy problem jest po stronie hostingu, czy frontendu. Bez niego raport pokazuje objaw bez przyczyny.

Czy mierzyć na mobile czy desktop?

Domyślnie mobile. Większość ruchu w e-commerce to urządzenia mobilne i to tam warunki (słabszy procesor, wolniejsza sieć) są trudniejsze. Desktop warto raportować pomocniczo, ale ocenę opieraj na mobile.

Jak często powtarzać pomiar?

Dla obserwacji trendu rynkowego sprawdza się kadencja kwartalna tą samą metodą. Dla własnego sklepu w trakcie optymalizacji — częściej, np. po każdej istotnej zmianie technicznej, żeby zweryfikować, czy realnie pomogła.

Chcesz wiedzieć, gdzie naprawdę traci Twój sklep?

Pomiar to początek — wartość jest w decyzjach, które z niego wynikają. W Agencji Marketingowej SEMTAK mierzymy Core Web Vitals technicznie i przekładamy liczby na konkretne naprawy i wzrost sprzedaży:

Audyt SEO — pełna diagnoza wydajności, indeksacji i tego, co blokuje sprzedaż Twojego sklepu.
Pozycjonowanie sklepów internetowych — szybkość jako część strategii widoczności w Google.
Tworzenie sklepów WooCommerce — szybki, techniczny sklep zbudowany pod CWV od pierwszego dnia.

Najpierw policz, ile kosztuje Cię wolny sklep: kalkulator utraty sprzedaży. A jeśli dopiero wchodzisz w temat, zacznij od wpisu Core Web Vitals w sklepie WooCommerce.