Poradnik diagnozowania wolnego działania panelu administracyjnego

Strona ładuje się odwiedzającym w miarę szybko, ale panel administracyjny wiesza się na pięć, dziesięć, czasem piętnaście sekund? Większość od razu podejrzewa słaby hosting. Tyle że rzadko to jego wina. W ponad połowie przypadków źródłem są zewnętrzne żądania HTTP, mniej więcej co czwarty wynika z błędnej konfiguracji bazy danych, a dopiero reszta to kwestie serwerowe. Poniżej przeprowadzę Cię przez proces od pomiarów po konkretne działania – bez zgadywania i wyłączania wszystkiego na oślep.

Zacznij od pomiaru, a nie od wyłączania

Zamiast dezaktywować wtyczki po kolei i mieć nadzieję, że trafisz, zainstaluj Query Monitor. To darmowe narzędzie, które stało się standardem w diagnostyce WordPressa. Pokazuje wszystko, co wydarzyło się przy ładowaniu strony: zapytania do bazy, wywołania HTTP API, błędy PHP, załadowane skrypty, użycie pamięci i czas wykonania. Nie wymaga konfiguracji – działa od razu po aktywacji.

Od wersji 4 panel został przepisany na Preact – renderuje dane po stronie przeglądarki. Nawet na wolnych stronach narzut narzędzia jest pomijalny, a dane widzi tylko zalogowany administrator. Możesz go bezpiecznie trzymać na produkcji.

Po instalacji spójrz na pasek narzędzi. Zobaczysz liczbę zapytań, czas wykonania i zużycie pamięci. W zdrowym panelu strona generuje się poniżej sekundy, wykonuje od 30 do 80 zapytań do bazy i mieści się w 64 MB pamięci. Przy dwóch sekundach albo więcej masz sygnał, że trzeba kopać głębiej.

Największy winowajca: autoload w tabeli wp_options

Otwórz Query Monitor i przejdź do zakładki zapytań. Pierwsze, co rzuca się w oczy, to zapytanie ładujące opcje z wp_options WHERE autoload = 'yes'. To ono najczęściej generuje największe opóźnienie.

WordPress wczytuje opcje oznaczone jako autoload przy każdym żądaniu – i na froncie, i w panelu administracyjnym. Problem w tym, że pluginom zdarza się pakować do autoload ogromne ilości danych. Transienty, cache page builderów (Elementor, Divi), dane analityczne, sesje WooCommerce – wszystko ląduje w tej tabeli. Podczas jednego z audytów trafiłem na 38 megabajtów autoload w sklepie WooCommerce. Po wyczyszczeniu czas ładowania panelu spadł z 8,3 sekundy do 1,4.

Bezpieczny próg to poniżej 1 MB. Przy 2 MB zaczynasz odczuwać spowolnienie. Powyżej 10 MB to już problem krytyczny.

Jak sprawdzić autoload? Query Monitor pokazuje całkowity rozmiar w panelu środowiska. Możesz też użyć WP-CLI:

wp option list --autoload=on --format=csv | sort -t, -k2 -nr | head -n 20

Wynik pokazuje 20 największych opcji w autoload. Szukaj wpisów powyżej 100 KB – to kandydaci do przestawienia na no. Są wyjątki, których nie ruszasz: siteurl, home, active_plugins, current_theme, permalink_structure, rewrite_rules, cron, wp_user_roles. Resztę można bezpiecznie zmienić.

Zewnętrzne żądania HTTP – gdy wtyczki dzwonią do domu

Teraz sprawdź panel HTTP API Calls w Query Monitor. Jeśli widzisz pięć lub więcej zewnętrznych wywołań, a którekolwiek trwa dłużej niż sekundę – znalazłeś prawdopodobnie główną przyczynę.

Każda wtyczka premium sprawdza licencję na swoim serwerze. SEO tool ładuje dane słów kluczowych, plugin analityczny ściąga raporty na żywo, formularze weryfikują klucze API. Domyślny timeout WordPressa na takie żądania to 5 sekund. Jeśli zewnętrzny serwer odpowiada wolno, blokujesz ładowanie strony na pięć sekund na każde wywołanie.

