Dlaczego mój admin WordPress jest taki wolny?

Dlaczego kokpit admina WordPress jest wolny

Jeśli admin WordPress jest wolny — albo kokpit WordPress jest bardzo wolny, a frontend szybki — nie urojenie. Wolny panel admina WordPress to jedna z najczęstszych skarg właścicieli stron po optymalizacji witryny publicznej. Wtyczki cache omijają wp-admin. CDN nie rusza panelu admina. Każde kliknięcie w backendzie WordPress odpala świeże żądanie PHP, ładuje hooki admina każdej aktywnej wtyczki i wciąga pełny zestaw autoloadowanych danych z wp_options.

Wtyczki cache tu nie pomagają — celowo omijają strony admina. CDN nie pomaga — admin jest dynamiczny. Spowolnienie idzie z wewnątrz WordPressa.

Admin WordPress wolny, frontend szybki? Dopasuj objaw

„Admin WordPress bardzo wolny” to nie jeden problem — to pięć–sześć różnych, które z kokpitu czują się tak samo. Znajdź swój konkretny objaw poniżej: kolumna przyczyny mówi, który mechanizm winić, a następny krok — co z tym zrobić.

Krok 0: Zeskanuj całą stronę, zanim cokolwiek zmierzysz

Wszystko poniżej tej sekcji mierzy jedną rzecz na raz. Zanim spędzisz 15 minut robiąc to ręcznie, poświęć minutę na Site Doctor w WP Multitool: odpala cały zestaw checków w jednym przebiegu — OPcache, drop-in object-cache, zdrowie Redis, probe page cache, nakładki optymalizatorów, balast bazy — i rankuje znaleziska od najgorszego, każde zlinkowane do modułu, który to naprawia.

Nie masz jeszcze wtyczki? darmowa strona /scan/ mierzy TTFB i kompresję z zewnątrz, co mówi ci, czy serwer jest wolny, zanim przeglądarka dostanie pierwszy bajt. Nie odpala żadnego z powyższych checków — one muszą lecieć na serwerze — więc gdy masz zewnętrzną liczbę, zainstaluj WP Multitool i odpal skan. Site Doctor jest w Lite i w Pro; źródła autoload i złapanych wolnych zapytań, które czyta, są tylko w Pro, a skan Lite oznacza te dwa jako pominięte źródła zamiast pozwalać krótkiej liście wyglądać na czystą stronę.

Kiedy Multitool to zła pierwsza odpowiedź: jeśli debugujesz jedno konkretne żądanie i już wiesz które, otwórz je w Query Monitor; jeśli zadaniem jest przyspieszenie publicznego frontendu dla wylogowanych, to wtyczka page-cache, nie skan diagnostyczny.

Skan daje ci shortlistę. Głębia per żądanie i per callback dalej przychodzi z Query Monitor i Slow Callback Finder niżej na tej stronie — rankowana lista tylko mówi, które z nich warto otworzyć. Pełna lista checków, checklista Redis i użycie WP-CLI są w dokumentacji Site Doctor; jeśli wolisz zrobić to ręcznie, 15-minutowa checklista poniżej robi tę samą robotę z DevTools i SQL.

Dlaczego kokpit WordPress jest wolny? (kokpit kontra reszta wp-admin)

„Wolny kokpit” i „wolny wp-admin” używa się zamiennie. To dwa różne problemy. Ekran główny kokpitu (/wp-admin/index.php) robi robotę, której nie robi żaden inny ekran admina — więc zanim cokolwiek naprawisz, ustal, który masz.

Test trwa minutę. Załaduj /wp-admin/, potem Ustawienia → Ogólne i porównaj czasy ładowania dokumentu w DevTools. Jeśli kokpit jest 2+ sekundy wolniejszy, to widgety — usuń te, których nie sprawdzasz codziennie, snippetem wp_dashboard_setup w sekcja szybkich wygranych. Widgety z zewnętrznym HTTP to najgorsi sprawcy: strona czeka na cudzy serwer.

Jeśli oba ekrany są tak samo wolne, kokpit nie jest problemem — cały wp-admin jest. To rozmiar autoloadu i callbacki admin_init, opisane w przyczyny poniżej. Naprawa widgetów kokpitu najpierw nic ci nie da na pozostałych 40 ekranach, których używasz cały dzień.

4 prawdziwe przyczyny wolnego admina WordPress

1. Wąskie gardło admin-ajax.php

