WordPress
Autoload-Ballast

Autoloaded Daten prüfen: zwei Queries

Fügen Sie diese in phpMyAdmin, Adminer oder wp db query ein – die erste liefert Ihre gesamte Autoload-Größe in KB, die zweite listet die 25 Optionen, die sie tatsächlich verursachen. Passen Sie das Präfix wp_ an, falls Ihres abweicht.

-- Total autoloaded data (KB) + row count
SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb,
       COUNT(*) AS autoload_count
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

-- Top 25 offenders, biggest first
SELECT option_name,
       ROUND(LENGTH(option_value) / 1024, 1) AS size_kb,
       autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 25;

WordPress-Autoloader vs. autoloaded Daten

„Autoloader" bedeutet in WordPress zwei völlig verschiedene Dinge, und die Suche danach liefert beides. Dreißig Sekunden zu prüfen, welches Sie vor sich haben, lohnt sich.

Wenn Sie hier gelandet sind, weil ein Hoster „autoloaded data" gemeldet hat oder weil Sie alloptions in einem Profiler gesehen haben, ist das Zweite gemeint. Wenn Sie einen Class not found-Fatal debuggen, ist das Erste gemeint – und diese Seite hilft Ihnen nicht weiter, das ist ein Composer- oder PSR-4-Problem.

Der Begriff „Plugin-Autoloader" ist genauso mehrdeutig. Ein Plugin bringt einen Composer-Autoloader für seine eigenen Klassen mit und schreibt gleichzeitig autoloaded Optionen. Nur das Zweite taucht in der Query unten auf.

Was sind autoloaded Daten?

WordPress hat eine einzelne Query, die bei jedem Seitenaufruf läuft, bevor Theme- oder Plugin-Code ausgeführt wird:

SELECT option_name, option_value
FROM wp_options
WHERE autoload = 'yes'

Sie lädt alle „autoloaded" Optionen auf einmal in den Speicher. Der WordPress-Core braucht davon rund 100 KB. Das Problem ist, dass Plugins es übertreiben.

Anders als langsame Queries, die Ihre TTFB nur zeitweise hochtreiben, ist Autoload-Ballast eine Dauersteuer. Er verlängert jeden einzelnen Request—gecacht oder nicht, Frontend oder Backend, AJAX oder Seitenaufruf.

Die Warnung „Autoloaded Data" bei WP Engine: was jetzt zu tun ist

WP Engine meldet autoloaded Daten ab 800 KB und bezeichnet alles darunter als normal. Es ist einer der wenigen Hoster, der das als Dashboard-Warnung anzeigt – deshalb stoßen die meisten Leute über ihn auf das Problem. Die Physik dahinter ist hoster-unabhängig: Jeder Request zieht das ganze Set nach PHP, ganz gleich, wo Sie hosten.

Die Warnung nennt Ihnen eine Zahl und sonst nichts. Hier steht, was Sie damit anfangen.

1. Messen Sie zuerst selbst. Führen Sie die Prüf-Query oben auf dieser Seite aus. Hoster-Dashboards messen nach Zeitplan, die angezeigte Zahl kann also Stunden alt sein, und manche Panels prüfen weiterhin autoload = 'yes', was unter WordPress 6.6+ zu niedrig zählt, weil der Core inzwischen auch 'on', 'auto' und 'auto-on' schreibt. Ein Panel, das „im normalen Bereich" sagt, ist kein Beweis.
2. Suchen Sie die Verursacher, nicht die Summe. Die Summe ist ein Symptom. Listen Sie die 25 größten Zeilen nach LENGTH(option_value) auf, und meist tragen drei oder vier Zeilen den Großteil des Gewichts.
3. Prüfen Sie jede einzelne gegen die Finger-weg-Liste weiter unten auf dieser Seite, bevor Sie etwas ändern. Manche großen autoloaded Optionen sollen groß sein.
4. Autoload abschalten, nicht löschen. wp option set-autoload OPTION_NAME off lässt die Daten intakt und umkehrbar. Zeilen zu löschen ist der Weg, die Einstellungen eines Plugins zu zerstören.
5. Erneut messen und dem Panel Zeit geben. Die Warnung verschwindet erst bei der nächsten Prüfung von WP Engine, nicht sofort.

