WordPress Autoload: Warum wp_options deine Seite bremst

WordPress Autoload lädt bei jedem Seitenaufruf massenhaft Optionen aus der wp_options-Tabelle in den Speicher und treibt so TTFB, CPU- und RAM-Bedarf in die Höhe. Wenn sich hier zu viele autoloaded Daten sammeln, bremst genau diese Tabelle deine Seite spürbar aus.

Zentrale Punkte

Ich fasse die wichtigsten Fakten zusammen, damit du sofort einschätzen kannst, ob dich autoloaded Optionen ausbremsen. Bei jedem Request lädt WordPress alle Einträge mit autoload=yes, egal ob sie gebraucht werden. Das wirkt wie ein unsichtbarer Rücksack, der mit jedem installierten Plugin schwerer wird. Ab etwa 1 MB Autoload-Größe kippt die Performance schnell, was vor allem auf kleineren Hosts auffällt. Mit ein paar zielgerichteten Schritten reduziere ich die Last dauerhaft und halte die wp_options sauber.

• Autoload-Last: Alles mit autoload=yes kommt bei jedem Seitenaufruf in den Speicher.
• Kritische Größe: Ab ~1 MB steigt TTFB stark; 2–3 MB gelten als Alarmbereich.
• Haupttreiber: Plugins, Transients, Logs und fehlerhafte Cron-Jobs.
• Messung: SQL/WP‑CLI zeigt Größe und Top‑Verursacher sofort.
• Abhilfe: Aufräumen, Autoload auf „no“, auslagern, regelmäßig prüfen.

Warum Autoload bremst

Autoloaded Optionen landen bei jedem Request im Speicher, und zwar unabhängig davon, ob die Seite sie gerade braucht; genau das frisst Ressourcen. Kleine Werte fallen kaum auf, aber bei vielen Plugins wächst die Summe schnell auf hunderte Kilobyte oder sogar mehrere Megabyte. Ab rund 1 MB sehe ich regelmäßig steigende TTFB, langsamere Admin-Seiten und mehr CPU-Spitzen. Auf Shared-Hosting vervielfacht die Last, weil parallele Anfragen die database wordpress zusätzlich belasten. Je größer der Autoload-Block, desto länger dauert die Deserialisierung und desto mehr Zeit verschenkt dein Server vor dem ersten Byte.

Wie WordPress intern lädt (alloptions und Objekt‑Cache)

WordPress fasst alle autoloaded Optionen zu einem großen Block zusammen. Beim ersten Request wird dieser Block mit einem einzigen Query geladen und unter dem Sammelschlüssel alloptions im Objekt‑Cache abgelegt. Dadurch sinkt zwar die Anzahl der Datenbankabfragen, aber nicht die Menge der zu verarbeitenden Daten: Der gesamte Block muss deserialisiert und im Speicher gehalten werden. Mit einem Persistent Object Cache (z. B. Redis oder Memcached) verschwindet die Datenbanklast, doch die PHP‑Prozesse müssen die Daten weiterhin entpacken und in RAM halten. Heißt: Ein großer Autoload‑Block schadet auch dann, wenn die Daten aus dem Cache kommen – nur die Engstelle verlagert sich von der Datenbank zur CPU und zum Arbeitsspeicher.

Besonders kritisch ist dies bei:

• hoher Parallelität (viele gleichzeitige Requests): Jeder PHP‑Worker lädt den Block separat.
• kurzen Prozesslaufzeiten (FPM/Serverless): Der Overhead fällt auf jeden neuen Prozess erneut an.
• Admin‑Bereich und Cron: Caches werden häufiger umgangen oder invalidiert, der Autoload‑Block zählt jedes Mal.

So finde ich die größten Autoload-Übeltäter

Ich starte mit einer Größenmessung direkt in der wp_options. Die Summe hole ich mir per SQL: SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload = 'yes';. Werte über 1 MB sind kritisch, ab 2–3 MB wird es gefährlich, besonders bei Traffic. Danach sortiere ich nach Größe: SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload = 'yes' ORDER BY bytes DESC LIMIT 20;. So identifiziere ich große Arrays, alte Transients und Plugin-Einträge, die oft gar nicht autoloaded sein müssten; eine kurze Schritt-für-Schritt-Anleitung hilft dabei, die Ergebnisse sicher zu bewerten.

