WooCommerce a wydajność serwera – co ma największe znaczenie?

Czasami rzeczywiście tak jest. Równie często problemem okazuje się jedna źle napisana wtyczka, zapchana kolejka zadań, ciężkie zapytania do bazy albo brak sensownego cache. Przeniesienie takiego sklepu na dwa razy droższy hosting może poprawić sytuację, ale nie usuwa przyczyny.

WooCommerce jest bardziej wymagający od zwykłej strony na WordPressie, ponieważ spora część jego działania jest dynamiczna. Karta produktu może zostać zapisana w cache, ale koszyk, płatność, stan magazynowy czy tworzenie zamówienia wymagają już pracy PHP i bazy danych.

Dlatego przy ocenie serwera trzeba patrzeć trochę szerzej niż na liczbę gigabajtów RAM.

Najważniejsze nie jest miejsce na dysku

Sklep może zajmować 20 GB i działać bardzo szybko, a inny mieścić się w 2 GB i zwalniać przy kilku jednoczesnych zamówieniach.

Dużo ważniejsze są dostępne zasoby obliczeniowe: procesor, pamięć, wydajność bazy danych oraz możliwość równoczesnej obsługi wielu żądań PHP.

Każde wejście na dynamiczną stronę uruchamia określoną pracę. WordPress ładuje swój kod, aktywne wtyczki, WooCommerce, pobiera informacje z bazy, wykonuje reguły dotyczące cen, podatków, wysyłki czy użytkownika i dopiero wtedy generuje odpowiedź.

Przy jednej osobie praktycznie każdy hosting sobie z tym poradzi.

Problem pojawia się, gdy w tej samej chwili kilkadziesiąt osób dodaje produkty do koszyka, inni przechodzą przez checkout, marketplace przesyła nowe zamówienia przez API, a w tle trwa aktualizacja stanów magazynowych.

Dlatego sklep, który przez większość tygodnia działa dobrze, może nagle zacząć zwalniać podczas kampanii reklamowej albo dużej promocji.

Liczy się nie tylko miesięczna liczba odwiedzin, ale również ich rozkład. Dziesięć tysięcy wizyt równomiernie rozłożonych w ciągu tygodnia to zupełnie inne obciążenie niż kilka tysięcy osób wchodzących w ciągu godziny na jeden przeceniony produkt.

Cache pomaga bardzo, ale nie przyspieszy wszystkiego

Jedną z najskuteczniejszych metod ograniczenia obciążenia WooCommerce jest cache.

Jeżeli 100 osób otwiera tę samą kategorię produktów, nie ma sensu za każdym razem wykonywać wszystkich zapytań i generować całej strony od początku. Gotowa wersja może zostać podana z pamięci podręcznej.

Taki mechanizm bardzo dobrze sprawdza się na stronie głównej, blogu, kategoriach oraz części kart produktów.

Inaczej wygląda koszyk i checkout.

Te strony zawierają dane konkretnego klienta i muszą pozostawać dynamiczne. Nie można wysłać użytkownikowi zawartości koszyka poprzedniej osoby tylko dlatego, że strona była w cache. Dlatego WooCommerce zaleca wyłączenie z pełnego cache między innymi koszyka, checkoutu oraz konta klienta.

To oznacza, że prawdziwą wydajność serwera najlepiej widać właśnie tam.

Sklep może osiągać świetne wyniki PageSpeed na stronie głównej, a jednocześnie potrzebować kilku sekund na przeliczenie dostawy po wpisaniu kodu pocztowego.

Poza cache całych stron istnieje również persistent object cache, najczęściej oparty na Redisie lub Memcached. Pozwala on przechowywać często używane dane w pamięci zamiast za każdym razem pobierać je z MySQL.

Przy niewielkim sklepie różnica nie zawsze będzie spektakularna. Przy dużym katalogu, wielu zapytaniach i intensywnym panelu administracyjnym potrafi być już wyraźna.

CDN rozwiązuje jeszcze inny problem. Pozwala odciążyć serwer przy przesyłaniu obrazów, CSS, JavaScriptu i innych plików statycznych. Nie sprawi jednak, że wolne zapytanie SQL nagle zacznie działać szybko.

Liczba wtyczek niewiele mówi bez sprawdzenia, co robią

„Masz 50 wtyczek, dlatego WooCommerce jest wolny” brzmi logicznie, ale jest zbyt dużym uproszczeniem.

Dziesięć dobrze napisanych, prostych rozszerzeń może powodować mniejsze obciążenie niż jedna wtyczka wykonująca przy każdym wejściu kilka ciężkich zapytań albo komunikująca się z zewnętrznym API.

Z drugiej strony liczba aktywnych dodatków nie jest całkowicie obojętna. WordPress ładuje aktywne wtyczki podczas obsługi żądań, a część z nich dodaje własne zapytania, skrypty, zadania w tle i tabele.

Szczególnie dobrze warto przyjrzeć się dodatkom odpowiedzialnym za filtry produktów, indywidualne ceny, wielowalutowość, synchronizacje marketplace, integracje ERP, rozbudowane programy lojalnościowe oraz automaty marketingowe.

To nie znaczy, że należy je usuwać. Trzeba tylko wiedzieć, ile kosztuje ich działanie.

Jeżeli po włączeniu jednej wtyczki czas generowania kategorii rośnie z 300 ms do dwóch sekund, zwiększenie pamięci z 2 do 4 GB niekoniecznie będzie najlepszym rozwiązaniem.

Podobnie jest z motywem. Rozbudowany szablon może ładować dodatkowe biblioteki, elementy page buildera i własne zapytania. Z punktu widzenia klienta efekt będzie taki sam: „WooCommerce działa wolno”, chociaż samo WooCommerce nie jest źródłem problemu.