Ein Vorbehalt speziell für Managed-Hoster mit Memcached: oberhalb von rund 1 MB kann das Autoload-Blob das Limit pro Schlüssel überschreiten, landet dann unbemerkt nicht im Cache, und jeder Request geht zurück in die Datenbank. Das ist schlimmer, als die Warnung vermuten lässt, und es zeigt sich als zufällige 502er im wp-admin statt als langsame Seite.

Unter 800 KB von Hand zu kommen, sind ein paar Stunden sorgfältige Arbeit. Der Autoloader Optimizer von WP Multitool erledigt dieselbe Prüfung, kategorisiert jede Zeile und schaltet die unbedenklichen um – mit Wiederherstellung per Klick dahinter.

Was Autoload-Ballast in WordPress verursacht

1. Überreste deaktivierter Plugins

Die meisten Plugins räumen nicht hinter sich auf. Sie legen bei der Aktivierung Optionen an und lassen sie für immer stehen—auch nach Deaktivierung und Löschung. So finden Sie sie:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Achten Sie auf Optionsnamen von Plugins, die Sie nicht mehr benutzen. Diese können Sie gefahrlos auf autoload='no' setzen oder ganz löschen.

2. Serialisierte Arrays, die wachsen

Manche Plugins speichern wachsende Daten in einer einzigen Option: Logs, Analytics-Snapshots, Cron-Zeitpläne. Ein einzelner option_value kann über 500 KB serialisiertes PHP sein.

3. Abgelaufene Transients

Transients sind temporäre Cache-Werte, die in wp_options liegen. Ohne externen Object Cache sammeln sich abgelaufene Transients an. WordPress räumt sie nur träge auf—beim nächsten Zugriff. Diese alten Transients können sich außerdem als langsame Queries bemerkbar machen, sobald die Tabelle groß genug wird.

SELECT COUNT(*) FROM wp_options
WHERE option_name LIKE '_transient_%'
AND autoload = 'yes';

4. Falsch konfigurierte Plugins

Plugins, die Einstellungen pro Benutzer, große JSON-Konfigurationen oder gecachte API-Antworten in autoloaded Optionen ablegen. Die Daten mögen nötig sein, aber sie müssen nicht bei jedem Request geladen werden.

Was Sie NICHT abschalten sollten

autoload umzuschalten ist umkehrbar. Zeilen zu löschen nicht. Manche Optionen müssen aber autoloaded bleiben, solange ihr Besitzer aktiv ist, sonst brechen WordPress und Ihre Plugins früh im Bootstrap – und es kommt kein Fehler, es wird einfach still schlechter. Nehmen Sie das als Kontrolle vor jeder Massenänderung.

Die Regel: Ist das Plugin aktiv und die Option Konfiguration, die es bei jedem Request liest, lassen Sie Autoload an. Ist das Plugin weg oder der Wert ein Cache-, Log- oder Queue-Blob, schalten Sie zuerst Autoload ab – und löschen Sie erst, wenn Sie sicher sind, dass niemand die Zeile mehr liest.

Typische Autoload-Verursacher: Ist das Abschalten sicher?

Zwanzig Präfixe, die mir immer wieder begegnen, und was ich mit jedem mache. „Vorsicht" heißt, die Antwort hängt davon ab, ob das Plugin noch aktiv ist – prüfen Sie das zuerst.

Autoload-Ballast in WordPress beheben

Autoload für einzelne Optionen abschalten

UPDATE wp_options SET autoload = 'no'
WHERE option_name = 'old_plugin_settings';

Abgelaufene Transients aufräumen

DELETE FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

Verwaiste Plugin-Daten löschen

-- Only after confirming the plugin is gone:
DELETE FROM wp_options
WHERE option_name LIKE 'removed_plugin_%';

Das Problem an manuellen Korrekturen: sie halten nicht. Plugins legen weiter Daten an. Transients sammeln sich neu an. Neue Plugins bringen neue autoloaded Optionen mit. Sie müssten monatlich prüfen, um das im Griff zu behalten.