Sklep ma zielony wynik w PageSpeed Insights, a sprzedaż na telefonach uparcie nie chce rosnąć. Znasz to? Powiem Ci od razu, bez owijania w bawełnę: ten zielony wynik wcale nie musi kłamać — on po prostu opisuje coś innego, niż myślisz. W tym tekście pokażę Ci, co Core Web Vitals mówią o Twoim sklepie, w których miejscach ścieżki zakupowej realnie tracisz konwersje i pozycje, i dlaczego prawdziwą odpowiedź dają dopiero pomiary od Twoich klientów, a nie z testu laboratoryjnego.
Trzy metryki, które Google przelicza na doświadczenie klienta
Core Web Vitals brzmi jak coś, co powinno zostać w dziale IT. W praktyce to trzy bardzo proste pytania o Twojego klienta, tylko zadane językiem liczb.
| Metryka | Próg Google | Po ludzku: o co pyta |
|---|---|---|
| LCP | do 2,5 s | Jak szybko klient widzi zdjęcie produktu albo pierwszy rząd listingu? |
| INP | do 200 ms | Czy filtr, wyszukiwarka i „dodaj do koszyka” reagują, gdy klient klika? |
| CLS | do 0,1 | Czy układ strony nie skacze klientowi pod palcem? |
Zwróć uwagę, że każda z nich dotyczy innego momentu zakupów. LCP decyduje o tym, czy klient w ogóle zostanie. INP — czy sprawnie przejdzie przez wybór rozmiaru, koloru i wariantu. CLS — czy nie kliknie w baner zamiast w „Kup teraz”, bo strona przesunęła mu się w ostatniej chwili.
Google ocenia to wszystko na podstawie zachowania prawdziwych użytkowników Chrome i przykłada do tego dwa warunki, które warto znać, bo tłumaczą większość nieporozumień:
- Liczy się 75. percentyl, czyli doświadczenie tych klientów, którym już jest wolno — a nie wygodna średnia.
- Musisz zaliczyć wszystkie trzy metryki naraz. Jedna w żółtym strefie wywala ocenę całej strony.
I dlatego to nie jest tak łatwe, jak się wydaje. Według danych z Chrome UX Report za maj 2026 komplet Core Web Vitals zaliczało niecałe 56% badanych witryn — mimo że każda metryka z osobna wypadała znacznie lepiej. Większość sklepów przewraca się na jednej rzeczy, nie na wszystkim naraz. Sztuka polega na tym, żeby wiedzieć, na której.
Dlaczego zielony wynik potrafi uśpić czujność
Nie mam nic przeciwko PageSpeed Insights. To dobre narzędzie i dobry pierwszy przystanek — szybko, za darmo, z listą rzeczy do poprawy. Problem zaczyna się wtedy, gdy ktoś na podstawie jednego testu strony głównej wyciąga wniosek o całym sklepie i idzie z tym na spotkanie zarządu.
Wyobraź sobie, że oceniasz nowy samochód wyłącznie na podstawie jazdy testowej po torze. Ładna pogoda, pusty asfalt, jeden kierowca. Dowiesz się czegoś o aucie, ale niczego o tym, jak zachowa się w korku, z pełnym bagażnikiem, zimą, na dziurawej drodze do pracy. Test laboratoryjny wydajności działa dokładnie tak samo: to symulacja jednego urządzenia, na stabilnym łączu, w jednym momencie.
Druga sekcja w PageSpeed — ta z danymi od realnych użytkowników — jest już bliżej prawdy, ale ma trzy ograniczenia, o których rzadko się mówi:
- Jest uśredniona. Pokazuje wynik dla całej witryny albo pojedynczego adresu, zbiorczo z ostatnich 28 dni.
- Nie obejmuje wszystkiego. Adresy o mniejszym ruchu — a takich w sklepie są setki — po prostu się w niej nie pojawiają.
- Nie mówi, co naprawić. Informacja „przekroczony wskaźnik CLS na kategoriach” nie wskazuje programiście ani jednego miejsca w kodzie.
To ostatnie jest w praktyce najdroższe. Bo między „mamy problem z wydajnością” a „popraw ten element na tym szablonie” leży zwykle kilka tygodni pracy działu IT, sporo dyskusji i budżet, który nie zamienia się w wynik.
Średnia to pułapka — i to w niej giną pieniądze
To jest mechanizm, który w sklepach widzę najczęściej i który kosztuje najwięcej.
Twój sklep ma pewnie kilkaset albo kilka tysięcy adresów. Regulaminy, archiwum bloga, strony informacyjne, stare kategorie, produkty niedostępne. Te podstrony są zwykle bardzo szybkie, bo prawie nic na nich nie ma — i bardzo licznie zawyżają Ci średnią. A pieniądze robi kilka, może kilkanaście szablonów: strona główna, listing kategorii, listing z włączonymi filtrami, karta produktu, karta produktu z wariantami, wyszukiwarka, koszyk, checkout.
W efekcie łatwo o raport, w którym wszystko świeci na zielono, a klient i tak wychodzi w połowie drogi do koszyka. Setki szybkich, rzadko odwiedzanych podstron potrafią skutecznie zasłonić poważny problem na tych kilkunastu adresach, przez które przechodzi większość Twojej sprzedaży.
Częsty błąd: mierzenie strony głównej zamiast ścieżki zakupowej Strona główna jest zwykle najlepiej dopieszczona i najrzadziej bywa ostatnim krokiem przed zakupem. Ruch z Google w e-commerce wchodzi na kategorie i karty produktów — i to tam trzeba mierzyć. Jeśli raport wydajności Twojego sklepu zaczyna się i kończy na stronie głównej, mierzysz wizytówkę, a nie sklep.
Czego test laboratoryjny nie pokaże nigdy
Są cztery rzeczy, których pojedynczy test nie wykryje z definicji. Nie dlatego, że narzędzie jest złe — po prostu mierzy co innego.
1. Szczyty sezonu. Test uruchomiony w maju nie powie Ci nic o tym, jak sklep zachowa się w Black Friday albo w pierwszy śnieżny weekend. A to właśnie w tych wąskich oknach robisz wynik roku i to wtedy serwer najczęściej zaczyna się dławić.
2. Realne urządzenia i realne sieci. Twoi klienci nie siedzą przy światłowodzie na nowym laptopie. Kupują na telefonie sprzed czterech lat, w drodze, przy zmiennym zasięgu, często z blokerem reklam. Te same podstrony zachowują się u nich zupełnie inaczej niż w teście.
3. Regresje po wdrożeniu. Marketing wgrywa nową kreację przed kampanią, ktoś dokłada skrypt do testów, agencja podpina nowy piksel. Każda z tych rzeczy z osobna to drobiazg. Bez stałego pomiaru dowiesz się o skutkach dopiero z wykresu sprzedaży, kilka tygodni później.
4. Skala. Ręczne przeklikanie kilkuset kategorii i kart produktów jest nierealne. Jeśli sprawdzasz wyrywkowo, mierzysz próbkę, którą sam wybrałeś — a niekoniecznie tę, na której zarabiasz.
Co zmienia pomiar na prawdziwych użytkownikach
Tu wchodzi rozwiązanie, które w naszej pracy zmieniło najwięcej: RUM, czyli monitoring wydajności oparty na danych od realnych użytkowników. W skrócie — zamiast raz na jakiś czas symulować wizytę, mierzysz każdą prawdziwą.
Do zbierania danych używamy oficjalnej biblioteki Google, tej samej, na której opiera się metodologia Chrome. Różnica polega na tym, że publiczne dane Google są zbiorcze, a własna telemetria działa na poziomie pojedynczej odsłony. To brzmi jak niuans, a jest przepaścią, bo:
- Widzisz rozkład, nie jedną liczbę. Nie „LCP wynosi 1,4 s”, tylko „na kategoriach połowa klientów ma 1,4 s, a co czwarty prawie 4 s — i wszyscy oni są z jednego rynku, na jednym typie urządzenia”.
- Metryka dostaje kontekst biznesowy. Zestawiamy wydajność z realnymi zachowaniami: użyciem filtrów, konfiguratorem produktu, dodaniem do koszyka. Wtedy widać, ile kosztuje konkretne opóźnienie.
- Raport zamienia się w listę zadań. Zamiast „popraw CLS” dział IT dostaje wskazanie konkretnego elementu, który odpowiada za problem. To różnica między ticketem do zrobienia w sprincie a ticketem wiszącym w backlogu przez kwartał.
- Regresję widać od razu. Alert po wdrożeniu, a nie zdziwienie po sezonie.
Dane spinamy potem w BigQuery i pokazujemy w trzech widokach: technicznym dla działu IT, alertowym pod planowanie prac i biznesowym dla zarządu. Jeden wspólny dashboard dla wszystkich nigdy nie działa — programista i prezes potrzebują innych liczb, żeby podjąć decyzję.
Powiem też uczciwie, czego RUM nie robi To nie jest narzędzie na „sprawdźmy w pięć minut, czy jest źle” — do tego wystarczy PageSpeed. Potrzeba kilku tygodni, żeby uzbierać próbkę, z której da się wyciągać wnioski, dane trzeba oczyścić z ruchu botów, a sam pomiar zaprojektować tak, żeby dodatkowo nie obciążał strony. To inwestycja w stałą wiedzę o sklepie, a nie szybki audyt. Jeśli ktoś obiecuje Ci komplet wniosków po tygodniu, to albo bardzo dużo zgaduje, albo bardzo mało mierzy.
Jak to wyglądało u naszego klienta
Żeby nie zostać na poziomie ogólników — konkret z projektu, który opisaliśmy szczegółowo w osobnym case study.
Klientem był duży sklep z asortymentem sportowym, działający na kilku rynkach europejskich, z bardzo mocną sezonowością: piki zimą na nartach, latem na rowerach. Firma sprawdzała wydajność w PageSpeed Insights i wszystko wyglądało poprawnie. Zebraliśmy ponad 329 000 zwalidowanych zdarzeń z 566 kluczowych adresów URL i obraz zmienił się natychmiast.
Uśrednione wartości dla całego serwisu wyglądały wzorowo. Pod nimi siedziały trzy problemy, z których każdy uderzał dokładnie w sprzedaż:
- Serwer odpowiadał 2,5 sekundy na najważniejszych stronach wejściowych przy rekomendowanym progu 0,8 sekundy. Dopóki to się nie zmieni, poprawianie grafik nie ma sensu, bo przeglądarka i tak czeka.
- Jeden komponent psuł układ na wszystkich listingach kategorii. Jeden błąd, kilkaset adresów. Audyt ręczny szukałby go tygodniami.
- Wyszukiwarka reagowała nawet po 285 ms. To ta ścieżka, którą idzie klient najbardziej zdecydowany na zakup — i najłatwiejsza do zepsucia.
Dział IT dostał gotową, spriorytetyzowaną listę zadań, ułożoną według faktycznego ruchu na ścieżce zakupowej, a nie według czyjegoś przeczucia. Skala korzyści jest łatwa do oszacowania: zgodnie z badaniami Google i Deloitte dla e-commerce poprawa mobilnego czasu ładowania o zaledwie 0,1 sekundy przekłada się na wzrost konwersji o około 8%. Przy skróceniu odpowiedzi serwera z 2,5 do 0,8 sekundy mówimy o zupełnie innej skali niż dziesiąte części sekundy.
Całość — z architekturą rozwiązania, kompletem wniosków i zestawieniem „przed i po” — znajdziesz tutaj: Real User Monitoring: jak przestaliśmy zgadywać i wskazaliśmy IT, co dokładnie psuje sprzedaż. Warto przeczytać, zanim zamówisz kolejny audyt wydajności — choćby po to, żeby wiedzieć, o co pytać.
Pięć pytań, które warto zadać swojej agencji lub działowi IT
Nie musisz znać się na kodzie, żeby ocenić, czy ktoś realnie panuje nad wydajnością Twojego sklepu. Wystarczy pięć pytań:
- Które szablony sklepu mierzymy? Jeśli odpowiedź brzmi „stronę główną”, masz odpowiedź na wszystkie kolejne pytania.
- Patrzymy na średnią czy na 75. percentyl? Google ocenia to drugie. Średnia ładnie wygląda w prezentacji i niewiele znaczy.
- Skąd wiemy, że problem dotyczy tego konkretnego elementu? Dobry raport wskazuje miejsce, nie tylko metrykę.
- Jak szybko dowiemy się, że coś się popsuło po wdrożeniu? Odpowiedź „przy następnym audycie” oznacza, że przez kwartał jedziesz na ślepo.
- Jak wyglądały nasze metryki w zeszłym sezonie o tej samej porze? Bez porównywalnych danych rok do roku nie ocenisz, czy w ogóle idziesz w dobrą stronę.
Jeśli na większość z nich nie ma dziś dobrej odpowiedzi, to nie znaczy, że ktoś pracuje źle. Znaczy tylko tyle, że sklep jest mierzony narzędziem, które nie było do tego zaprojektowane.
Od czego zacząć
Najprościej: przestań patrzeć na jedną liczbę dla całej domeny i zacznij patrzeć na kilka szablonów, przez które przechodzą Twoje pieniądze. Sprawdź, jak wyglądają osobno strona główna, kategoria, karta produktu i koszyk. Jeśli różnią się między sobą wyraźnie, wiesz już, gdzie szukać — i wiesz, że średnia Cię do tej pory uspokajała.
A jeśli chcesz zobaczyć swój sklep oczami klientów, a nie symulatora, to dokładnie to robimy w ramach monitoringu wydajności: projektujemy pomiar, zbieramy dane z realnych sesji zakupowych i zamieniamy je na konkretne zadania dla Twoich programistów, ułożone według wpływu na sprzedaż.
Napisz, obgadamy Twój przypadek na spokojnie — co już masz wpięte, gdzie realnie boli i czy w ogóle warto od razu iść w pełny monitoring, czy najpierw uporządkować dwie rzeczy, które widać od ręki. Bez zobowiązań i bez opowieści o tym, że wszystko trzeba przepisać od zera.
Chcę wiedzieć, co naprawdę spowalnia mój sklep → Umów bezpłatną konsultację
Na koniec drobna rada z praktyki: jak już wdrożycie pierwsze poprawki, nie odświeżaj raportów w piątek po wdrożeniu. Google liczy te dane w oknie 28-dniowym, więc i tak zobaczysz efekt dopiero za kilka tygodni. Lepiej sprawdzić to od razu na własnych pomiarach — i spokojnie wrócić do kawy.
