Jak przyspieszyć sklep WooCommerce: Core Web Vitals krok po kroku

Czerwone wyniki w PageSpeed Insights i spadająca sprzedaż z telefonów zwykle mają wspólną przyczynę: sklep ładuje się za wolno i reaguje z opóźnieniem. W WooCommerce te same problemy wracają od sklepu do sklepu, więc da się je usuwać w przewidywalnej kolejności. Poniżej ta kolejność, tak jak ją stosujemy: najpierw pomiar, potem serwer, cache, obrazy i wtyczki, a na końcu granica, za którą zwykła optymalizacja już nie pomaga.

Zmierz, zanim cokolwiek zmienisz

Wiele sklepów „optymalizuje” na ślepo. Ktoś instaluje wtyczkę do cache, wynik w PageSpeed rośnie o kilka punktów i temat uznaje się za zamknięty. Tymczasem Google ocenia sklep na podstawie tego, co dzieje się u prawdziwych użytkowników.

Dane terenowe i laboratoryjne

PageSpeed Insights pokazuje dwa zestawy wyników. Na górze są dane terenowe z raportu CrUX (Chrome User Experience Report), zebrane z przeglądarek realnych klientów przez ostatnie 28 dni. Niżej widać dane laboratoryjne z Lighthouse, czyli pojedynczy test na symulowanym, wolnym telefonie ze słabym łączem.

W wyszukiwarce liczą się terenowe. Laboratoryjne służą do diagnozy, bo pokazują, które pliki i skrypty blokują ładowanie. Przy małym ruchu sekcja terenowa bywa pusta i wtedy zostaje Lighthouse plus własne testy na telefonie.

Drugie miejsce do regularnych odwiedzin to raport Core Web Vitals w Google Search Console. Jak Google używa tych wskaźników w wyszukiwarce, opisuje dokumentacja Google Search Central. Widać w nim, które grupy adresów (na przykład strony produktów) są oznaczone jako „słabe” i która metryka za to odpowiada.

LCP, INP i CLS: co mierzą i jakie mają progi

Google patrzy na 75. percentyl. Sklep przechodzi test, gdy trzy czwarte wizyt mieści się w progach, dlatego pojedynczy dobry wynik na szybkim laptopie nic nie mówi o klientach, którzy wchodzą ze starszych telefonów.

Zapisz wyniki wyjściowe dla trzech typów stron: głównej, kategorii i produktu. Każdą zmianę porównuj z tymi liczbami, nie z pamięcią.

Hosting i PHP: od tego zaczynamy

WooCommerce jest cięższy niż zwykły WordPress. Każde wejście na stronę produktu uruchamia dziesiątki zapytań do bazy, a koszyk i checkout w ogóle nie korzystają z cache. Słabego serwera żadna wtyczka nie nadrobi.

• Wersja PHP. Sklep powinien działać na PHP 8.1 lub nowszym. Różnicę między PHP 7.4 a 8.x widać gołym okiem, a starsze wersje nie dostają już poprawek bezpieczeństwa. Zgodność wtyczek sprawdź przed zmianą, na kopii sklepu.
• OPcache. Trzyma skompilowany kod PHP w pamięci, więc serwer nie parsuje tych samych plików przy każdym żądaniu. Większość hostingów ma go włączonego. Sprawdź to mimo wszystko i zerknij na limit pamięci.
• Serwer WWW. LiteSpeed lub Nginx znoszą ruch lepiej niż klasyczny Apache z mod_php. LiteSpeed ma do tego własną wtyczkę cache, która rozumie WooCommerce.
• Cache obiektowy (Redis lub Memcached). Zapamiętuje wyniki zapytań do bazy między odsłonami, żeby serwer nie liczył ich od nowa. W sklepie z dużą liczbą produktów i wariantów to jedna z najbardziej odczuwalnych zmian, zwłaszcza dla zalogowanych klientów i stron, których nie da się cache'ować.

Sklep stoi na współdzielonym hostingu za kilkanaście złotych miesięcznie? Przeniesienie go na VPS albo na hosting zoptymalizowany pod WordPressa zwróci się szybciej niż kolejna wtyczka.

Czym jest cache strony i co z niego wykluczyć?

