Autoload in wp_options prüfen und sicher verkleinern

Cookbook: Ziel und Ergebnis

Du reduzierst nur belegte, unnötige Autoload-Last. Große gültige Konfiguration bleibt erhalten; unbekannte Optionen werden nicht gelöscht.

Rezept: Schritt für Schritt

1. Datenbank-Backup und Wiederherstellungsweg prüfen; Tabellenpräfix ermitteln.
2. Site Health und eine rein lesende Größenabfrage ausführen. Top-50 nach Bytes exportieren.
3. Jede große Option per Code-Suche, Plugin-Dokumentation und Deaktivierungshistorie einem Eigentümer zuordnen.
4. Zuerst selten benötigte, weiterhin gültige Optionen über die WordPress-Options-API auf Autoload false setzen; Löschung ist ein gesonderter Vorgang.

Rechenweg oder Entscheidungsregel

Autoload gesamt = SUM(LENGTH(option_value)) für autoloadfähige Werte\nAnteil Option (%) = Bytes der Option / Autoload gesamt × 100

Der Core-Warnwert von 800.000 Byte ist ein Signal zur Prüfung, kein Löschziel. Der Gewinn betrifft vor allem ungecachte PHP-Anfragen.

Praxisbeispiel

Gesamt 1,8 MB; eine Cache-Statistik eines entfernten Plugins belegt 900 kB, aktive Core-/Shop-Konfiguration 600 kB. Nur der belegte Altbestand wird auf Staging entfernt. Danach 0,9 MB und stabile Funktionen; die übrigen Werte werden nicht „auf Verdacht“ angefasst.

Prüfen, ob es funktioniert

• Abfrage und Site Health nach Änderung wiederholen.
• Frontend, Admin, Cron, REST und Eigentümer-Plugin testen.
• PHP-Fehlerlog und ungecachte TTFB vergleichen; Page-Cache-Hits sind ungeeignet.

Rollback

Option mit gesichertem Wert und ursprünglichem Autoload-Status über WordPress-API wiederherstellen, Object Cache leeren und Funktionen erneut prüfen. Bei serialisierten Daten keine manuelle Textmanipulation.

Was Autoload bedeutet

WordPress lädt autoload-markierte Optionen gebündelt. Das spart einzelne Abfragen für häufig benötigte Konfiguration, wird aber teuer, wenn große oder verwaiste Daten bei jeder Anfrage mitkommen. Site Health verwendet aktuell 800.000 Byte als filterbaren Warnwert.

Bestandsaufnahme

Beginne in Werkzeuge → Website-Zustand. Für eine Detailanalyse können Administratoren die größten autoload-Werte nach LENGTH(option_value) sortieren. Der Tabellenpräfix ist nicht immer wp_; SQL nur lesend und mit korrektem Präfix ausführen.

SELECT option_name, LENGTH(option_value) AS bytes, autoload
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY bytes DESC
LIMIT 50;

Sichere Entscheidung

Ordne jede große Option Core, Theme oder Plugin zu. Aktive, häufig benötigte Konfiguration darf autoloaden. Große, selten benötigte Daten können über die zuständige API auf false gesetzt werden. Bei WordPress 6.7+ sind für neue API-Aufrufe boolesche Werte vorgesehen; die alten Strings yes/no sind veraltet.

Nicht tun: Optionen allein wegen Name oder Größe löschen. Deaktivierte Plugins können Daten für eine spätere Reaktivierung benötigen; serialisierte Werte dürfen nicht per Suchen/Ersetzen beschädigt werden.

Erfolgskontrolle

Site Health und Größenabfrage wiederholen, Frontend, Admin, Cron und Plugin-Funktionen testen. Der Gewinn zeigt sich primär bei ungecachten PHP-Anfragen.

Quellen und Prüfstand

• WordPress: Site-Health-Autoload-Test
• WordPress: wp_set_options_autoload()
• WordPress: Options API

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.