Gdy WooCommerce działa wolno, przyczyna prawie nigdy nie jest jedna - to zwykle suma kilku rzeczy, które nakładają się na siebie. W e-commerce każda sekunda opóźnienia to realnie mniej koszyków i niższa pozycja w wyszukiwarce. Dobra wiadomość: w większości przypadków wolny WooCommerce da się naprawić bez budowy sklepu od nowa.
Poniżej rozkładam na czynniki pierwsze najczęstsze przyczyny, które widzę u klientów - od tych najbardziej oczywistych po te, które wychodzą dopiero pod maską.
Tani, współdzielony hosting
To przyczyna numer jeden. WooCommerce jest dynamiczny - każda strona koszyka, konta i checkoutu liczy się na żywo, a nie serwuje z gotowego pliku. Na współdzielonym hostingu za 10 zł miesięcznie dzielisz procesor i pamięć z setkami innych stron. Gdy sąsiad ma ruch, Twój sklep zwalnia.
Co pomaga: hosting z realnym SSD/NVMe, PHP 8.1+ i wystarczającą pamięcią (minimum 256-512 MB na proces), najlepiej dedykowany pod WordPress/WooCommerce. To zwykle najtańszy skok wydajności na złotówkę.
Za dużo wtyczek (i wtyczki źle napisane)
Nie chodzi o samą liczbę, tylko o to, co wtyczki robią na każdej stronie. Jedna źle napisana wtyczka
- ładująca własny CSS i JavaScript na całej witrynie, odpytująca bazę przy każdym wejściu - potrafi spowolnić sklep bardziej niż dwadzieścia lekkich. Klasyczni winowajcy: rozbudowane buildery stron, slidery, „page speed” wtyczki, które same dokładają narzut, oraz wtyczki marketingowe ładujące zewnętrzne skrypty.
Co pomaga: audyt wtyczek pod kątem realnego wpływu (narzędzie Query Monitor pokazuje, która wtyczka ile czasu zjada), usunięcie zbędnych i zastąpienie ciężkich lżejszymi odpowiednikami.
Brak cache - albo źle skonfigurowany
Bez cache WordPress generuje każdą stronę od zera przy każdym wejściu. Cache stron (page cache) serwuje gotowy HTML i to często najszybszy efekt „od ręki”. Problem w tym, że WooCommerce ma strony, których cache’ować nie wolno - koszyk, checkout, konto - i tu wiele konfiguracji albo nie cache’uje nic, albo cache’uje za dużo i klientom miesza się zawartość koszyka.
Co pomaga: dobry plugin cache (np. z poprawną obsługą wyjątków WooCommerce), cache obiektów (Redis) dla zapytań do bazy oraz OPcache po stronie PHP.
Ciężkie, nieoptymalne obrazy
Sklep to zdjęcia produktów - i to one najczęściej ważą najwięcej. Wgrane prosto z aparatu zdjęcie ma 4-6 MB, a w katalogu są ich setki. Przeglądarka musi to wszystko pobrać.
Co pomaga: kompresja i format nowej generacji (WebP/AVIF), serwowanie obrazów w rozmiarze, w jakim faktycznie się wyświetlają, oraz leniwe ładowanie (lazy loading) tego, co jest poniżej pierwszego ekranu.
Rozrośnięta baza danych
Z czasem baza WooCommerce puchnie: nieusuwane wersje wpisów (revisions), wygasłe transienty, logi wtyczek, porzucone koszyki, stare sesje. Każde zapytanie do takiej bazy trwa dłużej.
Co pomaga: porządki w bazie, czyszczenie transientów, indeksy na tabelach, a przy dużych katalogach - przeniesienie sesji i koszyków poza główne tabele.
Specyfika samego WooCommerce
Są też rzeczy typowe dla WooCommerce, które łatwo przeoczyć: „cart fragments” (skrypt odświeżający koszyk przez AJAX na każdej podstronie), brak wyłączenia zbędnych skryptów na stronach, gdzie nie ma koszyka, oraz motywy ładujące cały framework CSS dla jednego przycisku.
Co pomaga: wyłączenie cart fragments tam, gdzie nie są potrzebne, warunkowe ładowanie skryptów WooCommerce i motyw napisany pod wydajność, a nie pod „1000 funkcji w demie”. Ten sam mechanizm potrafi też zjadać koszyki na checkoucie - piszę o tym szerzej w tekście o porzuconych koszykach WooCommerce.
Jak sprawdzić, co konkretnie spowalnia Twój sklep
Zanim cokolwiek zmienisz, zmierz. Inaczej strzelasz na ślepo:
- PageSpeed Insights - pokazuje Core Web Vitals (LCP, INP, CLS) i konkretne rekomendacje dla Twojego adresu, osobno dla telefonu i komputera.
- Query Monitor (wtyczka dev) - pokazuje, które zapytania do bazy i które wtyczki zjadają czas generowania strony.
- Waterfall w narzędziach przeglądarki (zakładka Network) - widać, co i w jakiej kolejności się ładuje oraz co blokuje render.
Dopiero z tymi liczbami wiadomo, czy problem jest w hostingu, we wtyczkach, w obrazach czy w bazie - i co naprawić najpierw, żeby uzyskać największy efekt najmniejszym kosztem. Krok po kroku, gdzie dokładnie kliknąć i co odczytać, rozpisałem w osobnym tekście o tym, jak sprawdzić szybkość sklepu.
Sklep WooCommerce zwolnił z dnia na dzień - po aktualizacji albo po nowej wtyczce
Inaczej podchodzę do sklepu, który mulił od zawsze, a inaczej do takiego, w którym WooCommerce wolno działa dopiero od kilku dni. Nagłe zwolnienie ma zwykle jedną przyczynę i jedną datę: aktualizację wtyczki albo motywu, nową wtyczkę marketingową, zmianę ustawień cache po aktualizacji WordPressa. Zamiast od razu szukać nowego hostingu, cofam się do tej daty.
Kolejność, która działa najszybciej: robię kopię sklepu, pracuję na kopii, a nie na żywym sklepie, i wyłączam po kolei wtyczki dodane albo zaktualizowane w ostatnich dniach, mierząc po każdym kroku czas generowania strony w Query Monitorze. Jeśli po wyłączeniu jednej z nich czas wraca do normy, masz winowajcę i nie potrzebujesz przeprowadzki na inny serwer. Jeśli nie wraca, sprawdzam, czy aktualizacja nie wyłączyła cache i czy hosting nie przestawił PHP na starszą wersję - to drugie widać po tym, że wolniej odpowiadają wszystkie podstrony naraz, także te, na których nowa wtyczka nic nie robi.
Dopiero gdy sklep jest równo wolny wszędzie i przy wyłączonych wtyczkach, rozmowa o hostingu ma sens. Migracja wolnego sklepu WooCommerce, gdy dławi go jedna wtyczka, kosztuje kilka dni pracy i niczego nie naprawia - ta sama wtyczka pojedzie na nowy serwer razem z resztą.
Ile to trwa i ile kosztuje: typowy zestaw poprawek, czyli cache, obrazy, porządki w bazie i odchudzenie wtyczek, to godziny pracy rozłożone na kilka dni, nie tygodnie. Dłużej robi się dopiero wtedy, gdy trzeba ruszyć motyw albo przenieść sklep na inny serwer. Sam przegląd, po którym wiadomo, co dławi konkretny sklep, robię na start - tak wygląda rozwój i optymalizacja istniejących sklepów u mnie: najpierw pomiar, potem wycena na piśmie z rozpisanym zakresem, dopiero potem robota.
Czy trzeba budować sklep od nowa?
Zwykle nie. W większości przypadków wolny WooCommerce to suma kilku z powyższych przyczyn, a nie „zły sklep”. Uporządkowanie hostingu, cache, obrazów i wtyczek potrafi zbić czas ładowania kilkukrotnie
- bez utraty produktów, zamówień i pozycji w Google. Pełną przebudowę warto rozważyć dopiero, gdy motyw lub fundament są na tyle przestarzałe, że łatanie kosztuje więcej niż solidny redesign - o tym, kiedy wystarczy redesign, a kiedy faktycznie trzeba przebudowy od zera, piszę osobno w tekście o redesignie sklepu bez przebudowy. Ile dokładnie kosztuje samo uporządkowanie hostingu, cache i obrazów, zależy od tego, co konkretnie trzeba ruszyć - rozpisałem to w tekście o tym, ile kosztuje przyspieszenie sklepu.
Najczęstsze pytania
Jak szybko powinien ładować się sklep WooCommerce? Punktem odniesienia jest próg Google dla wersji mobilnej: główna treść pierwszego ekranu powinna pojawić się w 2,5 sekundy. Powyżej 4 sekund jesteś w strefie, w której klienci zaczynają wychodzić, zanim cokolwiek zobaczą. Mierz to zawsze na telefonie i na danych komórkowych, bo test na biurowym wifi prawie zawsze kłamie na plus.
Czy sama zmiana hostingu przyspieszy sklep? Często pomaga najbardziej ze wszystkich pojedynczych zmian, ale rzadko wystarcza. Lepszy serwer skraca czas pierwszej odpowiedzi, natomiast ciężkie zdjęcia, brak cache i wtyczki ładujące własny kod na każdej podstronie pojadą z Tobą na nowy hosting bez zmian. Kolejność, która się sprawdza: najpierw pomiar, potem hosting i cache, potem obrazy i wtyczki.
Czy wtyczka do optymalizacji załatwi sprawę? Częściowo. Dobra wtyczka cache potrafi dać duży skok od ręki, ale w WooCommerce musi mieć poprawnie ustawione wyjątki dla koszyka, checkoutu i konta - inaczej klientom miesza się zawartość koszyka. Wtyczki, które obiecują „przyspieszenie jednym kliknięciem”, potrafią też same dokładać narzut, więc po instalacji zawsze mierzę wynik przed i po.
Czy przyspieszanie sklepu grozi utratą zamówień albo zmianą wyglądu? Nie, jeśli robi się to po kolei i z kopią zapasową przed każdą większą zmianą. Optymalizacja dotyka ustawień serwera, cache, obrazów i skryptów - nie treści, produktów ani bazy zamówień. Wygląd zostaje ten sam; zmienia się tylko to, jak szybko się pokazuje.
Masz to u siebie i nie wiesz, od czego zacząć? Przyspieszam i naprawiam istniejące strony i sklepy - Core Web Vitals, awarie, rozbudowa o funkcje, których brakuje. Porozmawiajmy o projekcie.