Cache strony zapisuje gotowy HTML i serwuje go kolejnym odwiedzającym bez uruchamiania PHP i bazy danych. Na stronie głównej, w kategoriach i na produktach daje największą pojedynczą oszczędność czasu odpowiedzi serwera (TTFB, czyli tego, jak długo przeglądarka czeka na pierwszy bajt), a więc i LCP.

Sklep ma jednak strony, których cache'ować nie wolno: koszyk, zamówienie, moje konto. Inaczej jeden klient zobaczy koszyk drugiego. Dobre wtyczki (LiteSpeed Cache, WP Rocket, FlyingPress) wykrywają WooCommerce i same wykluczają te adresy. Po konfiguracji i tak sprawdź to ręcznie: w oknie prywatnym dodaj produkt do koszyka i zobacz, czy licznik w nagłówku pokazuje właściwą liczbę.

Druga pułapka to ciasteczka sesji. WooCommerce ustawia je w chwili dodania czegoś do koszyka i od tego momentu większość wtyczek omija cache dla tego użytkownika aż do końca wizyty. Tak ma być. Tyle że klient z produktem w koszyku chodzi wtedy po wolnym sklepie, więc hosting i PHP z poprzedniej sekcji ważą tu jeszcze więcej.

Czy sklep potrzebuje CDN?

Jeśli sprzedajesz za granicę, tak, to konieczność. CDN (Content Delivery Network) serwuje pliki statyczne, czyli obrazy, CSS, JS i fonty, z serwera położonego najbliżej użytkownika. Przy sprzedaży tylko w Polsce i serwerze w Polsce sama geografia daje niewiele. CDN robi jednak dwie inne rzeczy: zdejmuje z serwera obsługę plików statycznych, a w wydaniu Cloudflare czy Bunny potrafi w locie zmieniać rozmiar i format obrazów. Uważaj na cache'owanie HTML na poziomie CDN. Koszyk i konto trzeba tam wykluczyć tak samo jak w cache serwera.

Obrazy: zwykle największy pojedynczy problem

W typowym sklepie zdjęcia produktów to większość przesyłanych danych. Tu najczęściej leży przyczyna złego LCP.

• Format. Serwuj WebP, a jeśli serwer i wtyczka to obsługują, AVIF. Oba formaty przy podobnej jakości ważą mniej niż JPG. Konwersję przy przesyłaniu zrobi ShortPixel, Imagify, EWWW albo moduł w LiteSpeed Cache. Oryginał z aparatu w rozmiarze 4000 px nie ma prawa trafić na stronę.
• Wymiary. W siatce kategorii ładuj miniatury. Pełne zdjęcie zmniejszone przez CSS i tak pobiera się w całości. Rozmiary obrazów sprawdzisz w ustawieniach WooCommerce, a po każdej zmianie trzeba uruchomić ich regenerację.
• Lazy loading. Obrazy poza pierwszym ekranem ładuj z opóźnieniem. WordPress robi to domyślnie przez atrybut loading="lazy".
• Obraz LCP bez lazy loadingu. Ten błąd widzimy najczęściej. Główne zdjęcie produktu albo baner na stronie głównej dostaje lazy loading od motywu lub wtyczki, przez co przeglądarka pobiera je na samym końcu. Element LCP powinien mieć loading="eager" i fetchpriority="high". Który to element, PageSpeed Insights pokazuje w sekcji diagnostyki.
• Atrybuty width i height. Każdy obraz powinien mieć zadeklarowane wymiary, żeby przeglądarka zarezerwowała na niego miejsce, zanim plik dotrze. To usuwa większość przesunięć układu (CLS).

Wtyczki i motyw

Każda aktywna wtyczka to kod PHP wykonywany przy każdym żądaniu, a często także dodatkowe pliki CSS i JavaScript na każdej podstronie. Sklep z 60 wtyczkami nie jest rzadkością. Większość z nich jest zbędna.

Które wtyczki wyłączyć?

Najczęściej nieużywane slidery, kilka wtyczek robiących to samo (dwa SEO, dwa cache), wtyczki „statystyk” dublujące Google Analytics i dodatki do page buildera, z którego korzysta jedna podstrona. Żeby znaleźć resztę, przejdź listę i przy każdej pozycji zapytaj: co się stanie, jeśli ją wyłączę? Query Monitor pokaże, które wtyczki generują najwięcej zapytań i zabierają najwięcej czasu.