W praktyce zdarzały się strony z piętnastoma takimi żądaniami na jednym ekranie admina. Każde czeka na odpowiedź, jedno po drugim. Wystarczy jeden sparaliżowany serwer wtyczki, żeby panel stał się bezużyteczny.

Query Monitor oznacza każde wywołanie kolorem czasu. Czerwone, powyżej 1 sekundy, to sygnał alarmowy. Rozwiązanie nie polega na usunięciu wtyczki, tylko na sprawdzeniu, czy jej cache transientowy działa poprawnie. Dobrze napisana wtyczka nie pyta serwera przy każdym odświeżeniu – przechowuje odpowiedź w obiekcie cache na kilka godzin.

Zapytania do bazy i problem N+1

Otwórz panel zapytań w Query Monitor i kliknij zakładkę Queries by Component. Sortuj po czasie. Zobaczysz, która wtyczka generuje najwięcej zapytań.

Są dwa wzorce, które powinny zapalić lampkę ostrzegawczą. Pierwszy: duplikaty – wiele identycznych zapytań, oznaczone na pomarańczowo. To najczęściej problem N+1: pobierasz listę postów (jedno zapytanie), a potem dla każdego z nich osobne zapytanie o metadane. Przy 200 postach to 201 zapytań.

Drugi: zapytania skanujące całe tabele. EXPLAIN w MySQL pokazuje typ ALL – baza przegląda każdy wiersz w tabeli, zamiast skorzystać z indeksu. Dotyczy to szczególnie tabeli wp_postmeta. Wyszukiwanie produktów WooCommerce bez indeksu na meta_value potrafi skanować 150 tysięcy wierszy, żeby zwrócić jeden wynik.

Rozwiązanie: dodanie odpowiednich indeksów. Wystarczą dwa:

ALTER TABLE wp_postmeta ADD INDEX meta_key (meta_key);
ALTER TABLE wp_postmeta ADD INDEX post_id_meta_key (post_id, meta_key);

Dla WooCommerce warto dodać indeks złożony z wartością:

ALTER TABLE wp_postmeta ADD INDEX post_id_meta_key_value (post_id, meta_key, meta_value(10));

Jeśli nie chcesz bawić się w ręczne SQL-e, jest wtyczka Index WP MySQL For Speed – ponad 50 tysięcy aktywnych instalacji. Dodaje indeksy do wszystkich tabel WordPressa, umie je bezpiecznie usunąć i działa w trybie --dryrun, który pokazuje kod SQL bez wykonywania.

Heartbeat API – 240 niepotrzebnych żądań na godzinę

Mechanizm Heartbeat wysyła żądania POST do admin-ajax.php co 15 sekund na ekranie edycji i co 60 sekund na pozostałych stronach panelu. Każde żądanie uruchamia pełną inicjalizację WordPressa, autoryzację i wszystkie callbacki podpięte przez wtyczki. A te callbacki potrafią być zaskakująco kosztowne.

Przykład: heartbeat trwający 4 sekundy przez trzy wtyczki. Na każdej stronie admina, co minutę, przez 4 sekundy jeden PHP-FPM worker jest zajęty obsługą heartbeat. Przy kilku jednocześnie zalogowanych adminach szybko wyczerpujesz pulę workerów. W skali godziny jeden admin generuje 240 żądań heartbeat – każde niecache'owalne, każde wymagające osobnego procesu.

Nie wyłączaj heartbeat całkowicie – w edytorze odpowiada za autozapis i blokadę edycji. Lepiej zmień interwał. Możesz to zrobić przez darmową wtyczkę Heartbeat Control albo przez filtr w kodzie:

add_action('admin_enqueue_scripts', function () {
    global $pagenow;
    if ($pagenow !== 'post.php' && $pagenow !== 'post-new.php') {
        wp_deregister_script('heartbeat');
    }
});

Zalecana konfiguracja: dashboard – interwał 60 sekund, edytor – 30 sekund, frontend – wyłącz. Redukcja wywołań admin-ajax.php sięga 60–75 procent.

Zbędne widgety dashboardu

