English
DeutschAutoload in WordPress: Die Werte der autoload-Spalte und die Abfrage, die sie noch findet
Inhalt
Jede Seite dieses Blogs beginnt mit derselben Datenbankabfrage, abgeschickt bevor WordPress überhaupt weiß, welche Seite gefragt war: Es liest einen Satz Einstellungen, den es zu brauchen erwartet.
Welche Einstellungen dazugehören, entscheidet eine einzige Spalte namens autoload. Diese Spalte hat in den letzten Versionen neue Werte bekommen, und die Abfrage, die fast jede ältere Anleitung empfiehlt, liefert heute nichts mehr.
Was autoload wirklich tut
WordPress hält seine Einstellungen in einer einzigen Tabelle. Jede Zeile trägt einen Namen, einen Wert und einen Vermerk, ob der Wert automatisch mitkommen soll.
Der Vermerk spart Datenbankabfragen. Statt jede Einstellung bei Bedarf einzeln abzurufen, lädt WordPress alle für Autoload markierten Werte gemeinsam und hält sie für den Rest der Anfrage im Arbeitsspeicher.
Dieser Tausch hat einen Preis. Was den Vermerk trägt, reist bei jedem einzelnen Aufruf mit – auf Seiten, die es nie anrühren, bei Dateien, die über PHP ausgeliefert werden, bei jedem Besuch jedes Crawlers.
Drei Werte in der Spalte, vier gelten als geladen
Früher war die Spalte einfach. Dort stand yes oder no, und beides war unmissverständlich. Seit Version 6.6 stehen dort mehr Möglichkeiten.
on und off sind die ausdrücklichen Antworten: Irgendetwas hat verlangt, dass der Wert geladen wird, oder verlangt, dass er es nicht wird.
auto-on und auto-off heißen: Niemand hat gefragt, und WordPress hat entschieden.
auto heißt: Niemand hat gefragt, und WordPress hat auch nicht entschieden.
Welche Werte als geladen zählen, steht im Quelltext als Funktion wp_autoload_values_to_autoload(), und sie nennt vier davon: yes, on, auto-on und auto. Alles andere bleibt auf der Platte, bis etwas es beim Namen verlangt.
Warum die alte Abfrage nichts findet
Die Zeile, die in Anleitung um Anleitung auftaucht, lautet SELECT option_name FROM wp_options WHERE autoload = 'yes'.
Auf diese Seite angewandt liefert sie null Zeilen bei 1290 Optionen – während 155 dieser Optionen tatsächlich vor jeder Seite gelesen werden. Die Spalte führt hier nur off, on und auto. Der Wert yes kommt nirgends vor.
Gewarnt wird davor nicht. Es gibt keinen Fehler und keinen Hinweis, und ein leeres Ergebnis sieht genauso aus wie ein sauberer Befund. Eine auf diese Weise geprüfte Seite wirkt jahrelang, als hätte sie überhaupt keine geladenen Optionen.
Die Abfrage, die weiterhin trägt, nennt alle vier Werte: WHERE autoload IN ('yes','on','auto-on','auto').
Unentschieden heißt geladen
Der Wert auto ist der überraschende. Er hält fest, dass keine Entscheidung gefallen ist – und eine Option in diesem Zustand wird trotzdem geladen.
Der Weg durch den Quelltext ist kurz. Ein ausdrückliches true, on oder yes wird zu on. Ein ausdrückliches false, off oder no wird zu off. Wo nichts Ausdrückliches angegeben wurde, bekommt ein Filter das Wort: true wird zu auto-on, false zu auto-off, und gar keine Antwort zu auto.
Weil auto in der Ladeliste steht, hat Schweigen eine Richtung. Eine Option, die ohne ein Wort zum Autoload angelegt wurde, wird von da an vor jeder Seite gelesen. Auf dieser Seite befinden sich 55 Optionen in genau diesem Zustand.
Die Grenze bei 150.000 Bytes
Ein Filter kommt mit WordPress mit und tut nichts anderes, als auf die Größe zu achten. Wird ein Wert beim Serialisieren größer als 150.000 Bytes, lautet die Antwort auto-off, und die Option bleibt liegen.
Zwei Einzelheiten lohnen das Merken. Die Grenze ist selbst ein Filter, wp_max_autoloaded_option_size, ein Plugin kann sie also verschieben. Und sie greift nur dort, wo nichts Ausdrückliches gesagt wurde – eine von Hand auf on gesetzte Option wird geladen, wie groß sie auch ist.
In den Zahlen dieser Seite ist die Regel deutlich zu sehen. Keine geladene Option überschreitet hier 150.000 Bytes, während die größte Option der ganzen Tabelle – ein zwischengespeicherter Verzeichnisumfang von 102.403 Bytes – auf off steht und nie mitreist.
Was 155 Optionen wirklich kosten
Gemessen am 2. September 2026: 155 von 1290 Optionen werden vor jeder Seite gelesen, zusammen 122.435 Bytes, knapp unter 120 KB.
Wichtiger als die Summe ist die Verteilung. 145 der 155 sind kleiner als ein Kilobyte. Drei tragen zusammen 88.946 Bytes, also fast drei Viertel der ganzen Last.
Die mit Abstand größte ist cron mit 49.606 Bytes: 40 Prozent von allem Geladenen, in einer einzigen Zeile. Darin stehen 338 geplante Ereignisse, und 321 davon sind von einer einzigen Sorte – je ein publish_future_post für jeden Beitrag, der noch auf seinen Termin wartet.
Das ist kein Defekt, und kein Plugin trägt daran Schuld. Genau dafür gibt es die Option. Es bedeutet aber, dass ein Blog mit langem Redaktionsplan seinen gesamten Plan liest, bevor überhaupt eine Seite ausgeliefert wird – und dass dieses Gewicht mit dem Terminkalender wächst, nicht mit dem Verkehr. Gut zu wissen, bevor die Suche nach dem Schuldigen an ganz anderer Stelle beginnt.
Fragen und Antworten
Ändert ein persistenter Objektcache etwas an der Last der geladenen Optionen?
Er spart die Datenbankabfrage, nicht die Last. Mit einem Objektcache wie Redis oder Memcached legt WordPress den gesamten Satz geladener Optionen dort ab und holt ihn bei jedem Aufruf in einem Stück zurück, statt die Tabelle zu fragen. Im Arbeitsspeicher von PHP landen danach dieselben Werte wie ohne Cache, auf dieser Seite also weiterhin 122.435 Bytes je Aufruf, und der ganze Satz wird geladen, bevor die erste Zeile der Seite entsteht.
Eine Nebenwirkung verdient Beachtung: Der Satz liegt im Cache als ein einziger Eintrag. Wächst er, wächst dieser Eintrag mit, und Memcached nimmt in der Grundeinstellung keine Einträge über 1 MB an. Von dieser Grenze ist die Seite mit knapp 120 KB weit entfernt; ein Blog, dessen cron-Option mit dem Redaktionsplan wächst, sollte die Summe trotzdem im Blick behalten.
Lässt sich die cron-Option verkleinern, ohne geplante Beiträge zu gefährden?
Nur am Rand. Die 321 Einträge publish_future_post sind keine Altlast, sondern jeweils der Auftrag, einen wartenden Beitrag zu seinem Termin zu veröffentlichen. Fehlt der Eintrag, bleibt der Beitrag im Status future stehen, auch wenn sein Termin längst verstrichen ist. Im Mittel entfallen auf ein Ereignis knapp 147 Bytes (49.606 Bytes für 338 Ereignisse); jeder weitere eingeplante Beitrag macht die Option also um ungefähr diesen Betrag größer, und jede Veröffentlichung nimmt ihn wieder heraus.
Aufräumen lohnt sich bei den übrigen 17 Ereignissen. Dort bleiben gelegentlich wiederkehrende Aufgaben von Plugins zurück, die längst entfernt sind, weil ein Plugin seine geplanten Ereignisse beim Entfernen selbst abmelden muss und das nicht jedes tut. Selbst wenn alle 17 verzichtbar wären, brächte das bei durchschnittlicher Größe nur rund 2,5 KB.
Nichts ändert sich übrigens, wenn WP-Cron durch einen System-Cronjob angestoßen wird. Das betrifft nur, wer die fälligen Ereignisse auslöst; gespeichert und vor jeder Seite geladen wird die Liste weiterhin in derselben Option.
Setzt WordPress die Optionen eines deaktivierten Plugins auf off?
Nein. Deaktivieren lässt die Tabelle unberührt, und Optionen verschwinden erst, wenn das Plugin beim Löschen selbst aufräumt; eine Option, die ohne Angabe zum Autoload angelegt wurde, wird deshalb auch dann weiter vor jeder Seite gelesen, wenn ihr Plugin längst entfernt ist. Bei den 55 Optionen im Zustand auto verraten die Namensvorsilben meist, zu welchem Plugin eine Zeile gehört.
Passend dazu