Czy page builder spowalnia sklep?

Tak. Elementor, WPBakery czy Divi dokładają do każdej strony własne pliki CSS i JS, a generowany przez nie HTML jest kilkukrotnie większy, niż trzeba. Jeśli strona produktu powstała w page builderze, samo przeniesienie jej na natywny szablon motywu albo na bloki Gutenberga często obniża INP i LCP bardziej niż wszystkie wtyczki cache razem wzięte.

Skrypty śledzące i czaty

Google Tag Manager z dziesięcioma tagami, Pixel Meta, Hotjar, czat na żywo, widżet opinii, mapa Google w stopce. Każdy z osobna jest „lekki”. Razem potrafią zająć główny wątek przeglądarki na kilka sekund, a to bezpośrednio psuje INP na telefonach. Ładowanie takich skryptów opóźnia się do pierwszej interakcji użytkownika, czyli przewinięcia albo dotknięcia ekranu; WP Rocket, Perfmatters i FlyingPress mają do tego gotowe opcje. Czat ładuj dopiero po kliknięciu ikony.

Baza danych, koszyk i checkout

Porządek w bazie

Baza sklepu rośnie bez nadzoru. Z czasem każde zapytanie trwa dłużej.

• Transienty. To tymczasowe wpisy w tabeli wp_options, które wtyczki tworzą, ale rzadko po sobie sprzątają. Wygasłe usuniesz wtyczką WP-Optimize albo jednym poleceniem WP-CLI.
• Opcje autoload. Wszystko, co w wp_options ma autoload = yes, ładuje się przy każdym żądaniu, nawet jeśli dana strona tego nie potrzebuje. Gdy suma przekracza 1 MB, sprawdź, które wtyczki zostawiły tam śmieci.
• Logi i sesje. Sesje klientów WooCommerce trzyma w tabeli wc_sessions, a wiele wtyczek (płatności, kurierzy) zapisuje logi w bazie. Ustaw automatyczne czyszczenie, a logi kieruj do plików.
• HPOS (High-Performance Order Storage). Nowsze wersje WooCommerce przechowują zamówienia w osobnych tabelach zamiast w wp_posts i wp_postmeta. Przy dziesiątkach tysięcy zamówień różnicę czuć i w panelu, i w checkoucie. Migrację zrób na kopii, bo starsze wtyczki bywają niezgodne.

Przed każdą ingerencją w bazę zrób kopię.

Koszyk i checkout

Tu optymalizacja dotyka sprzedaży bezpośrednio, więc zwrot z pracy widać najszybciej.

• Fragmenty koszyka. Przy każdym załadowaniu strony WooCommerce wysyła do serwera żądanie (wc-ajax=get_refreshed_fragments), żeby odświeżyć licznik koszyka w nagłówku. Na stronach bez koszyka to zbędne żądanie. Wtyczki optymalizacyjne pozwalają wyłączyć fragmenty poza koszykiem i checkoutem, a na wpisach blogowych zablokować skrypty WooCommerce w całości.
• Blokowanie renderowania. Pliki CSS i JS ładowane w nagłówku strony opóźniają jej wyświetlenie. Wtyczka cache powinna umieć odłożyć JavaScript (defer) i wstawić krytyczny CSS bezpośrednio w kod strony (inline). Po zmianach przejdź cały proces zakupu, bo opóźnione skrypty potrafią popsuć bramkę płatności.
• Checkout bez rozpraszaczy. Na stronie zamówienia nie ładuj sliderów, czatu, popupów z newsletterem ani produktów polecanych. Im mniej na niej jest, tym szybciej działa i tym mniej klientów ją porzuca.

Co, jeśli to nadal za mało?

Bywa, że po przejściu wszystkich punktów sklep wciąż nie mieści się w progach. Zwykle stoi za tym jedna z trzech rzeczy: przestarzały motyw ładuje jQuery z dziesiątkami dodatków, główne funkcje sklepu zależą od ciężkiego page buildera albo katalog ma tysiące wariantów i filtry, których WooCommerce nie udźwignie bez przebudowy zapytań.

