Autoload in WordPress: Werte, Abfragen und Speicherbedarf

WordPress lädt häufig benötigte Optionen gemeinsam in einen Satz namens alloptions. Die Spalte autoload legt fest, welche Einträge standardmäßig dazugehören. Seit WordPress 6.6 reicht eine Prüfung auf yes allein nicht mehr aus: Weitere Werte können ebenfalls Autoload bedeuten.

Was beim Laden tatsächlich passiert

Optionen einer Website stehen normalerweise in deren Options-Tabelle. Beim Aufbau von alloptions prüft WordPress zunächst den Objektcache. Nur ohne passenden Cachetreffer wird die Datenbank abgefragt. Ein vorgeschalteter Ganzseiten-Cache kann eine Seite sogar ohne vollständigen WordPress-Start ausliefern. Statische Dateien und beliebige andere PHP-Skripte laden nicht automatisch WordPress-Optionen.

Autoload spart einzelne Optionsabfragen, hält dafür aber auch gerade ungenutzte Werte im geladenen Satz bereit. Optionen ohne Autoload bleiben über get_option() abrufbar und können ebenfalls im Objektcache liegen. „Nicht automatisch geladen“ bedeutet weder gelöscht noch grundsätzlich langsam.

Welche Werte zählen

• yes und no: ältere, weiterhin unterstützte Kennzeichnungen.
• on und off: ausdrücklich aktiviertes beziehungsweise deaktiviertes Autoload.
• auto-on und auto-off: Ergebnis der automatischen Entscheidung.
• auto: ohne eindeutige automatische Entscheidung; standardmäßig ebenfalls geladen.

wp_autoload_values_to_autoload() liefert standardmäßig yes, on, auto-on und auto. Ein gleichnamiger Filter kann Werte daraus entfernen. Die tatsächliche Laufzeitliste kann daher kleiner sein. Ein Update entfernt alte yes-Werte nicht pauschal.

Eine lesende SQL-Prüfung

Die folgende Abfrage zeigt Anzahl und gespeicherte Nutzdatenbytes für die Standardliste. wp_options ist durch den tatsächlichen Tabellennamen zu ersetzen, insbesondere bei anderem Präfix oder Multisite:

SELECT COUNT(*) AS option_count,
       COALESCE(SUM(OCTET_LENGTH(option_value)), 0) AS value_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Bei verändertem Autoload-Filter muss die Werteliste angepasst werden. Für die Suche nach großen Einträgen eignet sich zusätzlich:

SELECT option_name, autoload,
       OCTET_LENGTH(option_value) AS value_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY value_bytes DESC
LIMIT 20;

Die Abfragen verändern keine Optionen. OCTET_LENGTH zählt Bytes des gespeicherten Werts, keine Zeichen und keinen PHP-Arbeitsspeicher. Namen, Arrayverwaltung, Deserialisierung und Cacheformat verursachen zusätzliche oder anders verteilte Kosten. Auch der Core-Rückfall ist relevant: Liefert die Autoload-Abfrage keine Zeilen, kann wp_load_alloptions() anschließend sämtliche Optionen abrufen. Eine leere Trefferliste beweist deshalb nicht, dass keine Daten geladen werden.

Was die Grenze von 150.000 Bytes bedeutet

Ohne ausdrücklich gesetztes Autoload bewertet WordPress den neuen beziehungsweise aktualisierten Wert über Filter. Die standardmäßige Größenregel liefert bei mehr als 150.000 gespeicherten Bytes auto-off. Genau 150.000 Bytes überschreiten die Grenze noch nicht. Ein ausdrücklich übergebenes true führt dagegen zu on, auch bei größerem Wert.

Der Filter wp_max_autoloaded_option_size kann die Grenze ändern; weitere Filter können die Entscheidung beeinflussen. Die Regel ist weder ein globales Speicherlimit noch ein laufender Bereinigungsvorgang für sämtliche bestehenden Optionen. Ein Wert von 102.403 Bytes mit Kennzeichnung off wäre beispielsweise kein Beleg für das Überschreiten dieser Grenze.

Aktuelle Momentaufnahme dieses Blogs

Eine ausschließlich lesende Messung vom 24. Oktober 2026 ergab 31.912 Optionen. Davon entsprechen 156 Einträge der zu diesem Zeitpunkt wirksamen Autoload-Liste: zusammen 113.816 gespeicherte Nutzdatenbytes, rund 111,1 KiB. Die reine yes-Abfrage liefert hier weiterhin null Treffer; vorhanden sind on, auto und off.

Die größten Autoload-Werte sind cron mit 51.679 Bytes, rewrite_rules mit 16.592 Bytes und wpseo_taxonomy_meta mit 15.666 Bytes. Zusammen ergeben diese drei Werte rund 73,7 Prozent der gemessenen Nutzdaten. Das ist eine datierte Bestandsaufnahme, keine Laufzeitmessung und kein Beweis für überflüssige Daten.