Dlaczego sklep WooCommerce może działać wolno - i czemu zmiana platformy często nic nie daje

Piękny zimowy dzień.
Za oknem klasyczny widok współczesnej zimy: topniejące resztki śniegu, szary poranek, nic specjalnego. Sobota.
Nie trzeba się spieszyć. Dzieci jeszcze śpią. Przez chwilę można udawać, że weekend faktycznie jest weekendem.

I wtedy telefon.

— Adam, ja mam już dość. Zmieńmy WooCommerce na coś innego.
Do tego kilka epitetów, żeby było jasne, że to nie jest luźna sugestia, tylko stan emocjonalny.

— Rafał, spokojnie. Co się dzieje?
— (epitet, epitet) Działa tak wolno, że nic się nie da zrobić.

Sprawdzam u siebie.
I faktycznie, tym razem ciężko powiedzieć “u mnie działa”. Panel administracyjny ledwo żyje, sklep reaguje z opóźnieniem, choć dzień wcześniej wszystko działało normalnie.

Idealnie.
Nie ma to jak awaria w weekend.

Sielanka: terminated.

To nie był pierwszy taki telefon ale był jednym z tych, które najlepiej pokazują, jak łatwo źle zdiagnozować problem.

Pierwszy podejrzany… platforma (w tym wypadku WooCommerce).

W większości takich sytuacji podejrzenie zawsze pada na platformę.
To ona jest najbliżej klienta.
Na niej pracujesz, dodajesz produkty, obsługujesz zamówienia.
Jeśli coś działa wolno, to właśnie ona dostaje pierwszą kombinację uderzeń.

Problem w tym, że platforma bardzo często jest tylko miejscem, w którym widać objawy, a nie źródło problemu.

Trochę jak z samochodem.
Zapala się kontrolka „błąd silnika” i wszystko sugeruje: silnik.

A przyczyna?
Czasem czujnik. Czasem przecięty, bądź pęknięty kabel. Czasem coś, czego w ogóle nie widać bez zajrzenia głębiej.

Z WooCommerce (i każdą inną platformą) jest dokładnie tak samo.
Może być częścią problemu - ale rzadko bywa jedynym powodem.

Zanim zaczęliśmy cokolwiek zmieniać, trzeba było odpowiedzieć na jedno pytanie: czy to naprawdę problem platformy, czy tylko miejsce, w którym problem się objawia?

W takich momentach najłatwiej jest (teoretycznie) „uciec do nowej platformy”. Trudniej zatrzymać się i sprawdzić, co faktycznie nie działa. Zwłaszcza, że migracja przy zachowaniu pełnej funkcjonalności i szablonu (robionego na potrzeby sklepu) to ogrom pracy i strat czasu.

Test prawdy jak sprawdzić, gdzie naprawdę leży problem.

W pewnym momencie trzeba przestać zgadywać i oddzielić emocje od faktów.
Pytanie nie brzmiało już czy WooCommerce jest wolny, tylko: czy to w ogóle problem WooCommerce, czy coś znacznie głębiej?

Najprostszy sposób, to odizolować platformę od reszty systemu.

W tym przypadku takim testem była próba wczytania strony logowania. Dlatego, że ta strona jest „lekka” w rozumieniu obciążenia, bez produktów, koszyka, stony zamówienia oraz innych elementów, które wymagają zaangażowania serwera, ale wciąż angażująca go na tyle, żeby zobaczyć, jak reaguje.

I wtedy wszystko stało się jasne. Strona logowania wczytywała się w tempie rosnących pieniędzy na obecnych lokatach. Ergo: dobrze nie jest.

Dlaczego akurat strona logowania to dobry test funkcjonowania www?

Strona logowania ma jedną dużą zaletę: ogranicza funkcjonalność do absolutnego minimum.

Jest to strona dynamiczna, wymagająca uruchomienia interpretera PHP po stronie serwera, ale w bardzo ograniczonym zakresie.  Nie ma tu odczytu setek produktów, koszyka ani integracji zewnętrznych.  Liczba zapytań do bazy jest niewielka, a logika prosta.

Dzięki temu serwer jest zaangażowany na tyle, aby sprawdzić jego realną kondycję, ale nie na tyle, by obciążyć go dodatkową logiką sklepu.

Jeśli w takim scenariuszu odpowiedź serwera jest wolna, to jasny sygnał, że problem leży poniżej poziomu platformy.

To jeden z najszybszych sposobów, by odróżnić czy problem leży po stronie aplikacji czy po stronie infrastruktury.

Co faktycznie spowalniało sklep?

Gdy pierwsze testy wykluczyły platformę jako główną przyczynę, kolejnym krokiem było równoległe działanie na dwóch poziomach.

Z jednej strony problem został zgłoszony do administratorów serwera, którzy mają pełny wgląd w procesy PHP, bazę danych i obciążenie infrastruktury.
Z drugiej w trakcie oczekiwania na ich analizę - zaczęliśmy sprawdzać wszystko, co mogło dokładać się do problemu po stronie samego sklepu.

