Wydajność i bezpieczeństwo

Przyspieszenie WooCommerce: najczęstsze przyczyny wolnego panelu

· Krzysztof Balicki

Mały ślimak na klawiaturze laptopa

Panel WooCommerce zamula? Najczęściej winna jest przeciążona baza danych (autoload opcji, transienty, tysiące starych zamówień), ciężkie wtyczki albo zadania mielone w tle. Słaby hosting to rzadszy przypadek. Dlatego przyspieszenie WooCommerce na zapleczu zaczynam od diagnozy, a nie od kolejnej wtyczki cache, która zalogowanego admina i tak omija. Poniżej po kolei: jak sprawdzić przyczyny, zanim zapłacisz za mocniejszy serwer.

Dlaczego cache nie pomoże, gdy wolny jest panel, a nie sklep?

Bo to działa zupełnie inaczej. Cache stron wysyła odwiedzającym gotowy HTML. Panel administracyjny za każdym razem składa się od zera z kodu PHP i zapytań do bazy. Wolny sklep od strony klienta i ociężałe zaplecze to więc dwa osobne problemy, z innymi przyczynami i inną diagnozą. Zaplecze przyspieszają w sumie trzy rzeczy: mniej zapytań, lżejsza baza i mniej kodu ładowanego na każdej podstronie. Tyle. Ale zanim cokolwiek ruszysz, zmierz, co dokładnie trwa tak długo.

Jak zmierzyć, co spowalnia panel WooCommerce?

Musisz zobaczyć zapytania do bazy, hooki i żądania HTTP, które odpalają się przy ładowaniu konkretnego ekranu. Najprościej zrobić to wtyczką w rodzaju Query Monitor - pokazuje czas każdego zapytania i wtyczkę, z której ono pochodzi. Do tego Narzędzia > Stan witryny, logi serwera i slow query log w MySQL (czyli dziennik zapytań, które przekraczają ustalony próg czasu).

Testuj zawsze te same ekrany:

  • listę zamówień i jej wyszukiwarkę,
  • edycję produktu,
  • kokpit z widżetami,
  • raporty i analitykę.

Dobrze trzymać się zasady z zaleceń wydajnościowych WooCommerce dla deweloperów: porównuj sklep z danym rozszerzeniem włączonym i wyłączonym. Inaczej jego realnego wpływu po prostu nie zobaczysz.

Autoload opcji WordPress: ukryty balast w każdym żądaniu

Opcje z flagą autoload WordPress wczytuje przy każdym żądaniu. Każdym. Więc rozdęta tabela wp_options ciągnie w dół cały panel. Skąd ten balast? Z wtyczek usuniętych bez sprzątania, z logów i danych upchniętych w opcjach, no i z przeterminowanych transientów (to tymczasowe wpisy z datą ważności, które nie zawsze same znikają). Łączny rozmiar danych autoload i listę największych opcji wyciągniesz prostym zapytaniem SQL, część informacji jest też w Stanie witryny. Zanim zmienisz flagę, ustal, która wtyczka tworzy daną opcję, i zrób kopię bazy. Bez tego ani rusz.

Optymalizacja bazy WooCommerce: zamówienia, sesje i tabele metadanych

Tysiące zamówień i ich metadanych w wp_postmeta - to klasyczny powód, dla którego lista zamówień i wyszukiwarka chodzą jak żółw. Ulgę daje HPOS, czyli trzymanie zamówień w osobnych, dedykowanych tabelach zamiast w wp_posts i wp_postmeta. Tylko uwaga: przed przełączeniem sprawdź, czy wszystkie używane wtyczki deklarują zgodność z tym trybem.

Regularnie czyść też wygasłe sesje klientów, stare wpisy Action Scheduler, nadmiar rewizji i osierocone metadane. Aha, i zajrzyj do tabel, które zakładają wtyczki. Rozrośnięte logi bez indeksów potrafią spowolnić zapytania bardziej niż same zamówienia (i mało kto tam w ogóle patrzy).