Zostają wtedy dwie drogi. Pierwsza to headless: WooCommerce zostaje zapleczem (produkty, zamówienia, płatności), a front powstaje od nowa jako szybka aplikacja, która pobiera dane przez API. Masz wtedy pełną kontrolę nad tym, co trafia do przeglądarki, i zwykle Core Web Vitals w zieleni bez walki. Tak budujemy sklepy headless w Mobitry. Jak działa taki podział na zaplecze i front, opisujemy w tekście o headless WordPressie. Druga droga to zmiana platformy. Większy projekt, który ma sens, gdy problem leży nie tylko w wydajności.

Które podejście pasuje do konkretnego sklepu, rozstrzyga dopiero audyt wydajności z realnymi danymi terenowymi i profilem serwera. Sam wynik Lighthouse tego nie powie. Bez audytu łatwo zapłacić za przebudowę, której nie trzeba było robić.

Od czego zacząć? Kolejność według opłacalności

1. Zmierz: zapisz dane terenowe z PageSpeed Insights i raport Core Web Vitals z Search Console dla strony głównej, kategorii i produktu.
2. Sprawdź wersję PHP i OPcache. Na PHP 7.x zaplanuj aktualizację na kopii sklepu.
3. Włącz cache strony z poprawnymi wyjątkami dla koszyka, checkoutu i konta.
4. Napraw obraz LCP: bez lazy loadingu, w WebP, we właściwym rozmiarze, z fetchpriority="high".
5. Dodaj wymiary do wszystkich obrazów i sprawdź, co przesuwa układ (pasek cookies, banery, fonty).
6. Opóźnij skrypty śledzące i czat do pierwszej interakcji.
7. Przejrzyj wtyczki i usuń zbędne. Mierz różnicę po każdej partii.
8. Włącz cache obiektowy Redis, jeśli hosting na to pozwala.
9. Uporządkuj bazę: transienty, autoload, logi, migracja na HPOS.
10. Dopiero potem rozważ CDN i zmianę hostingu, jeśli TTFB nadal przekracza 600–800 ms.

Każdy krok mierz osobno. Po trzech zmianach naraz nie wiesz, która zadziałała, a która tylko dodała ryzyko.

Najczęstsze pytania

Dlaczego sklep ma dobry wynik na komputerze, a zły na telefonie?

Bo PageSpeed Insights testuje wersję mobilną na symulowanym telefonie średniej klasy z wolnym łączem. Każdy nadmiarowy skrypt i każdy za duży obraz kosztuje tam kilka razy więcej niż na laptopie. Do tego na małym ekranie mieści się mniej treści, więc elementem LCP jest zwykle duże zdjęcie. W większości sklepów ruch z telefonów przeważa, dlatego za właściwy uznaj wynik mobilny.

Czy wtyczka cache wystarczy, żeby przyspieszyć WooCommerce?

Nie. Cache strony pomaga tylko tam, gdzie HTML można zapisać i serwować wszystkim tak samo: na stronie głównej, w kategoriach i na produktach, dla niezalogowanych użytkowników. Koszyk, checkout, konto klienta i każda odsłona po dodaniu produktu do koszyka omijają cache i zależą wyłącznie od serwera, PHP, bazy i liczby wtyczek. Cache maskuje problemy, ale ich nie usuwa. Traktuj go jako jeden z kroków.

Jak często sprawdzać Core Web Vitals w sklepie?

Dane terenowe raz w miesiącu, a test laboratoryjny po każdej aktualizacji motywu, WooCommerce lub większej wtyczki. Dane w PageSpeed Insights i Search Console obejmują ostatnie 28 dni, więc efekt zmian widać z opóźnieniem, a miesięczny odstęp wystarcza, żeby zauważyć trend. Aktualizacje z kolei najczęściej cofają wcześniejsze poprawki, dlatego test po nich jest obowiązkowy. Jeśli nikt w zespole tego nie pilnuje, sens ma stałe wsparcie techniczne z umową SLA, które obejmuje aktualizacje i kontrolę wydajności po każdej z nich.

Źródła

• Web Vitals, web.dev (Google): progi i 75. percentyl
• Largest Contentful Paint (LCP), Interaction to Next Paint (INP) i Cumulative Layout Shift (CLS), web.dev
• Core Web Vitals w wyszukiwarce, Google Search Central
• Chrome User Experience Report (CrUX), Chrome for Developers
• PageSpeed Insights, Google