Erweiterte Diagnose: Zählen, gruppieren, Muster erkennen

Zur Vertiefung prüfe ich neben der Gesamtgröße auch Anzahl und Herkunft der Einträge:

• Anzahl autoloaded Optionen: SELECT COUNT(*) FROM wp_options WHERE autoload='yes';
• Top‑Namespaces (heuristisch über Präfixe): SELECT SUBSTRING_INDEX(option_name,'_',1) AS ns, COUNT(*) AS cnt, SUM(LENGTH(option_value)) AS bytes FROM wp_options WHERE autoload='yes' GROUP BY ns ORDER BY bytes DESC LIMIT 10;
• Transients, die fälschlich autoloaded sind: SELECT option_name FROM wp_options WHERE autoload='yes' AND option_name LIKE '_transient_%' ESCAPE '';

Mit diesen Abfragen finde ich schnell z. B. Statistik‑Caches, Page‑Builder‑Artefakte oder Log‑Reste. Muster sind oft klar erkennbar: mehrere Tausend kleine Einträge von einem Analytics‑Plugin oder wenige sehr große Arrays eines Builders.

Grenzwerte und Maßnahmen

Zur schnellen Einschätzung nutze ich feste Schwellen und ordne daraus die nächsten Schritte ab. So treffe ich Entscheidungen, ohne Zeit mit Bauchgefühl zu verlieren. Die Tabelle hilft beim Einordnen und gibt klare Handlungsoptionen je Bereich. Ich halte mich daran, weil sie in vielen Projekten zuverlässig funktioniert. Gerade bei knappen Ressourcen bringt sie Klarheit in weniger als einer Minute.

Autoload-Größe	Risiko	Empfohlene Maßnahme
0–500 KB	niedrig	Status dokumentieren, gelegentlich prüfen
500 KB–1 MB	mittel	Größte Einträge prüfen, unnötige löschen
> 1 MB	hoch	Top-Verursacher identifizieren, Autoload-Flag auf „no“
> 2–3 MB	kritisch	Systematische Bereinigung, Transients entfernen

Sicher bereinigen: Schritt für Schritt

Vor jeder Änderung sichere ich die Datenbank, denn ein vollständiges Backup schützt mich vor Fehlern. Mit WP‑CLI geht das fix: wp db export. Ich lösche abgelaufene Transients: wp transient delete --expired und nur falls nötig alle: wp transient delete --all. Verwaiste Plugin-Optionen entferne ich gezielt, etwa mit wp option delete my_plugin_option. Für große Einträge, die nicht autoloaded sein müssen, setze ich das Flag um: wp option update option_name 'value' --autoload=no; danach prüfe ich das Frontend und das Backend gründlich.

Sicherheitsnetz, Tests und Rollback

Nach jeder Änderung prüfe ich diese Bereiche in dieser Reihenfolge: Startseite (als Gast), eine tiefe Unterseite, Login/Logout, Admin‑Dashboard und das Speichern eines Beitrags. Zusätzlich triggere ich Cron: wp cron event run --due-now und schaue ins Error‑Log. Falls etwas bricht, setze ich gezielt zurück: wp option update option_name 'value' --autoload=yes oder stelle das Backup ein. Bei großen Arrays exportiere ich vorab deren Inhalt mit wp option get option_name > backup.json, so kann ich ihn jederzeit wiederherstellen.

Was ich nicht auf „autoload=no“ setze

Einige Optionen nutzt WordPress extrem früh im Bootstrap oder bei jeder Request‑Verarbeitung. Deren Autoload‑Flag ändere ich nicht blind, selbst wenn sie groß sind:

• siteurl, home: Basis‑URLs, früh benötigt.
• permalink_structure, rewrite_rules: Für die Request‑Auflösung essenziell; sind sie nicht in alloptions, folgen zusätzliche Datenbanktreffer.
• template, stylesheet: Theme‑Ermittlung.
• blog_charset, timezone_string und weitere Core‑Defaults.