Proces zaczął się od porządków: wyłączenia niepotrzebnych wtyczek i sprawdzenia, jak zachowuje się aplikacja bez dodatkowej logiki.

Równolegle przeanalizowaliśmy zapytania po stronie przeglądarki (zakładka Network), żeby zobaczyć, które elementy są faktycznie „ciężkie”.

W trakcie tej analizy wyszło kilka rzeczy, które nie były idealne: 

• niezoptymalizowane obrazy w sliderze ( za duże i w złym formacie) i skrypty z wtyczek wysyłające zbędne zapytania, czyli elementy, które przy stabilnym serwerze byłyby niezauważalne, ale w czasie problemów tylko pogarszały sytuację,
• nieaktualne wtyczki które mogły powodować ryzyko bezpieczeństwa.

Aktualizacje wtyczek jako element higieny technicznej.

W trakcie porządkowania sytuacji pojawił się jeszcze jeden, często pomijany aspekt: aktualizacje.

Warto to jasno rozdzielić. Aktualizowanie wtyczek nie było rozwiązaniem problemu wydajnościowego. Nie „naprawiło” zapętlonych procesów PHP ani nie przyspieszyło odpowiedzi serwera.

Było jednak elementem higieny technicznej, o którą warto dbać niezależnie od bieżących problemów.

Aktualne wersje wtyczek to:

• poprawki błędów, które mogą powodować nieoczywiste problemy w tle,
• lepsza kompatybilność z aktualną wersją WordPress i WooCommerce,
• mniejsze ryzyko konfliktów i nieprzewidywalnych zachowań aplikacji.

W tym przypadku część rozszerzeń była aktualizowana przy okazji prac porządkowych  nie jako „optymalizacja”, ale jako profilaktyka, która ułatwia dalszą diagnostykę i stabilizację systemu.

Jeśli interesuje Cię ten temat szerzej, opisaliśmy go dokładniej w osobnym materiale o tym, dlaczego regularne aktualizacje wtyczek są elementem stabilności sklepu, a nie tylko obowiązkiem bezpieczeństwa. 

Rozwiązanie problemu.

Po mojej stronie w międzyczasie wykonywane były wszystkie prace porządkowe i diagnostyczne po stronie sklepu.

Równolegle temat trafił do administratorów serwera, którzy mieli pełny wgląd w procesy PHP i zachowanie infrastruktury.

Po chwili przyszła odpowiedź:

„Dziękujemy za zgłoszenie. Przepraszamy za utrudnienia. Problemem wydajności były zapętlone procesy PHP. Sytuacja została opanowana.”

I to był moment, który najlepiej pokazał, dlaczego zmiana platformy nie miała sensu.

Problem nie leżał w WooCommerce, nie leżał w szablonie ani w funkcjonalnościach sklepu. Leżał w zapętlonych procesach PHP czyli czymś, co może wydarzyć się w każdym systemie opartym o PHP, niezależnie od tego, czy mówimy o WooCommerce, innym CMS-ie czy rozwiązaniu szytym na miarę.

Emocjonalna decyzja o migracji zakończyłaby się dokładnie w tym samym miejscu z tym samym problemem, tylko na innej platformie.

Wnioski

Ta sytuacja była dobrym przypomnieniem, że w e-commerce najdroższe nie są błędy techniczne, tylko błędne diagnozy.

Gdy sklep działa wolno, naturalnym odruchem jest obwinienie platformy. Jest najbliżej użytkownika, na niej pracujemy na co dzień i to ona „dostaje pierwsza”. Problem w tym, że bardzo często platforma jest tylko miejscem, w którym widać objawy, a nie ich źródłem.

W tym przypadku kluczowe okazały się trzy rzeczy:

1. Infrastruktura.
   Zapętlone procesy PHP były realną przyczyną problemu i nie miały związku z WooCommerce jako platformą.
2. Kolejność działań.
   Zamiast emocjonalnej decyzji o migracji, wykonany został prosty test, który pozwolił odizolować problem i zawęzić obszar poszukiwań.
3. Higiena i przygotowanie gruntu.
   Optymalizacja frontu, porządki we wtyczkach i aktualizacje nie „naprawiły” serwera, ale sprawiły, że po jego ustabilizowaniu sklep działał przewidywalnie i bez dodatkowych obciążeń.

Najważniejsza lekcja jest prosta: zanim zmienisz narzędzie, upewnij się, że wiesz, gdzie naprawdę leży problem.

O autorze.

Od lat związany z szeroko rozumianą informatyką. Pierwszą stronę stworzyłem w liceum, za co otrzymałem wyróżnienie.

Ciągle uczę się, aby dorównać tempu rozwoju nowoczesnych technologii łącząc je z wiedzą o psychologii aby zwiększać skuteczność stron i aplikacji internetowych.