Wtyczki, które obciążają zaplecze, i jak je wskazać

Z reguły panel dławi jedna, góra dwie wtyczki, które robią coś ciężkiego na każdej stronie admina. Po czym je poznać? Po zewnętrznych żądaniach HTTP do serwerów licencji albo API, po rozbudowanych widżetach w kokpicie i po powiadomieniach odpytywanych przy każdym przeładowaniu. Winowajcę najpewniej znajdziesz na kopii stagingowej: wyłączasz dodatki pojedynczo i porównujesz czas ładowania tych samych ekranów. Nudne, ale działa. Dobrze napisana wtyczka ładuje swój kod tylko tam, gdzie jest potrzebny, a przy rozszerzeniach z K4.pl masz aktualizacje i wsparcie, więc problem z wydajnością można po prostu zgłosić autorom.

Zadania w tle, Heartbeat i środowisko serwera

Zaległa kolejka zadań i ciągłe odpytywanie serwera zjadają zasoby, z których korzysta panel. Zajrzyj do WooCommerce > Stan > Zaplanowane działania i sprawdź, czy Action Scheduler nie zbiera zaległych albo nieudanych akcji. Dalej: WP-Cron odpalany ruchem na stronie zamiast prawdziwego crona serwera. I Heartbeat API, które potrafi pukać do serwera zdecydowanie za często. Wersję PHP, limit pamięci i cache obiektów (Redis lub Memcached) zostaw na koniec, kiedy baza i wtyczki są już ogarnięte.

Kolejność działań przy przyspieszeniu WooCommerce w panelu

Najpierw pomiar. Potem baza i autoload, następnie wtyczki, serwer na samym końcu. Dzięki temu widzisz efekt każdej zmiany osobno:

  1. Zrób kopię bazy i plików, przygotuj środowisko stagingowe.
  2. Zmierz czas ładowania wybranych ekranów panelu.
  3. Uporządkuj autoload i przeterminowane transienty.
  4. Posprzątaj zamówienia, sesje i kolejkę Action Scheduler.
  5. Przetestuj wtyczki, wyłączając je pojedynczo.
  6. Dopracuj konfigurację serwera: PHP, pamięć, cache obiektów, cron.
  7. Powtórz pomiar na tych samych ekranach.

Przyspieszenie WooCommerce to nie jednorazowa instalacja kolejnego narzędzia, tylko diagnoza, którą moim zdaniem warto powtarzać po każdej większej aktualizacji albo nowym dodatku i przed sezonem Black Friday.

Najczęstsze pytania

Czy wtyczka cache przyspieszy panel administracyjny WooCommerce?

Zwykle nie. Zalogowani użytkownicy omijają cache stron i dostają panel generowany na bieżąco. Zapleczu pomoże raczej cache obiektów, który trzyma wyniki zapytań w pamięci, plus lżejsza baza. Wtyczka cache przyda się za to sklepowi, który widzą klienci.

Czy mogę bezpiecznie wyłączyć autoload dużych opcji?

Tak, ale dopiero gdy wiesz, która wtyczka tworzy daną opcję i czy faktycznie potrzebuje jej przy każdym żądaniu. Kopia bazy przed zmianą, a całość najpierw na stagingu. Jak coś się posypie, przywracasz flagę i sklep nawet tego nie zauważy.

Kiedy wolny panel oznacza, że trzeba zmienić hosting?

Wtedy, gdy po uporządkowaniu bazy, autoloadu i wtyczek pomiary nadal pokazują długi czas odpowiedzi serwera przy niewielkiej liczbie zapytań. To sygnał, że ograniczeniem jest moc obliczeniowa, konfiguracja PHP albo baza danych po stronie dostawcy. Wcześniej? Przeprowadzka na inny hosting zwykle przenosi problem w nowe miejsce i tyle.