Grundregel: Core‑Optionen und solche, die auf nahezu jedem Request gebraucht werden, lasse ich autoloaded. Ich konzentriere mich auf große, selten genutzte Plugin‑Einträge, Cache‑Artefakte, Logs und alte Transients.

Wenn Optionen groß bleiben müssen

Manche Daten dürfen groß sein, aber sie müssen nicht bei jedem Request im Speicher landen. Für umfangreiche Konfigurationen nutze ich eigene Tabellen statt wp_options; das hält die Autoload-Menge klein. Nutzerbezogene Informationen gehören in die User‑Meta, nicht in globale Optionen. Statische Inhalte wie lange CSS/JS‑Strings speichere ich als Datei und lade sie gezielt. Beim Speichern setze ich Autoload direkt auf „no“, etwa mit add_option('name', $data, '', 'no');, um unnötiges Laden zu vermeiden.

Entwicklerleitfaden: Muster, die skalieren

Als Entwickler vermeide ich riesige „Mega‑Optionen“, die alles in einem Array sammeln. Besser ist ein schmaler Core‑Satz (autoload=yes) plus gezielte Lazy‑Loads (autoload=no). Praktische Muster:

• Optionen splitten: my_plugin_core (klein, autoload=yes) und my_plugin_cache_* (groß, autoload=no).
• Gezielt cachen: Häufig benötigte Teilmengen mit wp_cache_set() zwischenspeichern statt große Optionen autoloaded zu lassen.
• Transients korrekt nutzen: Standardmäßig nicht autoloaded speichern und bewusst abrufen; nur sehr kleine, häufig gebräuchliche Transients autoloaded.
• Option‑Wachstum stoppen: Keine Logs oder unbounded Caches in Optionen ablegen; maximale Größe und TTL erzwingen.

Vorbeugen statt reparieren

Ich halte meine Plugins schlank und deaktiviere, was keinen klaren Nutzen bringt; so bleibt der Autoload‑Block klein. Einmal pro Monat kontrolliere ich die Größe mit SQL oder WP‑CLI und dokumentiere die Werte. Unter Werkzeuge > Website‑Zustand beobachte ich Hinweise zu automatisch geladenen Optionen. Für stark besuchte Sites lohnt sich Hosting, das die database wordpress effizient betreibt und wp_options sauber hält. Eine Sammlung erprobter Tuning-Strategien hilft mir, Probleme früh zu erkennen und gar nicht erst groß werden zu lassen.

Automatisierung: Kleine Jobs, große Wirkung

Ich plane eine regelmäßige Bereinigung ein. Ein nächtlicher Cron‑Job (oder ein Server‑Cron, der WP‑CLI ausführt) entfernt abgelaufene Transients und protokolliert die Autoload‑Größe in eine Datei oder Tabelle. So sehe ich Trends, bevor Nutzer sie spüren. Beispiel‑Ablauf (vereinfacht):

wp transient delete --expired
wp db query "SELECT NOW(), SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';" >> autoload_stats.log

Komfortabel ist ein kleiner Health‑Check, der die Top‑10‑Einträge mit Datum speichert. Ein Blick in das Log genügt, um Ausreißer zeitlich zuzuordnen – meist nach einem Plugin‑Update oder einer neuen Funktion.

Praxisbeispiel: 60 Minuten Cleanup

In einem Projekt fand ich 5.500 autoloaded Optionen mit zusammen rund 2 MB; die Seite lieferte den ersten Byte nach etwa 1.900 ms. Nach Backup, Transient‑Löschung, Top‑20‑Prüfung und Flag‑Anpassungen halbierte sich die Ladezeit auf etwa 500 ms. Die CPU‑Auslastung sank von 89 % auf ungefähr 2,5 %, das Backend reagierte deutlich schneller. Der Ablauf war simpel: messen, bereinigen, testen, dokumentieren. Genau diese Routine wende ich regelmäßig an, um das Wachstum der wp_options dauerhaft zu kontrollieren.

Typische Ursachen und Fixes

