Backend WordPress
wydajność

Dlaczego optymalizacja frontendu nie wystarcza do szybkości WordPress

Większość poradników o wydajności WordPress skupia się na optymalizacji frontendu: cache, kompresja obrazków, minifikacja, CDN. To wszystko ma sens—i powinieneś to zrobić.

Ale o tym nikt nie mówi: wydajność backendu.

Winowajcą bywa zwykle Time to First Byte (TTFB)—czas, zanim serwer w ogóle zacznie odpowiadać. Jeśli serwer potrzebuje 2 sekund na złożenie strony, żadna ilość optymalizacji frontendu nie pomoże.

Który problem backendu masz?

Cztery objawy, cztery różne przyczyny. Zacznij od tego, co naprawdę widzisz, i resztę strony pomiń.

1. Admin jest wolny, a frontend w porządku. To nie jest problem cache i nigdy nie będzie. To admin-ajax, Heartbeat, callbacki wtyczek na admin_init albo autoload. Zdiagnozuj wolny wp-admin.
2. TTFB jest wysoki na stronach, które cache powinien serwować. Coś leci, zanim cache zdąży odpowiedzieć. Zwykle wolne zapytanie albo zestaw autoload za duży na object cache. Najpierw Znajdź wolne zapytania, potem sprawdź rozmiar autoloadu.
3. Hosting oflagował „autoloaded data”. Zmierz sam, zanim cokolwiek zrobisz — część paneli zaniża na WordPress 6.6+. Zaudytuj i napraw rozdęcie autoloadu.
4. Znasz przyczynę i chcesz to naprawić automatycznie. Autoloader Optimizer kategoryzuje każdą opcję autoload i przełącza bezpieczne, z przywracaniem jednym kliknięciem.

Benchmarki TTFB WordPress: znać swoje liczby

Sprawdź TTFB: Chrome DevTools → Network → pierwsze żądanie → „Waiting (TTFB)”

Jeśli TTFB jest powyżej 500 ms, najpierw backend, zanim ruszysz cokolwiek innego. Naprawiasz nie ten problem.

Jak diagnozować problemy wydajności backendu WordPress

Kroki 02–06 mierzą po jednej rzeczy, ręcznie. Krok 01 mierzy je wszystkie w jednym przebiegu — zacznij tam i pozwól rankowanej liście zdecydować, które z pozostałych jeszcze musisz odpalić.

Nie masz jeszcze wtyczki? darmowa strona /scan/ mierzy TTFB i kompresję z zewnątrz — czy serwer jest wolny, zanim przeglądarka dostanie pierwszy bajt. Nie odpala checków Site Doctor — te potrzebują serwera. Gdy masz już zewnętrzny wynik, zainstaluj WP Multitool i odpal skan.

1. Przeskanuj całą instalację przez Site Doctor — jeden przebieg po stronie wewnątrz WP Multitool: OPcache, drop-in object-cache, zdrowie Redis, probe page cache, nakładające się optymalizatory i balast bazy — rankowane od najgorszego, każde znalezisko zlinkowane do modułu, który to naprawia. Jest w Lite i w Pro; źródła autoload i złapanych wolnych zapytań są tylko w Pro, a skan w Lite oznacza je jako pominięte zamiast raportować czystą stronę. Checklist Redis, użycie WP-CLI i pełna lista checków są w dokumentacji Site Doctor.
2. Zmierz TTFB — Chrome DevTools albo WebPageTest. Jeśli szybko — frontend. Jeśli wolno — jedź dalej.
3. Sprawdź rozmiar autoloadu — Odpal powyższe SQL. Powyżej 1MB = działać od razu.
4. Włącz SAVEQUERIES — Dodaj tymczasowo define('SAVEQUERIES', true); do wp-config.php. Sprawdź $wpdb->queries pod wolne.
5. Zainstaluj Query Monitor — Darmowa wtyczka, która pokazuje, które funkcje odpalają które zapytania. Niezbędna przy debugowaniu.
6. Szukanie binarne wtyczek — Wyłącz wszystkie, zmierz TTFB, włączaj partiami, aż znajdziesz wolną.

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

Dlaczego problemy backendu WordPress wracają

Problemy backendu są niewidoczne. WordPress domyślnie nie pokazuje wolnych zapytań. Strona może mieć zapytania po 2 sekundy, o których nie wiesz, bo nie ma logowania.

I to nie jest jednorazowa naprawa. Wydajność spada z czasem, gdy:

1. Dokładasz wtyczki, które wpinają się w każde żądanie
2. Zbierasz treść i metadane
3. Rośnie ruch (wychodzą ukryte problemy)
4. Aktualizacje wtyczek wnoszą regresje

Potrzebujesz ciągłego monitoringu, nie tylko okresowych ręcznych sprawdzeń. Jeśli twój admin WordPress już jest wolny, szkoda rośnie z każdym załadowaniem strony.