Panel administracyjny WordPressa ładuje domyślnie kilka widgetów: At a Glance, Activity, Quick Draft, Site Health oraz WordPress Events and News. Ten ostatni pobiera dane z zewnętrznego API przy każdym odświeżeniu strony. Do tego wtyczki dokładają swoje: WooCommerce dashboard, Rank Math z danymi SEO, kolejne ze statystykami.

Każdy widget to zapytanie do bazy, często też wywołanie zewnętrzne i dodatkowy czas ładowania.

Screen Options w prawym górnym rogu pozwala odznaczyć zbędne widgety bez żadnego kodu. Jeśli chcesz zrobić to programowo – dla całego dashboardu lub dla klientów – użyj haka wp_dashboard_setup i funkcji remove_meta_box. Kod umieść w child theme lub w dedykowanej wtyczce site-specific.

Cache obiektowy – Redis

Panel administracyjny jest dynamiczny – żadna wtyczka cache stron go nie przyspieszy. Ale cache obiektowy działa na poziomie aplikacji: przechowuje wyniki zapytań w pamięci RAM, zamiast odpytywać bazę za każdym razem.

Jeśli masz Redis na serwerze (większość zarządzanych hostingów go oferuje), instalacja sprowadza się do aktywacji w panelu hostingu, zainstalowania darmowej wtyczki Redis Object Cache i kliknięcia Enable Object Cache. Strona, która wymagała 40 zapytań do bazy, przy ciepłym cache potrzebuje ich zaledwie kilka. Różnica jest szczególnie widoczna w WooCommerce i przy dużej liczbie niestandardowych typów postów.

Wersja PHP i rzeczy do sprawdzenia od ręki

Każda nowa wersja PHP jest szybsza od poprzedniej. Przejście z PHP 7.4 na 8.2 daje od 25 do 35 procent poprawy wydajności – bez żadnych zmian w kodzie i bez instalowania wtyczek. PHP 7.4 zakończyło wsparcie w listopadzie 2022. Jeśli wciąż na nim siedzisz, to pierwsza i najprostsza rzecz do zmiany.

Większość paneli hostingowych pozwala zmienić wersję PHP jednym kliknięciem. Zrób backup, zmień na 8.2 lub 8.3, sprawdź, czy strony działają. W rzadkich przypadkach jakaś stara wtyczka może nie być kompatybilna – to sygnał, że i tak warto ją wymienić, bo prędzej czy później zacznie sprawiać problemy.

Kiedy hosting faktycznie jest winny

Jeśli po sprawdzeniu autoloadu, zewnętrznych żądań, heartbeat, indeksów bazy i cache obiektowego panel wciąż działa wolno – TTFB powyżej 600 milisekund przy pustej stronie admina – hosting faktycznie może być wąskim gardłem. Zwłaszcza budżetowe pakiety shared hosting, gdzie dzielisz PHP-FPM workery z kilkudziesięcioma innymi stronami.

To jednak ostateczność, nie pierwsza diagnoza. Większość przypadków wolnego panelu udaje się rozwiązać bez zmiany hostingu.

Praktyczna reguła decyzyjna

Zanim zapłacisz za droższy hosting, przejdź przez tę listę:

1. Zainstaluj Query Monitor i sprawdź czas generowania strony, liczbę zapytań i pamięć.
2. Zmierz rozmiar autoload w wp_options – cel poniżej 1 MB.
3. Przejrzyj panel HTTP API Calls – szukaj żądań powyżej 1 sekundy.
4. Sortuj zapytania DB po czasie – interesują cię te powyżej 50 milisekund.
5. Zidentyfikuj wtyczkę generującą najwięcej zapytań (Queries by Component).
6. Ustaw heartbeat na 60 sekund na dashboardzie.
7. Wyłącz zbędne widgety dashboardu.
8. Włącz Redis, jeśli hosting go oferuje.
9. Zaktualizuj PHP do najnowszej stabilnej wersji.
10. Dodaj indeksy do tabeli wp_postmeta.

Jeśli wykonanie tych dziesięciu kroków nie przyspieszy panelu – dopiero wtedy warto rozmawiać z hostingiem o upgrade. Z doświadczenia: w ośmiu na dziesięć przypadków problem znika przed krokiem dziewiątym.