Page‑Builder schreiben gern große Cache‑Arrays in Optionen, die ich besser in Dateien ablege. Statistiken speichere ich als nicht-automatisch geladene Transients und rufe sie gezielt ab. Logs gehören in rotierende Dateien, nicht in wp_options. Fehlgeschlagene Cron‑Jobs verursachen alte Transients; hier passe ich Intervalle und Zeitouts an. Durch diese einfachen Änderungen sinkt die Autoload‑Menge schnell und bleibt langfristig stabil.

Einfluss von Caches, FPC und Hosting

Ein vorgeschalteter Full‑Page‑Cache (FPC) schützt primär anonyme Besucher. Doch überall, wo der Cache umgangen wird – eingeloggte Nutzer, Warenkorb, Checkout, Admin, Cron, WP‑CLI – schlägt der Autoload‑Block voll durch. Ein schneller Datenbank‑Server kaschiert die I/O‑Last, aber CPU‑Zeit fürs Deserialisieren und RAM‑Verbrauch bleiben. Gerade auf kleinen Instanzen mit wenigen FPM‑Workern führt ein großer Autoload‑Block zu Warteschlangen und Zeitüberschreitungen, obwohl die Daten „aus dem Cache“ kommen. Ziel ist deshalb immer: den Block selbst klein halten, nicht nur die Quelle schneller machen.

Monitoring und Kennzahlen

Ich tracke TTFB, First Contentful Paint und Backend‑Ladezeit vor und nach jeder Bereinigung. Parallel dokumentiere ich die Autoload‑Größe, die Anzahl der autoloaded Optionen und die größten Einträge. Ein kleines Sheet mit Datum, Größe und TTFB reicht für klare Trends. Für die Pflege nutze ich monatlich die SQL‑Abfragen und eine kurze Datenbank pflegen‑Checkliste. So erkenne ich Ausreißer früh und halte die database wordpress dauerhaft schlank.

Multisite: Zwei Baustellen im Blick

In Multisite‑Setups gibt es Autoload‑Last sowohl je Site als auch auf Netzwerkebene. Ich prüfe daher die wp_options jeder Site (Tabellenpräfix pro Blog) und zusätzlich die Netzwerk‑Optionen. Große, global genutzte Arrays wirken sich auf alle Sites aus. Vorgehen wie im Single‑Setup: messen, Top‑Einträge identifizieren, große Werte auslagern oder auf autoload=no setzen, wenn sie nicht auf jedem Request gebraucht werden. Besonders im Netzwerk‑Admin macht sich eine Reduktion sofort bemerkbar.

Häufige Missverständnisse – kurz geklärt

• „Redis löst das Problem.“ Es reduziert die DB‑Queries, aber nicht die Größe des Autoload‑Blocks. CPU‑ und RAM‑Kosten bleiben.
• „FPC macht Autoload egal.“ Nicht für eingeloggte Nutzer, Cron und Admin. Dort entfällt der FPC‑Vorteil.
• „Alle Transients löschen ist gefährlich.“ Es ist sicher, führt nur zu neuem Aufbau. Gezielt und geplant einsetzen.
• „Ein großer Block ist ok, wenn es wenige Einträge sind.“ Entscheidend ist die Summe der Bytes und die Deserialisierung, nicht die Anzahl allein.

Testplan nach der Bereinigung

• Frontend: Startseite, zufällige Archiv‑ und Detailseite, als Gast und eingeloggter Nutzer.
• Funktionen: Suche, Kontaktformular, Warenkorb/Checkout (falls Shop).
• Admin: Dashboard, Beitragsliste, Speichern eines Beitrags/Produkts, Plugin‑Seite.
• Hintergrund: Geplante Cron‑Events ausführen, Error‑Log prüfen, TTFB stichprobenartig messen.

Zusammenfassung für schnelle Entscheidungen

Autoloaded Optionen sind ein leiser Performance‑Killer, den ich mit wenigen, klaren Schritten einfange. Ich messe die Größe, entferne alte Transients, setze unnötige Einträge auf autoload=no und lagere große Daten aus. Danach teste ich Frontend und Backend und notiere die Messpunkte. Mit einer Stunde Fokusarbeit reduziere ich die Autoload‑Last oft um 30–70 % und halbiere die Ladezeiten. Wer diese Routine monatlich wiederholt, hält die wp_options schnell und die Seite spürbar reaktionsfreudig.