Baza danych zaczyna mieć znaczenie wraz ze wzrostem sklepu

Mały sklep ma kilkaset produktów i kilka tysięcy zamówień. Po kilku latach może mieć dziesiątki tysięcy produktów, wariantów, klientów, kuponów i setki tysięcy zamówień.

Ta historia pozostaje w bazie.

Właśnie dlatego WooCommerce wprowadził HPOS, czyli High-Performance Order Storage. Zamiast przechowywać dane zamówień razem z dużą częścią pozostałych danych WordPressa w tabelach posts i postmeta, HPOS wykorzystuje oddzielne tabele zoptymalizowane pod zamówienia.

Dla nowych instalacji HPOS jest standardem. W starszych sklepach warto sprawdzić, czy jest już używany. Przed migracją trzeba jednak upewnić się, że wszystkie kluczowe rozszerzenia są z nim zgodne.

Nie należy również zapominać o samej bazie.

Po latach potrafią pozostać w niej stare dane po usuniętych wtyczkach, duże ilości logów, sesje, transienty albo nadmiernie rozrośnięte opcje ładowane przy każdym żądaniu.

Nie oznacza to, że trzeba raz w miesiącu uruchamiać przypadkową wtyczkę „Database Optimizer” i usuwać wszystko, co uzna za niepotrzebne. Przy sklepie produkcyjnym lepiej najpierw ustalić, które tabele rzeczywiście są duże i jakie zapytania zajmują czas.

Czasami kilka minut analizy bazy daje więcej niż zmiana całego serwera.

Zadania w tle potrafią przeciążyć sklep, choć klient ich nie widzi

WooCommerce wykonuje wiele operacji bez udziału użytkownika.

Aktualizacje, webhooks, odnawianie subskrypcji, wysyłka wiadomości, synchronizacje, przetwarzanie importów czy działania niektórych rozszerzeń mogą korzystać z WP-Cron i Action Scheduler.

Normalnie klient tego nie zauważa.

Problem zaczyna się, gdy w kolejce pojawiają się tysiące oczekujących albo nieudanych zadań. Sklep może wtedy zużywać zasoby na nadrabianie pracy w tle, a równocześnie obsługiwać osoby robiące zakupy.

W panelu WooCommerce można sprawdzić zaplanowane akcje. Jeżeli kolejka stale rośnie, a stare zadania nie są wykonywane, warto znaleźć przyczynę zamiast jedynie zwiększać parametry hostingu.

Przy aktywnych sklepach sensowne jest również prawidłowe skonfigurowanie crona po stronie serwera zamiast polegania wyłącznie na wywołaniach WP-Cron związanych z wizytami użytkowników.

Ma to szczególne znaczenie przy integracjach.

Wyobraźmy sobie sklep synchronizujący zamówienia z systemem magazynowym, programem do faktur, kurierem i marketplace. Klient może zobaczyć normalnie działającą stronę, a w tle rośnie kolejka niewysłanych webhooków. Kilka godzin później okazuje się, że zamówienia nie trafiły do ERP albo faktury nie zostały utworzone.

To także jest problem wydajnościowy, choć nie objawia się wolnym ładowaniem strony.

Obrazy mogą spowolnić stronę bez przeciążania PHP

Nie każdy problem z szybkością WooCommerce leży po stronie serwera aplikacyjnego.

Jeżeli karta produktu ładuje sześć zdjęć po 4 MB, klient będzie długo czekał nawet przy bardzo szybkim PHP i bazie.

Zdjęcia powinny być odpowiednio skalowane i kompresowane. Przy dużej liczbie grafik pomaga CDN, nowoczesne formaty plików i lazy loading.

Podobnie z JavaScriptem.

Widget czatu, tracking kilku systemów reklamowych, mapy, narzędzie do personalizacji, popup, system rekomendacji i zewnętrzne opinie mogą wygenerować sporą ilość kodu uruchamianego już w przeglądarce klienta.

W tej sytuacji kupienie większego serwera niewiele zmieni.

Dlatego trzeba rozdzielić dwa problemy: jak szybko serwer generuje odpowiedź oraz jak szybko gotowa strona ładuje się i zaczyna reagować w przeglądarce.

Od czego zacząć, gdy sklep zwalnia?

Najpierw od pomiaru, nie od migracji hostingu.

Dobrze ustalić:

Dopiero później wiadomo, w którą stronę iść.

Jeżeli procesor regularnie osiąga limit podczas normalnego ruchu, mocniejszy serwer może być właściwą odpowiedzią. Jeśli stronę obciąża jedno zapytanie trwające trzy sekundy, najpierw należy poprawić zapytanie. Gdy problemem jest kilkadziesiąt megabajtów grafik, potrzeba optymalizacji obrazów i CDN, a nie kolejnych rdzeni CPU.

Przy większych sklepach pomocne jest monitorowanie aplikacji, które pokazuje czas wykonywania zapytań, kod poszczególnych wtyczek oraz zewnętrzne połączenia API. Dzięki temu diagnoza przestaje opierać się na zasadzie „wydaje mi się, że serwer jest za słaby”.

WooCommerce może obsługiwać bardzo duże sklepy, ale skala wymaga odpowiednio przygotowanej infrastruktury. Dobrze skonfigurowany cache, współczesne PHP, szybka baza, HPOS, kontrolowana liczba ciężkich rozszerzeń i sprawnie działające zadania w tle potrafią zrobić większą różnicę niż samo przejście na droższy pakiet hostingowy.

Serwer ma znaczenie. Tyle że jest jednym z elementów całego systemu, a nie uniwersalnym rozwiązaniem każdego problemu z szybkością sklepu.