WordPress puszcza wszystkie żądania AJAX przez jeden plik: admin-ajax.php. Każde żądanie bootstrappuje cały stos WordPress. Jeśli 5 wtyczek robi AJAX na kokpicie, to 5 dodatkowych pełnych bootstrapów WordPress na widok kokpitu.

# Check admin-ajax traffic in your browser:
# DevTools → Network → Filter "admin-ajax"
# Look at how many requests fire on a single page load

2. Narzut Heartbeat API

WordPress Heartbeat wysyła żądanie AJAX co 15–60 sekund po autosave, blokady wpisów i powiadomienia. Każde ładuje pełny stos WordPress. Na hostingu współdzielonym samo to potrafi nasycić workery PHP.

// Slow down heartbeat to reduce load:
add_filter('heartbeat_settings', function($settings) {
    $settings['interval'] = 120; // seconds (default: 15-60)
    return $settings;
});

3. Wolne callbacki wtyczek na admin_init

Wtyczki wpinają się w admin_init, admin_menu i admin_enqueue_scripts. Lecą na każdej stronie admina, nie tylko na ustawieniach wtyczki. Jeden źle napisany callback potrafi dodać 500 ms+ do każdego żądania admina.

4. Rozdęcie autoloadu

To samo zapytanie autoload wp_options, które bije we frontend, leci też na każdej stronie admina. Ale strony admina nigdy nie są w cache, więc czujesz pełny koszt za każdym razem. Czytaj pełny poradnik autoloadu.

Szybkie wygrane, gdy wiesz, który przypadek masz

Zmniejsz częstotliwość Heartbeat

Zmiana Heartbeat z 15 s na 120 s obcina tło admin-ajax o 87% (karty edytora, 15 s → 120 s). Większość stron nie zauważy różnicy w działaniu.

Wyłącz widgety kokpitu

Każdy widget kokpitu odpala własne zapytania przy ładowaniu. Usuń widgety wtyczek, których nie sprawdzasz codziennie:

add_action('wp_dashboard_setup', function() {
    remove_meta_box('dashboard_quick_press', 'dashboard', 'side');
    remove_meta_box('dashboard_primary', 'dashboard', 'side');
    // Remove plugin widgets that make external API calls
});

Dodaj object cache

Redis albo Memcached poprawia wydajność admina, bo strony admina są ciężkie od zapytań i nigdy nie mają page cache. Lookupi bazy z każdej strony admina idą z pamięci.

Autoloadowane dane na hostingu zarządzanym (WP Engine, Flywheel)

Jeśli jesteś na WP Engine albo Flywheel i panel admina jest wolny, najpierw sprawdź autoloadowane dane. WP Engine poleca trzymać łączne opcje autoload poniżej 800 KB. Powyżej każde żądanie admina ładuje za duży wynik wp_options do pamięci — a strony admina nigdy nie są w cache, więc czujesz pełny koszt przy każdym kliknięciu.

Zaudytuj rozmiar autoloadu jednym zapytaniem:

-- Total autoloaded data (target: under 800 KB)
SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');

-- Top 20 biggest autoloaded options
SELECT option_name, ROUND(LENGTH(option_value) / 1024, 1) AS kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

Typowi sprawcy: stare transjenty, cache sprawdzania aktualizacji wtyczek i za duże bloby motywu/opcji z page builderów. Bezpieczna poprawka to wyłączenie autoload na pojedynczych opcjach — wp option set-autoload OPTION_NAME off — nie hurtowe kasowanie wierszy. Autoloader Optimizer WP Multitool szereguje sprawców i wyłącza autoload bezpiecznie.

Jeśli autoload jest już poniżej 800 KB, a panel admina nadal bardzo wolny, wąskie gardło przeszło na callbacki hooków — tam wkracza Slow Callback Finder.

Przed i po: jak wygląda „naprawione”

Nie pokażę ci wymyślonych liczb klientów — before/after, którego nie zmierzyłeś, to fikcja. Mogę dać arkusz, który wypełniam, zanim cokolwiek ruszę. Wypełnij go najpierw, zmieniaj po jednej rzeczy i mierz po każdej zmianie. Bez kolumny „przed” nigdy nie wiesz, która poprawka zadziałała.

Dwie zasady robią liczby uczciwymi. Mierz na tej samej stronie, tej samej przeglądarce, o tej samej porze — obciążenie admina zależy od aktywności zespołu. I zmieniaj jedną rzecz między pomiarami, inaczej nie przypiszesz poprawy niczemu. Wartości bezwzględne znaczą mniej niż delty: obcięcie TTFB admina o połowę na tanim hostingu bije „szybką” liczbę, której nie odtworzysz.

Powiązane poradniki