Zum Inhalt springen 
Ich analysiere WordPress Autoload-Daten gezielt, identifiziere übergroße Einträge in der wp_options-Tabelle und räume kritische Kandidaten ab. So senke ich die Gesamtgröße der automatisch geladenen Optionen, drücke TTFB, entlaste RAM und beschleunige Backend und Frontend zuverlässig.
Zentrale Punkte
Die folgenden Punkte geben dir einen kompakten Überblick, bevor ich tiefer einsteige.
- Autoload-Größe klein halten (Ideal: unter 1–2 MB)
- Top-Verursacher finden (Transients, große Arrays, Plugin-Reste)
- SQL-Checks für Größe, Anzahl und Top-Einträge
- Gezielt auf autoload=’no‘ setzen oder löschen
- Monitoring und monatliche Pflege etablieren
Ich halte die Liste bewusst schlank und fokussiert, damit du sofort die größten Hebel erkennst. Jede Maßnahme zahlt direkt auf spürbare Ladezeiten ein. Die Schritte lassen sich sicher testen und bei Bedarf wieder zurückdrehen. Ich verbinde Analyse, Bereinigung und Monitoring in einem klaren Ablauf. So erreichst du nachhaltig schnelle Seitenaufrufe.
Warum Autoload-Daten die Performance bremsen
Bei jedem Request lädt WordPress alle Optionen mit autoload=’yes’ in den Speicher – unabhängig davon, ob dein Theme oder ein Plugin sie gerade benötigt. Wächst die Summe dieser Werte auf mehrere Megabyte, steigen Latenz, TTFB und RAM-Bedarf deutlich. Besonders große serialisierte Arrays, veraltete Transients und Reste deinstallierter Plugins blähen die Autoload-Menge auf. Das führt zu unnötiger Arbeit für PHP und MySQL und macht gerade das Backend spürbar träge. Ich priorisiere daher alles, was bei jedem Seitenaufruf in den Speicher wandert, und entferne systematisch den Ballast.
Ist-Stand messen: Größe und Anzahl schnell prüfen
Bevor ich etwas ändere, ermittle ich die aktuelle Datenlage der automatisch geladenen Optionen in der wp_options-Tabelle. Dafür nutze ich eine einfache SQL-Abfrage zur Gesamtgröße und ergänze sie um die Anzahl der Einträge. Das Ergebnis übersetze ich in MB, setze mir Ziele und plane die nächsten Schritte. Liegt die Summe über 1–2 MB oder die Anzahl deutlich über 500, starte ich eine fokussierte Analyse. Schon dieser erste Blick schafft Klarheit und legt die Prioritäten fest.
-- Gesamtgröße (Bytes) der Autoload-Daten
SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';
-- Anzahl der Autoload-Einträge
SELECT COUNT(*) AS autoload_count
FROM wp_options
WHERE autoload = 'yes';
Kritische Einträge erkennen und priorisieren
Ich identifiziere zuerst die größten Brocken, denn wenige Optionen verursachen oft den Großteil der Last. Häufig finde ich Transients (_transient_*, _site_transient_*), Rollen-Definitionen (_user_roles_) oder Logs und Statistiken von Plugins, die nicht ständig gebraucht werden. Auch WooCommerce- oder SEO-Plugins speichern gern ausufernde Arrays. Alles über 100–200 KB pro Option schaue ich mir genau an, Transients über 50 KB entferne ich konsequent. Wer tiefer einsteigen will, kann meinen weiterführenden Datenbank-Tuning-Boost als zusätzlichen Leitfaden nutzen, um die Reihenfolge der Maßnahmen sinnvoll abzuarbeiten.
-- Top-Verursacher in MB sichtbar machen
SELECT option_name, autoload,
ROUND(LENGTH(option_value) / 1024 / 1024, 2) AS size_mb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_mb DESC
LIMIT 20;
Vertiefte Analyse: Muster, Präfixe und Serialisierung
Um zielgerichtet aufzuräumen, zerschneide ich die Autoload-Menge nach Präfixen und Datenformen. So sehe ich schnell, welche Plugins oder Funktionsbereiche besonders stark beitragen und ob große, serialisierte Arrays dominieren. Serialisierte Daten erkenne ich an einem Startmuster wie a:... (Array) oder O:... (Objekt). Große, verschachtelte Arrays sind typische Kandidaten für autoload=no oder eine Aufteilung in kleinere Einheiten.
-- Verteilung nach (einfachen) Präfixen
SELECT
SUBSTRING_INDEX(option_name, '_', 1) AS prefix,
COUNT(*) AS cnt,
ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS size_mb
FROM wp_options
WHERE autoload = 'yes'
GROUP BY prefix
ORDER BY size_mb DESC
LIMIT 20;
-- Große serialisierte Arrays identifizieren
SELECT option_name,
LENGTH(option_value) AS len
FROM wp_options
WHERE autoload = 'yes'
AND option_value REGEXP '^a:[0-9]+:'
ORDER BY len DESC
LIMIT 20;
-- JSON-artige Inhalte prüfen (nur grober Filter)
SELECT option_name,
LENGTH(option_value) AS len
FROM wp_options
WHERE autoload = 'yes'
AND option_value LIKE '{%'
ORDER BY len DESC
LIMIT 20;
Findest du mehrere sehr große Optionen eines Plugins, ist meist die Speicherstrategie das Problem (z. B. Caches oder Logs in einer einzigen Option). Das lässt sich oft entschärfen: Daten aufteilen, nicht benötigte Teile löschen, oder per Plugin-Einstellung die Protokollierung reduzieren.
Gezielt bereinigen: Transients, Autoload=no, verwaiste Optionen
Bei veralteten Transients lösche ich abgelaufene Einträge, denn sie belegen oft unnötig Speicher. Große, selten genutzte Optionen stelle ich auf autoload=’no’ um und teste die Funktion der Seite direkt danach. Finde ich Spuren von entfernten Plugins, räume ich deren Präfixe kontrolliert aus der wp_options-Tabelle auf. Jeder Schritt erfolgt mit aktuellem Backup und klarer Rückfallebene, damit du jederzeit sicher bist. So schrumpft die Autoload-Summe schnell und der TTFB profitiert.
-- Abgelaufene Transients entfernen (vorher Backup!)
DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
OR option_name LIKE '_site_transient_%';
-- Einzelne große Option vom Autoload befreien
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'BEISPIEL_OPTION';
-- Verwaiste Plugin-Optionen mit erkennbarem Präfix löschen
DELETE FROM wp_options
WHERE option_name LIKE 'altplugin_%';
Sicher löschen statt blind entfernen
Wenn ich nur abgelaufene Transients entsorgen will, nutze ich gezielte Abfragen, die die Timeout-Optionen berücksichtigen. Das ist schonender und reduziert Seiteneffekte beim Caching. Alternativ erledigt WP‑CLI die Aufgabe mit einem einzigen Befehl.
-- Nur abgelaufene (Site-)Transients löschen (sicherer)
DELETE a, b
FROM wp_options a
JOIN wp_options b
ON b.option_name = REPLACE(a.option_name, '_transient_', '_transient_timeout_')
WHERE a.option_name LIKE '_transient_%'
AND a.option_name NOT LIKE '_transient_timeout_%'
AND b.option_value < UNIX_TIMESTAMP();
DELETE a, b
FROM wp_options a
JOIN wp_options b
ON b.option_name = REPLACE(a.option_name, '_site_transient_', '_site_transient_timeout_')
WHERE a.option_name LIKE '_site_transient_%'
AND a.option_name NOT LIKE '_site_transient_timeout_%'
AND b.option_value < UNIX_TIMESTAMP();
-- WP‑CLI (empfohlen): abgelaufene Transients entfernen
# Einzel-Site
wp transient delete --expired
# Multisite-weit
wp transient delete --expired --network
Für einen Rollback sichere ich die größten Optionen vorab separat: Namen sammeln, Inhalte exportieren, Änderungen protokollieren. So kann ich im Problemfall einzelne Werte binnen Sekunden zurückspielen.
# Top-50-Autoload-Namen exportieren
wp db query "
SELECT option_name
FROM wp_options
WHERE autoload='yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 50
" --skip-column-names > big_options.txt
# Inhalte sichern (einfaches Textformat)
while read -r NAME; do
printf '=== %s ===n' "$NAME" >> backup_options.txt
wp option get "$NAME" >> backup_options.txt
done < big_options.txt
Tabellenpflege und Speicherhygiene
Nach der Bereinigung optimiere ich die Tabelle, damit gelöschte Datenblöcke frei werden und die Datenbank wieder effizient arbeitet. Dieser Schritt reduziert Fragmentierung und hilft MySQL bei kommenden Abfragen. Anschließend prüfe ich erneut die Autoload-Größe, damit der Erfolg messbar bleibt. Optional beschleunigt ein Object Cache wie Redis oder Memcached das Laden verbleibender Optionen zusätzlich. Auch ohne Cache spürst du den Effekt sofort, weil weniger Daten pro Request in den RAM wandern.
-- Speicher freigeben und Statistiken aktualisieren
OPTIMIZE TABLE wp_options;
Automatisieren mit Tools und WP‑CLI
Auf wiederkehrenden Installationen spare ich Zeit mit ausgewählten Tools und Skripten. WP-CLI ermöglicht mir Massenupdates, etwa um mehrere große Optionen auf autoload=’no’ zu setzen und direkt zu prüfen. Für das regelmäßige Bereinigen von Transients und das Optimieren von Tabellen nutze ich schlanke Plugins mit klarer Protokollierung. Vor jeder Automatisierung dokumentiere ich die Ausgangswerte, damit ich Nutzen und Risiko abwägen kann. Wer mehr Tempo aus der wp_options herausholen will, findet unter Performance-Tuning der wp_options zusätzliche Ideen für die sinnvolle Kombination aus Analyse und Skripting.
# Beispiel: Liste großer Optionsnamen durchgehen und Autoload deaktivieren
while read -r NAME; do
wp option update "$NAME" "$(wp option get "$NAME")" --autoload=no
done < names.txt
Monitoring und Prävention: TTFB und RAM im Blick
Nach dem Aufräumen etabliere ich eine einfache Routine, damit die Autoload-Summe nicht wieder ansteigt. Ein monatlicher Check der Gesamtgröße, ergänzt um die Top-10-Optionen, reicht oft aus. Steigt der Wert deutlich, prüfe ich zuletzt installierte Plugins und deren Einstellungen. Parallel beobachte ich TTFB, PHP Memory Usage und Datenbankzeit, um Verbesserungen sichtbar zu machen. Auf gutem Hosting wirken diese Maßnahmen stärker, weil die I/O-Performance die Gewinne zusätzlich verstärkt.
Schwellenwerte und Maßnahmen auf einen Blick
Für die Einordnung der nächsten Schritte nutze ich klare Grenzen, die zügige Entscheidungen ermöglichen. So priorisiere ich zuerst die größten Verursacher, ohne Zeit mit unkritischen Einträgen zu verlieren. Die Tabelle zeigt dir typische Schwellwerte und meine Standardreaktion darauf. Sie ersetzt keine Analyse, aber sie gibt dir Handlungssicherheit für die ersten Runden. Wer tiefer einsteigt, kann anschließend feiner justieren und die Kontrollen verdichten.
| Typ | Schwellwert | Aktion |
|---|---|---|
| Gesamte Autoload-Größe | < 1–2 MB | Beibehalten, monatlich prüfen |
| Gesamte Autoload-Größe | 2–5 MB | Größte 10 Optionen prüfen, Transients bereinigen |
| Gesamte Autoload-Größe | > 5 MB | Sofortige Reduktion anstreben, Autoload=no für selten genutzte Optionen |
| Einzelne Option | > 100–200 KB | Ursache prüfen, ggf. auf Autoload=no setzen |
| Transients | > 50 KB | Löschen, später mit sauberem Cache neu erzeugen lassen |
Risiken vermeiden und sicher testen
Ich ändere kritische Optionen niemals ohne frisches Backup und ohne Plan für den Rückweg. Vor dem Löschen prüfe ich, ob es sich um zentrale Core-Optionen wie siteurl oder home handelt, denn diese fasse ich nicht an. Nach jeder Änderung lade ich Frontend und Backend in einer frischen Session, um Seiteneffekte früh zu erkennen. Bei Problemen stelle ich den vorherigen Zustand aus der Sicherung wieder her und gehe kleinschrittiger vor. So bleibt die Optimierung kontrollierbar, und du bewahrst die Stabilität deiner Installation.
Praxisbeispiel: Von träge zu reaktionsschnell
In einer Installation mit über 20 MB Autoload-Daten habe ich zuerst große Transients entfernt und dann drei sperrige Optionen auf autoload=no gesetzt. Nach einem OPTIMIZE TABLE fielen TTFB und Backend-Wartezeiten sichtbar, ohne dass Funktionen ausfielen. Im Anschluss reduzierte ich verwaiste Plugin-Reste, die nach Deinstallationen verblieben. Die erneute Messung zeigte eine Autoload-Summe nahe 2 MB, was die Seiten spürbar beschleunigte. Jede Aktion war messbar, reversibel und brachte sofort Vorteile.
Core-Optionen und typische Stolperfallen
Neben offensichtlichen Brocken gibt es Optionen, die du besonders vorsichtig behandelst. Dazu zählen siteurl, home, active_plugins, stylesheet/template, permalink_structure, rewrite_rules, cron und wp_user_roles. Einige davon sind groß (z. B. rewrite_rules) und häufig autoload=’yes’. Ich reduziere deren Größe, aber entkopple sie nicht leichtfertig vom Autoload. Bei ungewöhnlich großen rewrite_rules prüfe ich Custom Post Types, Taxonomien und Plugins mit eigenen Rewrites und räume auf, statt nur am Symptom zu arbeiten. Ist cron aufgebläht, deaktiviere ich doppelte Events und bereinige Hooks; ein bloßes Umstellen auf autoload=no löst die Ursache nicht.
Entwickler-Best-Practices: Optionen richtig einsetzen
Viele Autoload-Probleme entstehen bereits in der Entwicklung. Meine Leitlinien:
- Ephemere Daten (Caches, Ergebnisse, temporäre Listen) in Transients speichern und möglichst nicht autoloaden.
- Große Strukturen in kleinere, gezielte Optionen zerlegen; keine Megabyte-großen „Sammelcontainer“.
add_option( $name, $value, '', 'no' )nutzen, wenn etwas nicht bei jedem Request gebraucht wird.- Keine Logs oder Debug-Dumps in Optionen parken; dafür eigene Tabellen oder Files/Observability verwenden.
- Statt serialisierter Riesen-Arrays ggf. auf mehrere Optionen oder eine eigene Tabelle ausweichen – besseres Teil-Loading.
- Exakte Invalidierung: Caches gezielt löschen statt „clear all“. Das hält Daten klein und stabil.
// Beispiel: Option bewusst ohne Autoload anlegen
add_option( 'mein_plugin_cache', $daten, '', 'no' );
// Sicherstellen, dass große Arrays nicht unnötig wachsen
update_option( 'mein_plugin_cache', array_slice( $daten, 0, 1000 ), false );
Object Cache: Nutzen und Grenzen
Ein persistenter Object Cache (Redis/Memcached) reduziert Datenbank-Last, aber er beseitigt keine Autoload-Bloat. Große Autoload-Summen wandern dann eben direkt aus dem Cache in den PHP-Speicher. Das spart Queries, erhöht aber weiterhin RAM-Bedarf und Deserialisierungsarbeit. Darum gilt: Erst reduzieren, dann cachen. Nach Aufräumen einmal den Cache leeren, damit sich saubere, kleinere Datensätze aufbauen.
Indizes, Engine und Integrität der wp_options
Standardmäßig existieren sinnvolle Indizes auf option_name und autoload. Bei manuell migrierten Installationen wurden diese vereinzelt entfernt oder beschädigt. Ich prüfe die Indizes und setze sie bei Bedarf neu. Zudem achte ich auf InnoDB als Storage Engine und ein passendes Row-Format, damit große Werte effizient ausgelagert werden können.
-- Indizes prüfen
SHOW INDEX FROM wp_options;
-- (Nur falls fehlend!) Index auf autoload neu anlegen
CREATE INDEX autoload ON wp_options (autoload);
-- (Optional) Auf InnoDB und modernes Row-Format umstellen
ALTER TABLE wp_options ENGINE=InnoDB, ROW_FORMAT=DYNAMIC;
Wichtig: Strukturänderungen nur mit Backup und Wartungsfenster durchführen. Oft reicht bereits die Autoload-Reduktion plus OPTIMIZE TABLE, um deutliche Effekte zu erzielen.
Fehlersuche bei Regress: Messbar vorgehen
Nach Änderungen beobachte ich gezielt folgende Kennzahlen pro Request: TTFB, Query-Anzahl/-Zeit, Peak Memory und PHP-Ausführungszeit. Für tiefe Analysen lohnt sich ein kurzzeitig aktiviertes Slow-Query-Log auf der Datenbank und – auf Entwicklungsumgebungen – ein Profiler. Wichtig ist, jede Änderung isoliert zu testen: erst Transients, dann einzelne große Optionen, anschließend Tabellenpflege.
-- Beispiel: Abfragen zu Autoload-Optionen im Log sichtbar machen
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 0.2; -- 200ms
-- Nach Tests wieder deaktivieren
Sonderfälle: WooCommerce, SEO & Statistik-Plugins
E-Commerce- und Analyse-Plugins erzeugen häufig große Optionen (Produktindizes, Reports, Verlauf). Ich prüfe, ob Caches neu aufgebaut werden können, ob es Einstellungen für die Cache-Größe gibt und ob bestimmte Berichtsfunktionen wirklich ständig gebraucht werden. Bei WooCommerce lohnt ein Blick auf Sitzungs- und Bestands-Transients; bei SEO-Plugins achte ich auf Index- und Metadaten-Caches. Grundsatz: Funktion erhalten, Speicher begrenzen – lieber häufiger gezielt regenerieren als dauerhaft Riesenwerte autoloaden.
Staging, Rollout und wiederholbare Checks
Ich führe alle riskanteren Schritte zuerst auf einer Staging-Umgebung durch und sichere dort die konkrete Reihenfolge der Befehle. Dieses Playbook setze ich anschließend in der Produktion um. Für wiederkehrende Checks erstelle ich mir zwei Minireports: Gesamtgröße/Anzahl sowie Top-10-Größen. Das hält das Monitoring leichtgewichtig und sorgt für schnelle Reaktionen, wenn ein Plugin-Update die Autoload-Menge wieder anhebt.
# Quick-Report 1: Größe & Anzahl
wp db query "SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';"
wp db query "SELECT COUNT(*) FROM wp_options WHERE autoload='yes';"
# Quick-Report 2: Top-10
wp db query "
SELECT option_name, ROUND(LENGTH(option_value)/1024/1024,2) AS mb
FROM wp_options WHERE autoload='yes'
ORDER BY mb DESC LIMIT 10;
"
Feinjustierung: Multisite und Netzwerkweite Daten
In Multisite-Setups prüfe ich zusätzlich die wp_sitemeta-Tabelle, weil dort netzwerkweite Einstellungen liegen. Große Einträge dort verhalten sich ähnlich und können mehrere Sites ausbremsen. Ich messe Summen und Top-Einträge, entscheide dann über Bereinigung und Autoload-Anteil pro Netzwerk. Die Prüfung geschieht getrennt je Site, damit lokale Besonderheiten nicht untergehen. So halte ich auch größere Netzwerke reaktionsschnell und schütze gemeinsame Ressourcen.
-- Netzwerkweite Daten prüfen (Multisite)
SELECT SUM(LENGTH(meta_value)) AS network_meta_size FROM wp_sitemeta;
SELECT meta_key, LENGTH(meta_value) AS len
FROM wp_sitemeta
ORDER BY len DESC
LIMIT 10;
Weiterführende Hilfe für strukturierte Umsetzung
Wenn du das Vorgehen schrittweise umsetzen willst, nutze einen kompakten Leitfaden als Ergänzung zu deinen eigenen Notizen. Starte mit Messung, sichere ein Backup, bereinige Transients und prüfe danach schrittweise große Optionen. So hältst du Risiko überschaubar und siehst nach jeder Runde klare Verbesserungen. Für zusätzliche Struktur bietet sich dieser Überblick an: wp_options-Optimierung. Mit diesem Raster bleibst du konsequent und verlierst keine Schritte aus dem Blick.
Kurzbilanz: Die wichtigsten Hebel für schnelle Seiten
Ich halte die automatisch geladenen Optionen konsequent klein, räume Transients auf, stelle selten genutzte Brocken auf autoload=no und optimiere die Tabelle. Messung vor und nach jeder Runde macht die Wirkung sichtbar und schafft Sicherheit. Mit klaren Schwellwerten finde ich die größten Ursachen in Minuten und setze dort zuerst an. Ein einfaches Monitoring verhindert, dass die Autoload-Summe später wieder hochläuft. So bringe ich deine WordPress-Installation dauerhaft auf Tempo und stärke die Performance spürbar.
