Zbyt duży autoload w WordPressie może podnosić TTFB, ponieważ przy każdym żądaniu system pobiera opcje oznaczone jako autoload=yes. Najpierw zidentyfikuj największe rekordy w tabeli wp_options, wykonaj kopię bazy, a dopiero potem zmień status zbędnych danych na no lub usuń je, jeśli masz pewność, że nie są już potrzebne.
Dlaczego autoload spowalnia WordPressa?
Opcje WordPressa są przechowywane w tabeli wp_options. Rekord z flagą autoload=yes jest ładowany automatycznie podczas obsługi żądania. Dzięki temu ustawienia często używanych funkcji są dostępne bez dodatkowego odczytu, ale zbyt duży zestaw takich danych zwiększa ilość pracy wykonywanej przy każdym wejściu na stronę.
Problem często narasta po instalowaniu i usuwaniu wtyczek. Rozszerzenie może pozostawić konfigurację, logi, transienty lub dane tymczasowe, mimo że sama wtyczka nie jest już używana. Skutkiem bywa wyższy TTFB, czyli czas oczekiwania na pierwszy bajt odpowiedzi serwera.
| Waga danych autoload | Wpływ na TTFB | Rekomendacja |
|---|---|---|
| Mniej niż 500 KB | Zwykle niewielki, ale zależny od hostingu i zapytań | Monitoruj przy większych zmianach wtyczek |
| 500 KB–1 MB | Może być odczuwalny na słabszym serwerze | Sprawdź największe rekordy |
| Powyżej 1 MB | Ryzyko wyraźnego wzrostu czasu odpowiedzi | Przeprowadź diagnostykę i ogranicz zbędny autoload |
Podane progi są orientacyjne, a nie uniwersalnym testem wydajności. Na wynik wpływają także wersja PHP, konfiguracja bazy, cache obiektowy, hosting i kod aktywnych wtyczek.
Jak sprawdzić, co zajmuje najwięcej miejsca?
W phpMyAdmin wybierz bazę używaną przez WordPress, otwórz zakładkę SQL i uruchom zapytanie. Jeśli instalacja korzysta z innego prefiksu tabel niż wp_, zastąp nim nazwę wp_options.
SELECT
option_id,
option_name,
LENGTH(option_value) AS size_bytes,
autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on')
ORDER BY size_bytes DESC
LIMIT 50;W nowszych wersjach WordPressa mogą występować także wartości on, auto i auto-on. Dlatego nie ograniczaj diagnostyki wyłącznie do literalnego yes.
Do wstępnej oceny łącznego rozmiaru możesz użyć również takiego zapytania:
SELECT
autoload,
COUNT(*) AS options_count,
SUM(LENGTH(option_value)) AS total_bytes
FROM wp_options
GROUP BY autoload
ORDER BY total_bytes DESC;Najczęściej podejrzane są:
- pozostałości po usuniętych wtyczkach – konfiguracja, cache lub dane migracyjne
- logi i debugowanie – wpisy przechowywane w bazie przez rozszerzenia
- transienty – dane tymczasowe, które nie zostały prawidłowo usunięte
- bardzo duże opcje serializowane – złożone tablice, których nie należy edytować ręcznie bez pewności co do ich struktury
Jeśli nie chcesz korzystać z SQL, użyj Query Monitor. Wtyczka pomaga wskazać wolne zapytania i problemy z bazą, ale nie podejmie za Ciebie decyzji, który rekord można usunąć. Nazwę opcji trzeba powiązać z konkretną wtyczką lub funkcją, zanim zmienisz jej status.
Jak bezpiecznie oczyścić autoload?
Nie wykonuj żadnego zapytania modyfikującego bazę bez aktualnej kopii zapasowej. Backup powinien obejmować bazę danych i być możliwy do odtworzenia, a nie tylko zapisany na tym samym koncie hostingowym.
Przed zmianami sprawdź następujące warunki:
- Wykonano backup bazy i znasz sposób jego odtworzenia.
- Masz dostęp do phpMyAdmin lub innego narzędzia administracyjnego.
- Zweryfikowano, z jaką wtyczką lub funkcją związany jest każdy rekord.
- Masz kopię testową strony albo możesz wykonać test poza godzinami największego ruchu.
Procedurę wykonuj w tej kolejności:
- Zdiagnozuj rekordy – zapisz listę największych opcji oraz ich rozmiary.
- Ustal właściciela danych – sprawdź prefiks nazwy, dokumentację wtyczki i kod, jeśli rekord jest niejasny.
- Zmień autoload na
no– to bezpieczniejsza i odwracalna metoda niż natychmiastowe usuwanie. - Przetestuj stronę – sprawdź stronę główną, logowanie, formularze, edytor i funkcje zależne od danej wtyczki.
- Usuń rekord dopiero po weryfikacji – dotyczy to wyłącznie danych po odinstalowanej wtyczce lub potwierdzonych pozostałości.
Przykładowa zmiana statusu pojedynczego, zweryfikowanego rekordu wygląda tak:
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'nazwa_opcji';Najpierw możesz ograniczyć zapytanie do konkretnego identyfikatora, aby zmniejszyć ryzyko pomyłki:
UPDATE wp_options
SET autoload = 'no'
WHERE option_id = 1234
AND option_name = 'nazwa_opcji';Usuwanie jest operacją destrukcyjną. Wykonuj je wyłącznie po potwierdzeniu, że rekord nie jest już używany:
DELETE FROM wp_options
WHERE option_id = 1234
AND option_name = 'nazwa_opcji';Zmiana na no nie usuwa danych. WordPress pobierze je dopiero wtedy, gdy kod wykona zapytanie o konkretną opcję. Jeśli strona zacznie działać nieprawidłowo, możesz przywrócić poprzedni status:
UPDATE wp_options
SET autoload = 'yes'
WHERE option_id = 1234
AND option_name = 'nazwa_opcji';Nie modyfikuj ręcznie fragmentu wartości serializowanej, jeśli nie znasz jej struktury. Zmiana długości lub składni może uszkodzić całą tablicę ustawień. W takiej sytuacji bezpieczniej przywrócić backup albo użyć narzędzia, które prawidłowo obsługuje dane serializowane.
Na co uważać podczas czyszczenia?
Największy rekord nie zawsze jest zbędny. Aktywna wtyczka może przechowywać w jednej opcji konfigurację potrzebną do działania strony, sklepu, formularza albo integracji. Usunięcie takiego wpisu może wywołać błędy PHP, utratę ustawień lub błąd 500.
Staging pozwala sprawdzić zmianę bez ryzyka dla odwiedzających. Po modyfikacji obserwuj logi PHP, działanie panelu, formularze, płatności i proces publikacji. Jeśli nie potrafisz przypisać rekordu do konkretnego rozszerzenia albo po zmianie pojawił się błąd 500, przywróć backup i skonsultuj operację z administratorem WordPressa.
Po zakończeniu porównaj rozmiar autoload z pomiarem początkowym i sprawdź TTFB w tych samych warunkach. Samo zmniejszenie liczby bajtów nie gwarantuje poprawy, ale daje podstawę do dalszej oceny. Najbezpieczniejsza strategia to diagnoza, backup, zmiana yes na no, testy i dopiero później selektywne usuwanie potwierdzonych pozostałości.
