Core Web Vitals sklepów WooCommerce 2026 — przewodnik i metodologia raportu
Sklep może otrzymać 90 punktów w PageSpeed Insights, a mimo to nie przechodzić oceny Core Web Vitals w Google Search Console. Może też działać szybko na komputerze właściciela, ale wolno reagować na telefonach klientów.
Problem zwykle nie leży w samym narzędziu. Wynika z pomieszania dwóch rodzajów danych: wyników prawdziwych użytkowników oraz testów wykonywanych w kontrolowanych warunkach.
Rzetelny raport Core Web Vitals nie powinien kończyć się jednym wynikiem „72/100". Musi pokazać, które typy stron są wolne, na jakich urządzeniach występuje problem, co go powoduje i które poprawki mają największe znaczenie dla sklepu.
W tym przewodniku pokazujemy, jak przygotować taki raport dla WooCommerce: jakie adresy badać, z jakich źródeł korzystać, jak interpretować LCP, INP i CLS oraz jak oddzielić realne problemy od przypadkowych wahań testu.
Odpowiedź wprost
Ten raport pokazuje, jak naprawdę wypadają sklepy WooCommerce w Core Web Vitals na danych terenowych (CrUX), i wyjaśnia metodologię pomiaru. Kluczowy wniosek: wynik 90+ w PageSpeed Insights (test laboratoryjny) nie oznacza zaliczenia Core Web Vitals w Search Console (dane prawdziwych użytkowników, głównie z telefonów). Liczy się to, co widzi klient na swoim urządzeniu, nie wynik na komputerze właściciela. Jak krok po kroku poprawić te metryki, tłumaczymy w poradniku Core Web Vitals w sklepie WooCommerce.
W skrócie (TL;DR)
- Core Web Vitals w 2026 roku obejmują LCP, INP i CLS. Wszystkie trzy muszą osiągać dobry wynik na 75. percentylu, aby strona lub grupa adresów przeszła ocenę.
- Dane terenowe pochodzą od rzeczywistych użytkowników, a laboratoryjne są symulacją. Nie należy ich uśredniać.
- WooCommerce trzeba badać według typów stron. Strona główna, kategoria, produkt i checkout mogą mieć zupełnie inne problemy.
- Wynik Lighthouse 90/100 nie oznacza automatycznie, że sklep przechodzi Core Web Vitals.
- Dobry raport pokazuje wynik, przyczynę, priorytet, odpowiedzialną osobę i sposób sprawdzenia poprawki.
- Dane terenowe obejmują kroczące okno ostatnich 28 dni, dlatego ich zmiana nie jest widoczna natychmiast po wdrożeniu.
Czym jest raport Core Web Vitals dla WooCommerce?
Raport Core Web Vitals to uporządkowany pomiar szybkości, responsywności i stabilności sklepu, oparty na danych rzeczywistych użytkowników oraz testach diagnostycznych.
Nie jest nim pojedynczy zrzut ekranu z PageSpeed Insights. Raport powinien odpowiedzieć na pytania: czy sklep przechodzi Core Web Vitals; która metryka powoduje problem; czy dotyczy telefonów, komputerów czy obu grup; które typy podstron wypadają najsłabiej; czy źródłem jest serwer, zdjęcie, JavaScript, motyw czy zewnętrzna usługa; czy problem występuje u prawdziwych użytkowników; co naprawić jako pierwsze; i jak sprawdzimy, czy poprawka zadziałała. Jeżeli raport pokazuje jedynie wynik wydajności i listę automatycznych zaleceń, właściciel sklepu nadal nie wie, od czego zacząć.
Raport to NIE test jednego adresu w PageSpeed
Test jednego URL pokazuje jeden adres, jeden moment, analizę Lighthouse i automatyczne zalecenia — nie zna procesu zakupowego ani priorytetów biznesowych. Pełny raport WooCommerce obejmuje różne typy podstron, uwzględnia dane terenowe i trend, łączy field + lab (opcjonalnie własny RUM), weryfikuje rzeczywistą przyczynę, testuje filtry, warianty, koszyk i checkout oraz rozdziela problemy krytyczne od porządkowych. Jeśli dopiero poznajesz temat, zacznij od poradnika Core Web Vitals w sklepie WooCommerce — co to jest i dlaczego wpływa na sprzedaż. Ten artykuł koncentruje się na metodologii pomiaru i raportowania.
Jakie metryki Core Web Vitals obowiązują w 2026 roku?
Aktualne Core Web Vitals to LCP, INP i CLS. Ocenę przechodzi strona, która osiąga dobry wynik dla wszystkich trzech metryk na 75. percentylu wizyt.
Progi (stan na 5 czerwca 2026) i 75. percentyl
LCP: dobry do 2,5 s, wymaga poprawy 2,5–4 s, słaby powyżej 4 s. INP: dobry do 200 ms, wymaga poprawy 200–500 ms, słaby powyżej 500 ms. CLS: dobry do 0,1, wymaga poprawy 0,1–0,25, słaby powyżej 0,25. To nie jest średnia: 75. percentyl oznacza, że 75% wizyt osiągnęło wynik nie gorszy niż dana wartość. Google ocenia tak, by strona działała dobrze dla większości użytkowników, nie tylko dla osób z szybkim telefonem i łączem.
| Metryka | Dobry wynik | Wymaga poprawy | Słaby wynik |
|---|---|---|---|
| LCP | do 2,5 s | powyżej 2,5 do 4 s | powyżej 4 s |
| INP | do 200 ms | powyżej 200 do 500 ms | powyżej 500 ms |
| CLS | do 0,1 | powyżej 0,1 do 0,25 | powyżej 0,25 |
Dlaczego średnia nie wystarcza. Średnia może ukryć problem: jeśli połowa klientów widzi produkt po 1,5 s, a druga połowa czeka 5 s, średnia wynosi 3,25 s — ale nie pokazuje, że bardzo duża grupa użytkowników ma wyraźnie gorsze doświadczenie. W raporcie prezentuj 75. percentyl, udział wyników dobrych, wymagających poprawy i słabych oraz zmianę względem poprzedniego okresu.
Co mierzą LCP, INP i CLS w sklepie WooCommerce?
LCP mierzy czas wyświetlenia największego elementu w początkowym obszarze strony. W WooCommerce może to być baner na stronie głównej, zdjęcie kategorii, główne zdjęcie produktu, duży nagłówek albo grafika kampanii. Słaby wynik może wynikać z wolnego serwera, ciężkiego obrazu, zbyt późnego pobierania zasobu albo blokującego kodu. Lazy-loading (odroczenie pobierania zdjęcia do czasu, gdy jest potrzebne) jest przydatny dla obrazów niżej na stronie, ale nie powinien bez kontroli obejmować głównego zdjęcia będącego elementem LCP. Samo zmniejszenie obrazu nie zawsze naprawia wynik — jeśli zdjęcie zostaje wykryte dopiero po wykonaniu JavaScriptu, jego pobieranie nadal zacznie się za późno.
INP mierzy opóźnienie między działaniem użytkownika a pokazaniem kolejnej zmiany na ekranie. W sklepie istotne są: otwieranie menu, filtry, wybór wariantu, dodanie do koszyka, otwarcie mini-koszyka, wybór dostawy, zmiana płatności i walidacja formularza. Słaby INP często wiąże się z dużą ilością JavaScriptu, długimi zadaniami, ciężkim page builderem albo rozbudowaną strukturą strony. DOM to struktura elementów HTML budujących stronę — jeśli motyw i builder tworzą tysiące zagnieżdżonych elementów, każda interakcja może wymagać większej liczby obliczeń.
CLS mierzy nieoczekiwane przesunięcia elementów podczas korzystania ze strony. Problem pojawia się, gdy klient chce nacisnąć „Dodaj do koszyka", ale w ostatniej chwili nad przyciskiem pojawia się komunikat, banner lub nowa informacja. W WooCommerce przesunięcia często powodują obrazy bez określonych wymiarów, dynamiczna cena wariantu, banner cookies, pasek promocji, sekcja opinii, widget czatu, późno ładowany font i komunikat WooCommerce.
Czy TTFB jest częścią Core Web Vitals?
TTFB nie jest Core Web Vital, ale jest ważną metryką diagnostyczną podczas badania WooCommerce.
TTFB (Time to First Byte) mierzy czas od rozpoczęcia żądania do otrzymania pierwszego bajtu odpowiedzi z serwera. Orientacyjnie większość witryn powinna dążyć do około 0,8 sekundy lub mniej — to jednak nie jest oficjalny próg zaliczenia Core Web Vitals. Jeśli serwer odpowiada po 2 sekundach, przeglądarka dopiero wtedy może rozpocząć pobieranie dokumentu, stylów, skryptów i obrazów.
Co może podnosić TTFB w WooCommerce: przeciążony hosting, zbyt mało procesów PHP, wolna baza danych, ciężkie zapytania wtyczek, duża ilość danych autoload, brak object cache, wywołania zewnętrznego API, geolokalizacja, personalizacja cen i duża liczba wariantów. Autoload to dane z tabeli wp_options, które WordPress ładuje automatycznie przy każdym żądaniu — jeśli jest ich zbyt dużo, mogą niepotrzebnie obciążać bazę i pamięć. Object cache to pamięć podręczna wyników zapytań i obliczeń WordPressa (np. Redis), która ogranicza liczbę powtarzanych odczytów z bazy. Nie każdą stronę WooCommerce można obsłużyć pełnym cache — koszyk, checkout i konto klienta zawierają dane konkretnego użytkownika, dlatego wymagają sprawnego backendu i poprawnej konfiguracji sesji.
Dane terenowe i laboratoryjne — jaka jest różnica?
Dane terenowe pokazują doświadczenia prawdziwych użytkowników, a dane laboratoryjne pomagają odtworzyć problem i znaleźć jego przyczynę.
| Rodzaj danych | Co pokazuje? | Zaleta | Ograniczenie |
|---|---|---|---|
| Field / CrUX | Rzeczywiste wizyty użytkowników Chrome | Pokazuje realne doświadczenia | Wymaga odpowiedniego ruchu |
| Własny RUM | Dane zbierane bezpośrednio w sklepie | Więcej szczegółów i segmentów | Wymaga wdrożenia |
| Lab / Lighthouse | Symulowane wczytanie strony | Powtarzalna diagnostyka | Nie odwzorowuje wszystkich klientów |
| Test w DevTools | Konkretne interakcje | Pomaga diagnozować INP | Zależy od scenariusza i urządzenia |
Field data pochodzi z rzeczywistych wizyt. Publicznym źródłem Google jest CrUX (Chrome User Experience Report) — obejmuje kwalifikujące się wizyty użytkowników Chrome i może udostępniać dane dla konkretnego adresu albo całej domeny. W PageSpeed Insights dane CrUX obejmują kroczące okno ostatnich 28 dni. Field odpowiada na pytanie: jak sklep działał dla prawdziwych użytkowników?
Lab data powstaje podczas symulowanego testu. Lighthouse analizuje stronę w określonych warunkach urządzenia, procesora i sieci — może pokazać kolejność pobierania zasobów, blokujące pliki, element LCP, długie zadania, niewykorzystany JavaScript, przesunięcia układu, liczbę żądań i rozmiar strony. Lab odpowiada na pytanie: co może powodować problem i czy wdrożona zmiana poprawia wynik w tych samych warunkach testowych?
Field i lab to różne źródła — nie uśredniaj ich
Wyniki mogą się różnić z powodu innych urządzeń i sieci, lokalizacji użytkowników, pierwszej vs kolejnej wizyty, aktywnego cache, zgody na cookies, personalizacji, testów A/B, zmieniających się integracji i różnych zachowań użytkowników. Nie wybieraj wyniku, który wygląda korzystniej — najpierw ustal, z jakiego źródła pochodzi. LCP z CrUX nie powinno być uśredniane z LCP z Lighthouse.
Dlaczego Lighthouse nie jest oceną Core Web Vitals?
Wynik Lighthouse od 0 do 100 jest syntetyczną oceną testu laboratoryjnego, a nie wynikiem Core Web Vitals z realnych wizyt.
W części laboratoryjnej znajdziesz m.in. First Contentful Paint, Largest Contentful Paint, Speed Index, Total Blocking Time i Cumulative Layout Shift. INP nie jest standardowo mierzony przez zwykłe automatyczne otwarcie strony, ponieważ wymaga interakcji użytkownika. W Lighthouse funkcję diagnostyczną pełni m.in. TBT (Total Blocking Time) — pokazuje czas blokowania głównego wątku podczas ładowania.
TBT ≠ INP, a wynik 90/100 ≠ zaliczenie CWV
Nie przepisuj TBT do kolumny INP, nie traktuj wyniku 90/100 jako zaliczenia Core Web Vitals, nie porównuj raportów bez zapisania warunków testu i nie uznawaj jednego przebiegu za ostateczny wynik. Zaliczenie CWV wymaga dobrych danych terenowych (field) dla LCP, INP i CLS — Lighthouse jest tylko diagnostyką laboratoryjną.
Jakich narzędzi używać do raportu Core Web Vitals?
Google Search Console pokazuje problemy Core Web Vitals na poziomie grup podobnych adresów — rozdziela mobile/desktop oraz adresy dobre, wymagające poprawy i słabe, a karty produktów z tego samego szablonu może grupować. Raport nie pokazuje wszystkich adresów, wymaga odpowiedniej ilości danych, opiera się na rzeczywistych wizytach i może wskazywać problem dla grupy, a nie pojedynczego URL-a.
PageSpeed Insights (PSI) łączy dane terenowe CrUX z laboratoryjną analizą Lighthouse. Przed zapisaniem wyniku sprawdź, czy dane field dotyczą konkretnego URL-a czy całej domeny (originu), czy w ogóle są dostępne, jaki okres pokazują i czy oglądasz mobile czy desktop. Jeśli produkt nie ma wystarczającego ruchu, PSI może pokazać dane całej domeny — nie wolno wtedy przedstawiać ich jako wyniku konkretnego produktu.
CrUX Vis pomaga obserwować historyczny trend rzeczywistych wyników: kiedy metryka zaczęła się pogarszać, czy problem występuje stale, jak wygląda okres przed i po wdrożeniu oraz różnice mobile/desktop.
Własny RUM (Real User Monitoring) pozwala zbierać szczegółowe dane bez ograniczania się do publicznego CrUX — można użyć biblioteki web-vitals i przesyłać wyniki do własnej bazy, systemu analitycznego albo GA4, zapisując dodatkowo typ strony, urządzenie, wersję szablonu, element LCP, interakcję powodującą słaby INP, status zalogowania, aktywny eksperyment oraz metodę dostawy/płatności. Wyniki własnego RUM i CrUX nie muszą być identyczne — mogą obejmować inną grupę użytkowników i inne zasady zbierania danych.
Chrome DevTools (panel Performance) służy do technicznej analizy ładowania i interakcji — pomaga znaleźć element LCP, długie zadania, blokujący JavaScript, koszt przeliczania stylów, duży DOM, przesunięcia układu i wolne interakcje. Jest szczególnie przydatny przy diagnozie INP, bo pozwala wykonać konkretną czynność (np. użyć filtra albo wybrać wariant).
Jak przygotować raport Core Web Vitals krok po kroku?
Krok 1. Określ cel raportu. Najpierw ustal, czy raport dotyczy jednego sklepu, porównania konkurencji czy większej próby branżowej — to trzy różne projekty. Audyt jednego sklepu korzysta z Search Console, GA4, własnego RUM, logów serwera, danych o zamówieniach, środowiska testowego i informacji o wtyczkach — celem jest znalezienie i naprawienie problemu. Porównanie konkurencji ma dostęp głównie do publicznych danych CrUX, testów laboratoryjnych i publicznych podstron (nie widzisz konfiguracji serwera, danych sprzedażowych ani prywatnej części checkoutu). Raport branżowy wymaga opisania doboru domen, kryteriów włączenia/wykluczenia, metody potwierdzenia WooCommerce, liczebności próby, daty pomiaru, braków danych, sposobu agregacji i zasad anonimizacji — bez tego raport jest zbiorem wyników, a nie powtarzalnym badaniem.
Krok 2. Zbuduj reprezentatywną próbę stron. Sklepu nie można oceniać wyłącznie na podstawie strony głównej.
| Typ strony | Przykład |
|---|---|
| Strona główna | Główny landing sklepu |
| Kategoria | Popularna lista produktów |
| Kategoria z filtrami | Listing po użyciu ważnego filtra |
| Produkt prosty | Produkt bez wariantów |
| Produkt wariantowy | Rozmiary, kolory lub konfiguracja |
| Produkt promocyjny | Cena regularna i obniżona |
| Wyszukiwarka | Wyniki wyszukiwania w sklepie |
| Koszyk | Produkt dodany do koszyka |
| Checkout | Formularz, dostawa i płatność |
| Konto klienta | Logowanie i historia zamówień |
Koszyk, checkout i konto są zwykle nieindeksowane, personalizowane i odwiedzane przez mniejszą liczbę osób — dla nich często potrzebujesz własnego RUM albo testów manualnych. Dobierając produkty, uwzględnij produkt popularny, z wieloma zdjęciami, wariantowy, z opiniami, z filmem lub konfiguracją oraz otrzymujący najwięcej ruchu z reklam.
Krok 3. Zapisz warunki badania. Raport powinien pozwolić powtórzyć pomiar — zapisz datę i godzinę, badany URL, typ strony, urządzenie, źródło danych, okres danych field, wersję narzędzia, lokalizację testu, warunki sieci, stan cache, liczbę przebiegów, status zalogowania, zgodę lub brak zgody na cookies oraz aktywny wariant testu A/B. Przy porównaniu okresów zachowaj te same warunki.
Krok 4. Zbierz dane terenowe. Field data powinno być głównym źródłem informacji o tym, jak sklep działa dla prawdziwych użytkowników. Kolejność: otwórz raport CWV w Search Console → sprawdź mobile i desktop osobno → zapisz liczbę grup dobrych/wymagających poprawy/słabych → otwórz poszczególne problemy → zanotuj reprezentatywne adresy → sprawdź je w PSI → ustal czy PSI pokazuje dane URL-a czy originu → sprawdź historię w CrUX Vis → jeśli masz własny RUM, podziel wyniki wg szablonu i urządzenia. Jeśli publiczne źródło nie ma próbki, zapisz: „Brak wystarczających danych terenowych dla tego adresu. Wykonano test laboratoryjny, którego nie należy traktować jako wyniku rzeczywistych użytkowników". Brak danych CrUX nie oznacza, że strona jest szybka ani wolna.
Krok 5. Wykonaj testy laboratoryjne. Testy lab wykonuj kilkukrotnie w tych samych warunkach i raportuj medianę: co najmniej 3 przebiegi dla ważnego adresu (5 przy większym badaniu), osobne testy mobile/desktop, czysty profil przeglądarki, wyłączone rozszerzenia, ta sama lokalizacja i sieć, brak wdrożeń i ciężkich backupów podczas testu. Mediana to środkowy wynik po uporządkowaniu pomiarów — mniej podatna na pojedynczy skrajny przebieg. Przykład: 2,3 s / 2,5 s / 2,6 s / 2,9 s / 5,8 s → mediana LCP = 2,6 s. Nie wybieraj 2,3 s tylko dlatego, że jest najlepsze; pojedyncze 5,8 s też nie powinno automatycznie zastąpić analizy całej próbki.
Krok 6. Przetestuj interakcje ważne dla sprzedaży. INP wymaga rzeczywistych działań użytkownika, nie tylko automatycznego otwarcia strony. Przygotuj stały scenariusz. Kategoria: otwórz filtry → wybierz markę → ustaw zakres ceny → zmień sortowanie → wyczyść filtry → przejdź na kolejną stronę. Produkt wariantowy: zmień kolor → wybierz rozmiar → zmień liczbę sztuk → otwórz galerię → dodaj do koszyka → otwórz mini-koszyk. Koszyk i checkout: zmień liczbę produktów → zastosuj kod rabatowy → oblicz dostawę → wybierz punkt odbioru → zmień metodę płatności → wywołaj i popraw błąd formularza. AJAX pozwala doładować fragment strony bez przeładowania całego dokumentu — WooCommerce używa go m.in. do aktualizacji koszyka, fragmentów checkoutu i części filtrów; duża liczba kolejnych zapytań AJAX może powodować opóźnienia, zwłaszcza gdy każde uruchamia ciężkie zapytania do bazy albo zewnętrzne API. Zapisuj, która interakcja była wolna, czy wystąpiła podczas ładowania, jaki skrypt ją obsługiwał, jak długo główny wątek był zablokowany, ile elementów układu przeliczono i czy problem dotyczył jednej wtyczki.
Krok 7. Znajdź przyczynę, a nie tylko objaw. Każdy słaby wynik powinien być połączony z techniczną hipotezą i dowodem.
| Problem | Dowód | Prawdopodobna przyczyna |
|---|---|---|
| LCP 4,2 s na produkcie | Element LCP to zdjęcie 1,8 MB | Za duży plik i późne pobieranie |
| LCP 4,5 s przy TTFB 2,1 s | Dokument HTML zaczyna się późno | Serwer, baza lub ciężka wtyczka |
| INP 620 ms po użyciu filtra | Długie zadanie JavaScript | Filtry lub rozbudowany DOM |
| CLS 0,24 | Przesunięcie po pokazaniu bannera | Brak zarezerwowanego miejsca |
| Wolny checkout | Seria kolejnych zapytań AJAX | Dostawa, podatki lub płatność |
Nie pisz tylko „należy zmniejszyć JavaScript". Lepszy zapis: „Po wyborze wariantu skrypt wtyczki X blokuje główny wątek przez ok. 480 ms. Problem występuje na produktach wariantowych i dotyczy głównej interakcji zakupowej. Priorytet: wysoki".
Krok 8. Nadaj poprawkom priorytety. Priorytet powinien wynikać z wpływu na użytkownika i sprzedaż, a nie z kolejności zaleceń w Lighthouse.
| Priorytet | Znaczenie | Przykład |
|---|---|---|
| P0 — krytyczny | Blokuje lub poważnie utrudnia zakup | Niedziałający przycisk lub checkout |
| P1 — wysoki | Dotyczy dużego ruchu lub głównego szablonu | Słaby LCP wszystkich produktów |
| P2 — średni | Pogarsza doświadczenie, ale nie blokuje zakupu | Przesunięcie sekcji opinii |
| P3 — niski | Zmiana porządkowa o małym wpływie | Niewielka ilość zbędnego CSS |
Dodatkowo oceń liczbę objętych adresów, udział ruchu, wpływ na mobile, etap lejka, trudność wdrożenia, ryzyko uszkodzenia sklepu i możliwość przetestowania zmiany. Zmniejszenie logo o 15 KB może być łatwe, ale nie musi zmienić odczuwalnej szybkości; naprawa skryptu blokującego wybór wariantu wymaga więcej pracy, ale dotyczy bezpośrednio zakupu — powinna mieć wyższy priorytet.
Krok 9. Przetestuj poprawki przed wdrożeniem. Zmiany wydajnościowe sprawdzaj na stagingu oraz w pełnym procesie zakupowym. Po zmianie cache, JavaScriptu lub motywu przetestuj logowanie, ceny, warianty, kody rabatowe, koszyk, dostawy, płatności, e-maile, stany magazynowe i analitykę.
Cache: nie jedna reguła dla całego WooCommerce
Z pełnego cache trzeba wykluczyć albo odpowiednio obsłużyć: koszyk, checkout, konto klienta, treści zależne od zalogowania, ceny indywidualne, dane zależne od lokalizacji i elementy z danymi sesji. Źle skonfigurowany cache może poprawić wynik testu, a jednocześnie pokazać klientowi cudzy koszyk lub niewłaściwą cenę.
Krok 10. Zweryfikuj wyniki po wdrożeniu. Wynik laboratoryjny można sprawdzić od razu, ale dane terenowe zmieniają się stopniowo w 28-dniowym oknie CrUX. Po wdrożeniu: powtórz testy lab w tych samych warunkach → sprawdź proces zakupowy → porównaj mediany przed i po → obserwuj własny RUM → sprawdź trend w CrUX Vis → uruchom walidację problemu w Search Console → monitoruj wynik przez kolejne tygodnie. Nie oczekuj, że następnego dnia cały raport Search Console zmieni kolor na zielony — nowe wizyty stopniowo zastępują starsze dane, a trwała poprawa z czasem stanie się widoczna w wynikach terenowych.
Jak powinna wyglądać struktura raportu?
Raport powinien prowadzić od podsumowania biznesowego do technicznych dowodów i planu wdrożenia.
1. Podsumowanie dla właściciela (jedna strona): ogólny stan, najważniejszy problem, dotknięte szablony, potencjalny wpływ, trzy pierwsze działania, sposób weryfikacji. 2. Zakres i metodologia: badane adresy, urządzenia, okres danych, źródła, liczba przebiegów, ograniczenia, braki danych. 3. Dane terenowe: LCP/INP/CLS p75, udział dobrych wizyt, trend, mobile/desktop, URL vs origin. 4. Wyniki laboratoryjne: mediana LCP, TBT, CLS, TTFB, rozmiar strony, liczba żądań, element LCP, długie zadania. 5. Analiza według szablonu: osobno strona główna, kategorie, produkty, koszyk, checkout. 6. Lista problemów: dla każdego opis, dowód, dotknięte adresy, wpływ, priorytet, rekomendacja, odpowiedzialna osoba, sposób testowania. 7. Plan wdrożenia: szybkie poprawki, prace programistyczne, zmiany serwerowe, zmiany motywu, zmiany wtyczek, monitoring.
Przykładowa tabela wyników
Poniższe dane pokazują sposób budowy tabeli — nie są wynikiem konkretnego sklepu.
| Typ strony | Źródło | LCP | INP/TBT | CLS | TTFB | Status | Główny problem |
|---|---|---|---|---|---|---|---|
| Strona główna | CrUX URL | 2,3 s | 180 ms | 0,05 | 0,7 s | Dobry | Brak |
| Kategoria | RUM | 3,2 s | 240 ms | 0,08 | 0,9 s | Wymaga poprawy | Baner i filtry |
| Produkt | CrUX grupa | 4,1 s | 310 ms | 0,12 | 1,4 s | Słaby | Zdjęcie i serwer |
| Koszyk | Lab | 2,8 s | TBT 390 ms | 0,04 | 1,1 s | Diagnostyka | Skrypty koszyka |
| Checkout | Test manualny | — | Wolna walidacja | 0,03 | 1,6 s | Krytyczny | Płatność i dostawa |
Znak „—" nie oznacza wyniku 0 — oznacza, że metryka nie została wiarygodnie zmierzona w danym źródle.
Jak raportować wynik całego sklepu?
Nie sprowadzaj całego WooCommerce do jednej średniej liczby.
Lepsze wskaźniki zbiorcze to procent grup z dobrym wynikiem, procent wizyt przechodzących wszystkie trzy metryki, wyniki najważniejszych szablonów, mobile vs desktop, trend względem poprzedniego okresu, liczba problemów P0 i P1 oraz udział ruchu objętego problemem. Nie mieszaj w jednej średniej LCP w sekundach, INP w milisekundach, CLS bez jednostki i wyniku Lighthouse 0–100.
Metodologia publicznego raportu branżowego WooCommerce
Publiczny raport wymaga jasno opisanej próby, kryteriów kwalifikacji i zasad agregacji.
Dobór sklepów. Określ liczbę domen, kraj i język, sposób wykrywania WooCommerce, wymaganie aktywnego sklepu, minimalne elementy oferty, okres pobrania danych oraz sposób obsługi subdomen i wersji językowych.
Weryfikacja WooCommerce. Automatyczne wykrywanie technologii może się mylić — potwierdź próbę na podstawie kodu źródłowego, charakterystycznych zasobów WooCommerce, endpointów, struktury koszyka i ręcznej kontroli części domen. Endpoint to konkretny adres lub punkt komunikacji, przez który aplikacja udostępnia dane albo przyjmuje żądania. Jeśli raport obejmuje sklepy headless, oznacz je osobno — headless oznacza, że WooCommerce działa jako zaplecze, a warstwa widoczna dla klienta została zbudowana w innej technologii.
Braki danych. Nie usuwaj bez wyjaśnienia wszystkich sklepów bez CrUX. Pokaż, ile domen miało pełne dane, ile tylko dane originu, ile nie miało danych i ile zostało wykluczonych oraz z jakiego powodu. Brak danych CrUX nie jest wynikiem wydajności.
Anonimizacja. Jeśli celem jest opisanie kondycji rynku, publikuj przede wszystkim wyniki zbiorcze. Lista „najwolniejszych sklepów" może prowadzić do mylących wniosków, bo nie znasz zmian wdrażanych w trakcie badania, eksperymentów, lokalizacji użytkowników, struktury ruchu, warunków serwera ani przyczyn technicznych. Nazwy konkretnych sklepów publikuj tylko wtedy, gdy metodologia i kontekst to uzasadniają.
Najczęstsze problemy WooCommerce według metryki
Problemy z LCP najczęściej powodują: wolny serwer, ciężkie zdjęcie główne, slider, lazy-loading elementu LCP, późne wykrycie zasobu, blokujące CSS, ciężki font i banner uruchamiany przez JavaScript. Sprawdź najpierw: jaki element jest LCP, jaki jest TTFB, kiedy przeglądarka wykrywa zasób, ile waży plik, czy ma prawidłowe wymiary, czy jest ładowany priorytetowo i co opóźnia jego wyrenderowanie. Preload to instrukcja, że określony zasób przeglądarka powinna pobrać wcześniej i z wysokim priorytetem — nie ustawiaj go dla wszystkich obrazów, priorytet powinien otrzymać rzeczywisty element potrzebny na początku ładowania.
Problemy z INP najczęściej powodują: ciężkie filtry, duża liczba wariantów, rozbudowany DOM, page builder, skrypty reklamowe, czat, system rekomendacji, mini-koszyk, skrypty opinii i długie zadania JavaScript. Sprawdź najpierw najwolniejsze interakcje, długie zadania, skrypt odpowiedzialny za zdarzenie, liczbę przeliczanych elementów, zachowanie podczas ładowania i wynik po wyłączeniu podejrzanej wtyczki na stagingu.
Problemy z CLS najczęściej powodują: brak wymiarów obrazów, zmiana wysokości galerii, dynamiczne ceny wariantów, pasek promocji, banner cookies, font zmieniający szerokość tekstu, widget opinii, komunikaty WooCommerce i sticky menu. Sprawdź najpierw element powodujący największe przesunięcie, czy jego miejsce jest zarezerwowane, czy zmiana następuje po zgodzie cookies, czy problem pojawia się po wyborze wariantu i czy występuje podczas przewijania.
Problemy z TTFB najczęściej powodują: hosting niedopasowany do sklepu, wolne PHP, ciężka baza, zapytania bez indeksów, nadmierny autoload, brak object cache, zewnętrzne API, duża liczba wtyczek, obciążenie przez boty i zadania cron wykonywane podczas wizyty. Cron to mechanizm uruchamiający zaplanowane zadania (synchronizacja produktów, wysyłka wiadomości, czyszczenie danych). Redis lub inny object cache może ograniczyć liczbę powtarzanych zapytań, ale nie naprawi źle napisanej wtyczki ani wolnej odpowiedzi zewnętrznego API. Więcej działań w poradniku jak przyspieszyć sklep WooCommerce oraz artykule hosting pod WooCommerce — jak wybrać.
Najczęstsze błędy w raportach Core Web Vitals
Najczęściej powtarzane błędy zafałszowują obraz wydajności i prowadzą do złych decyzji.
Raportowanie pojedynczego testu — jeden przebieg może wypaść skrajnie; raportuj medianę kilku pomiarów. Testowanie tylko strony głównej — może być szybka, gdy produkt, filtry i checkout mają poważne problemy. Mieszanie danych terenowych i laboratoryjnych — LCP z CrUX nie uśredniaj z LCP z Lighthouse. Traktowanie wyniku 90 jako zaliczenia CWV — Lighthouse nie zastępuje rzeczywistych danych LCP, INP, CLS. Podawanie TBT jako INP — TBT wspiera diagnozę, ale to inny pomiar. Brak informacji URL vs origin — dane całej domeny nie są wynikiem konkretnej karty produktu. Brak testów procesu zakupowego — raport może poprawić stronę główną, a pozostawić wolne filtry, koszyk i płatność. Instalowanie kolejnej wtyczki „do szybkości" — kilka narzędzi cache może zmieniać te same zasoby i powodować trudne do odtworzenia błędy. Brak testu po wdrożeniu — lepszy wynik nie ma wartości, jeśli przestały działać warianty, koszyk lub płatności.
Co możesz sprawdzić samodzielnie?
Podstawową diagnozę wykonasz, przechodząc poniższą listę dla kilku typów stron.
- Otwórz raport Core Web Vitals w Google Search Console.
- Sprawdź mobile i desktop osobno.
- Przetestuj stronę główną, kategorię i produkt.
- Ustal, czy dane PSI dotyczą URL-a, czy originu.
- Zapisz element LCP każdej badanej strony.
- Porównaj TTFB poszczególnych szablonów.
- Wykonaj co najmniej trzy przebiegi.
- Otwórz sklep na telefonie w trybie prywatnym.
- Użyj filtrów i wariantów.
- Dodaj produkt do koszyka.
- Przejdź przez dostawę i płatność.
- Zwróć uwagę na przesunięcia przycisku zakupu.
- Porównaj zachowanie przed i po zgodzie na cookies.
- Zapisz datę, urządzenie i warunki pomiaru.
Możesz też użyć kalkulatora utraty sprzedaży, aby oszacować, ile kosztuje wolny sklep.
Kiedy warto zlecić to specjaliście?
Pomoc techniczna jest potrzebna, gdy wynik wskazuje problem, ale nie wiadomo, która warstwa WooCommerce go powoduje ani jak bezpiecznie ją zmienić.
Warto zlecić analizę, gdy Search Console pokazuje słabe grupy adresów, wyniki lab i field znacznie się różnią, sklep nie ma publicznych danych CrUX, nie wiesz jaki element jest LCP, INP pogarsza się po użyciu filtrów, checkout działa wolno mimo szybkiej strony głównej, zmiana cache powoduje błędy koszyka, sklep ma dużo wtyczek, problemy pojawiły się po przebudowie, TTFB rośnie podczas większego ruchu, potrzebujesz raportu dla zarządu lub klienta, chcesz porównać wyniki przed migracją i po niej, potrzebujesz własnego RUM albo wdrożenie wymaga zmian w motywie, wtyczce lub serwerze. W takim przypadku potrzebny jest nie tylko test szybkości, lecz audyt SEO technicznego łączący dane terenowe, testy laboratoryjne, analizę kodu, serwera i najważniejszych szablonów WooCommerce. Jeśli głównym problemem jest infrastruktura, sprawdź też serwer pod WordPress i WooCommerce.
Najczęściej zadawane pytania
Jakie Core Web Vitals obowiązują w 2026 roku?
LCP, INP i CLS. Dobre progi to LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1, oceniane na 75. percentylu wizyt.
Czy Core Web Vitals wpływają na pozycje w Google?
Core Web Vitals są częścią szerszej oceny doświadczenia strony, ale nie stanowią samodzielnego czynnika gwarantującego wysoką pozycję. Trafność i jakość treści nadal mają podstawowe znaczenie.
Dlaczego PageSpeed pokazuje dobry wynik, a Search Console słaby?
PageSpeed może pokazywać bieżący test laboratoryjny, natomiast Search Console opiera się na danych prawdziwych użytkowników z ostatnich 28 dni. Są to różne źródła i okresy.
Czy wynik Lighthouse 90 oznacza, że sklep przechodzi Core Web Vitals?
Nie. Wynik Lighthouse jest oceną laboratoryjną. Zaliczenie Core Web Vitals wymaga dobrych danych terenowych dla LCP, INP i CLS.
Co oznacza brak danych w PageSpeed Insights?
Najczęściej dany adres lub cała domena nie ma wystarczającej liczby kwalifikujących się wizyt w CrUX. Brak danych nie oznacza ani dobrego, ani słabego wyniku.
Ile razy wykonać test PageSpeed?
Do podstawowej diagnozy warto wykonać przynajmniej trzy przebiegi w tych samych warunkach i zapisać medianę. Przy raporcie porównawczym można zastosować pięć lub więcej przebiegów.
Czy analizować mobile czy desktop?
Oba typy urządzeń należy analizować osobno. Mobile zwykle stawia trudniejsze warunki techniczne, ale priorytet warto ustalić także na podstawie rzeczywistego udziału ruchu.
Jak często przygotowywać raport Core Web Vitals?
Stały monitoring może działać codziennie. Pełny raport warto przygotować przed większym wdrożeniem, po jego zakończeniu oraz okresowo, na przykład raz na kwartał.
Celem nie jest 100 punktów, tylko sprawny sklep
Rzetelny raport Core Web Vitals dla WooCommerce nie sprowadza się do wyniku PageSpeed. Powinien rozdzielać field i lab, pokazywać 75. percentyl, badać mobile i desktop, obejmować różne typy podstron, testować interakcje zakupowe, uwzględniać TTFB diagnostycznie, wskazywać konkretną przyczynę, nadawać poprawkom priorytety, opisywać metodologię i porównywać wynik przed i po wdrożeniu.
Celem nie jest zdobycie 100 punktów, lecz sklep, który szybko pokazuje produkt, reaguje na działania klienta, nie przesuwa przycisków i pozwala bez problemu przejść do płatności. Jeśli chcesz sprawdzić Core Web Vitals swojego WooCommerce, możemy przygotować raport obejmujący CrUX, Search Console, Lighthouse, kluczowe szablony, filtry, produkty i checkout:
- SEO techniczne — wyniki, przyczyny, priorytety wdrożenia i sposób sprawdzenia efektów.
- Serwery WordPress i WooCommerce — gdy źródłem problemu jest infrastruktura i TTFB.
- Core Web Vitals — podstawy oraz jak przyspieszyć sklep WooCommerce — powiązane poradniki.
