Wchodzisz na własny sklep, ładuje się ładnie, więc wydaje się, że jest dobrze. Problem w tym, że Ty masz go w cache przeglądarki i mocny telefon, a klient z reklamy wchodzi pierwszy raz, z gorszą siecią i często ze starszym sprzętem. To jego doświadczenie liczy Google - i to ono decyduje, czy dojdzie do koszyka.
Core Web Vitals to trzy konkretne miary tego doświadczenia. Nie chodzi o ogólne „strona szybka czy wolna”, tylko o trzy odrębne rzeczy: jak szybko pojawia się główna treść, jak szybko strona reaguje na kliknięcie i czy układ nie skacze pod palcem. Każda z nich psuje sprzedaż w inny sposób i naprawia się ją inaczej.
Rozkładam je tak, żeby było jasne, co realnie boli w sklepie WooCommerce, jak to sprawdzić i co naprawić najpierw, żeby uzyskać najwięcej najmniejszym kosztem.
LCP - jak szybko widać główną treść
LCP (Largest Contentful Paint) mierzy, po jakim czasie pojawia się największy element na pierwszym ekranie - zwykle zdjęcie hero albo główne zdjęcie produktu. To moment, w którym klient czuje „ok, strona się załadowała”. Google chce, żeby zmieścić się w 2,5 sekundy na telefonie. Powyżej 4 sekund jesteś już w czerwonej strefie.
W WooCommerce LCP psują najczęściej te same rzeczy:
- ciężkie zdjęcie hero albo banner wgrany prosto z grafika, ważący kilka MB
- zdjęcia w starym formacie JPG/PNG zamiast WebP czy AVIF
- wolny serwer, który długo myśli, zanim w ogóle zacznie wysyłać stronę (to tzw. TTFB - czas do pierwszej odpowiedzi)
- slidery i buildery, które najpierw ładują własny kod, a dopiero potem pokazują obrazek
Najczęstszy winowajca to po prostu największe zdjęcie na górze. Jeśli waży 3 MB i ładuje się dopiero po skryptach buildera, masz LCP na poziomie kilku sekund, choćby reszta sklepu była lekka.
Co pomaga: zdjęcie hero w WebP, ściśnięte do rozsądnej wagi i w rozmiarze, w jakim faktycznie się wyświetla. Plus szybka pierwsza odpowiedź serwera - czyli przyzwoity hosting i cache. To zwykle największy pojedynczy skok na liczniku.
INP - jak szybko sklep reaguje na kliknięcie
INP (Interaction to Next Paint) mierzy opóźnienie między tym, że klient coś kliknie - „dodaj do koszyka”, filtr, rozwinięcie menu - a tym, że strona faktycznie zareaguje. To frustracja typu „kliknąłem i nic, więc klikam jeszcze raz”. Cel to poniżej 200 milisekund. Powyżej pół sekundy klient czuje, że sklep się zacina.
INP psuje głównie nadmiar JavaScriptu pracującego w tle. Przeglądarka ma jeden „pas ruchu” na liczenie - jeśli w momencie kliknięcia akurat przeżuwa skrypty wtyczek, buildera i narzędzi marketingowych, Twoje kliknięcie czeka w kolejce. W WooCommerce dochodzi do tego specyfika koszyka: domyślnie na każdej podstronie chodzi skrypt odświeżający koszyk przez AJAX (tzw. cart fragments), który potrafi obciążać interakcje tam, gdzie wcale nie jest potrzebny.
To akurat ta sama rodzina problemów, którą opisuję szerzej w tekście dlaczego sklep WooCommerce wolno działa - tyle że tu chodzi konkretnie o reakcję na klik, nie o samo ładowanie.
Co pomaga: mniej kodu na starcie - wyłączenie wtyczek, które realnie nic nie wnoszą, warunkowe ładowanie skryptów tylko tam, gdzie są potrzebne, i ograniczenie cart fragments do stron z koszykiem. Mniej JavaScriptu = szybsza reakcja.
CLS - czy układ nie skacze pod palcem
CLS (Cumulative Layout Shift) mierzy, jak bardzo elementy przeskakują w trakcie ładowania. Każdy zna to uczucie: chcesz kliknąć „kup”, w ostatniej chwili doładowuje się baner albo zdjęcie i przycisk ucieka w dół, a Ty klikasz coś innego. W sklepie to nie tylko irytacja - to realnie kliknięcia mijające się z celem i porzucone zakupy. Google chce wyniku poniżej 0,1.
Co powoduje skoki w WooCommerce:
- obrazy bez podanych wymiarów - przeglądarka nie wie, ile miejsca zarezerwować, więc treść skacze, gdy zdjęcie wreszcie dojdzie
- czcionki ładowane z opóźnieniem, które podmieniają tekst i przesuwają układ
- banery, cookie-bary i widgety doładowywane na górze strony już po tym, jak klient zaczął czytać
- treści wstrzykiwane przez wtyczki i reklamy bez zarezerwowanego miejsca
CLS jest podstępny, bo na Twoim szybkim łączu zdjęcia doładowują się od razu i nic nie skacze. Klient na wolniejszej sieci widzi zupełnie inny, skaczący sklep.
Co pomaga: podanie wymiarów (szerokość i wysokość) dla każdego zdjęcia, rezerwacja miejsca na banery i widgety z góry oraz rozsądne ładowanie czcionek. To często najtańsza naprawa z całej trójki - sam efekt skakania znika, gdy elementy mają z góry przypisane miejsce.
Jak Core Web Vitals przekładają się na sprzedaż i Google
Dwie rzeczy łączą się tu w jedno. Po pierwsze konwersja: wolniejszy i bardziej „skaczący” sklep traci klientów po drodze. Według danych Google prawdopodobieństwo porzucenia strony mocno rośnie wraz z czasem ładowania - przy wzroście z 1 do 3 sekund skok jest wyraźny. W e-commerce każda taka sekunda to mniej koszyków, niezależnie od tego, jak dobra jest oferta.
Po drugie pozycja w wyszukiwarce. Core Web Vitals są jednym z sygnałów rankingowych Google i - co kluczowe - liczą się z wersji mobilnej (mobile-first). Google ocenia Twój sklep tak, jak wygląda na telefonie, a nie na Twoim monitorze. To dlatego sklep, który na desktopie chodzi świetnie, potrafi mieć słabe wyniki tam, gdzie Google faktycznie patrzy.
Same Core Web Vitals nie wygrają rankingu zamiast dobrej treści i sensownej oferty - ale słabe wyniki realnie ciągną w dół, a klient i tak głosuje nogami. To jeden z powodów, dla których przy przyspieszaniu sklepu WooCommerce traktuję wydajność jako część projektu, a nie poprawkę „na potem”.
Jak to zmierzyć - pole kontra laboratorium
Zacznij od PageSpeed Insights - wklejasz adres i dostajesz wszystkie trzy wartości osobno dla telefonu i komputera. Patrz na telefon, bo to jego liczy Google. Jedna rzecz, która myli wszystkich: PSI pokazuje dwa rodzaje danych i łatwo wyciągnąć złe wnioski.
- Dane z pola (field data) - to realni użytkownicy z ostatnich 28 dni, zebrane przez Chrome. Pokazują, jak Twój sklep faktycznie zachowuje się u klientów, na różnych telefonach i sieciach. To jest prawda. Pojawiają się dopiero, gdy sklep ma wystarczający ruch.
- Dane z laboratorium (lab data) - to jeden test na symulowanym urządzeniu, robiony w danej chwili. Świetny do diagnozy „co konkretnie naprawić”, bo daje listę rekomendacji, ale to nie jest to samo, co doświadczenie realnych klientów.
Najczęstszy błąd to chwalenie się dobrym wynikiem z laboratorium, gdy dane z pola mówią coś zupełnie innego. Jeśli masz mały ruch i pola brak, posiłkuj się testem z telefonu na danych komórkowych - to bliżej rzeczywistości niż test na szybkim wifi w biurze.
Co pomaga: zawsze patrz najpierw na dane z pola dla telefonu. Jak ich nie ma - testuj na realnym telefonie, nie na własnym laptopie. Liczby z laptopa prawie zawsze kłamią na plus.
Jak przejść przez taki pomiar krok po kroku i nie wpaść w pułapkę „zielonego wyniku”, rozpisałem osobno w mini-audycie PSI.
Co naprawić najpierw
Reguła jest prosta: najpierw mierzę, potem naprawiam, i biorę się za to, co daje największy efekt najmniejszym kosztem. W praktyce kolejność wygląda u mnie tak:
- Zdjęcie hero i pierwszy ekran - to najszybszy skok na LCP. WebP, sensowna waga, właściwy rozmiar. Często sam ten krok wyciąga LCP z czerwonej strefy.
- Szybka pierwsza odpowiedź serwera - przyzwoity hosting plus poprawnie ustawiony cache. Bez tego cała reszta startuje z opóźnieniem.
- Wymiary obrazów i rezerwacja miejsca - tania, szybka naprawa CLS, która od razu kończy problem skakania.
- Odchudzenie JavaScriptu - mniej wtyczek, warunkowe ładowanie skryptów, ograniczenie cart fragments. To poprawia INP, czyli reakcję na kliknięcia.
- Zewnętrzne skrypty (third-party) - czaty, piksele, mapy, widgety opinii. Każdy z nich dokłada obciążenie spoza Twojej kontroli. Zostaw te, które realnie zarabiają, resztę utnij albo załaduj z opóźnieniem.
Nie trzeba robić wszystkiego naraz i prawie nigdy nie trzeba budować sklepu od zera. W większości przypadków słabe Core Web Vitals to suma kilku z powyższych rzeczy, a nie „zły sklep”. Posprzątanie ich po kolei zwykle przesuwa liczby z czerwonego na zielony bez utraty produktów, zamówień i pozycji w Google.
Od czego zacząć u siebie
Jeśli nie wiesz, w którą z tych liczb celować najpierw - nie zgaduj, podeślij mi link. Zrobię bezpłatny przegląd, zmierzę Core Web Vitals Twojego sklepu na telefonie i powiem wprost, co konkretnie dławi sprzedaż i co naprawić w pierwszej kolejności. Wycenę dostajesz na piśmie w 24 h, bez „od X zł”.
Najczęstsze pytania
Co to są Core Web Vitals w jednym zdaniu? To trzy miary tego, jak stronę odbiera realny użytkownik: LCP (jak szybko widać główną treść), INP (jak szybko strona reaguje na kliknięcie) i CLS (czy układ nie skacze w trakcie ładowania). Google podaje progi dobrych wyników: 2,5 sekundy dla LCP, 200 milisekund dla INP i 0,1 dla CLS - liczone dla wersji mobilnej.
Czy Core Web Vitals wpływają na pozycję w Google? Tak, są jednym z sygnałów rankingowych, ale nie najważniejszym. Dobre wyniki nie wypchną słabej treści na górę, natomiast złe realnie ciągną w dół - i dodatkowo kosztują klientów, którzy odpadają, zanim strona się ułoży. Traktuję je jako higienę, nie jako sposób na ranking.
Dlaczego PageSpeed Insights pokazuje mi za każdym razem inny wynik? Bo test laboratoryjny to jeden pomiar na symulowanym urządzeniu i naturalnie się waha. Stabilna jest dopiero sekcja z danymi z pola, zbierana od realnych użytkowników z ostatnich 28 dni - i to na nią patrz przy ocenie sklepu. Wynik z laboratorium służy do diagnozy „co naprawić”, nie do chwalenia się liczbą.
Czy da się poprawić Core Web Vitals bez przebudowy sklepu? W większości przypadków tak. Słabe wyniki to zwykle suma kilku rzeczy - ciężkie zdjęcie na pierwszym ekranie, wolna odpowiedź serwera, obrazy bez wymiarów, nadmiar skryptów - a każdą z nich naprawia się osobno, bez ruszania produktów, zamówień i adresów podstron.
Powiązane: Dlaczego sklep WooCommerce wolno działa · Mini-audyt szybkości w PSI