{"id":13556,"date":"2026-10-15T12:45:00","date_gmt":"2026-10-15T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13556"},"modified":"2026-10-09T23:11:48","modified_gmt":"2026-10-09T21:11:48","slug":"autoload-in-wordpress-die-werte-der-autoload-spalte-und-die-abfrage","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/wordpress-plugins-tricks-de\/tutorials-de-wordpress-plugins-tricks-de\/autoload-in-wordpress-die-werte-der-autoload-spalte-und-die-abfrage\/","title":{"rendered":"Autoload in WordPress: Die Werte der autoload-Spalte und die Abfrage, die sie noch findet"},"content":{"rendered":"

Jede Seite dieses Blogs beginnt mit derselben Datenbankabfrage, abgeschickt bevor WordPress \u00fcberhaupt wei\u00df, welche Seite gefragt war: Es liest einen Satz Einstellungen, den es zu brauchen erwartet.<\/p>\n

Welche Einstellungen dazugeh\u00f6ren, entscheidet eine einzige Spalte namens autoload<\/code>. Diese Spalte hat in den letzten Versionen neue Werte bekommen, und die Abfrage, die fast jede \u00e4ltere Anleitung empfiehlt, liefert heute nichts mehr.<\/p>\n

\n\"Zwei
Sieben Werte sind m\u00f6glich. Vier davon bedeuten: Die Option wird vor jeder Seite gelesen.<\/figcaption><\/figure>\n

Was autoload wirklich tut<\/h2>\n

WordPress h\u00e4lt seine Einstellungen in einer einzigen Tabelle. Jede Zeile tr\u00e4gt einen Namen, einen Wert und einen Vermerk, ob der Wert automatisch mitkommen soll.<\/p>\n

Der Vermerk spart Datenbankabfragen. Statt jede Einstellung bei Bedarf einzeln abzurufen, l\u00e4dt WordPress alle f\u00fcr Autoload markierten Werte gemeinsam und h\u00e4lt sie f\u00fcr den Rest der Anfrage im Arbeitsspeicher.<\/p>\n

Dieser Tausch hat einen Preis. Was den Vermerk tr\u00e4gt, reist bei jedem einzelnen Aufruf mit – auf Seiten, die es nie anr\u00fchren, bei Dateien, die \u00fcber PHP ausgeliefert werden, bei jedem Besuch jedes Crawlers.<\/p>\n

Drei Werte in der Spalte, vier gelten als geladen<\/h2>\n

Fr\u00fcher war die Spalte einfach. Dort stand yes<\/code> oder no<\/code>, und beides war unmissverst\u00e4ndlich. Seit Version 6.6 stehen dort mehr M\u00f6glichkeiten.<\/p>\n

on<\/code> und off<\/code> sind die ausdr\u00fccklichen Antworten: Irgendetwas hat verlangt, dass der Wert geladen wird, oder verlangt, dass er es nicht wird.<\/p>\n

auto-on<\/code> und auto-off<\/code> hei\u00dfen: Niemand hat gefragt, und WordPress hat entschieden.<\/p>\n

auto<\/code> hei\u00dft: Niemand hat gefragt, und WordPress hat auch nicht entschieden.<\/p>\n

Welche Werte als geladen z\u00e4hlen, steht im Quelltext als Funktion wp_autoload_values_to_autoload()<\/code>, und sie nennt vier davon: yes<\/code>, on<\/code>, auto-on<\/code> und auto<\/code>. Alles andere bleibt auf der Platte, bis etwas es beim Namen verlangt.<\/p>\n

Warum die alte Abfrage nichts findet<\/h2>\n

Die Zeile, die in Anleitung um Anleitung auftaucht, lautet SELECT option_name FROM wp_options WHERE autoload = 'yes'<\/code>.<\/p>\n

Auf diese Seite angewandt liefert sie null Zeilen bei 1290 Optionen – w\u00e4hrend 155 dieser Optionen tats\u00e4chlich vor jeder Seite gelesen werden. Die Spalte f\u00fchrt hier nur off<\/code>, on<\/code> und auto<\/code>. Der Wert yes<\/code> kommt nirgends vor.<\/p>\n

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\u00fcfte Seite wirkt jahrelang, als h\u00e4tte sie \u00fcberhaupt keine geladenen Optionen.<\/p>\n

Die Abfrage, die weiterhin tr\u00e4gt, nennt alle vier Werte: WHERE autoload IN ('yes','on','auto-on','auto')<\/code>.<\/p>\n

\n\"Eine
\n<\/figure>\n

Unentschieden hei\u00dft geladen<\/h2>\n

Der Wert auto<\/code> ist der \u00fcberraschende. Er h\u00e4lt fest, dass keine Entscheidung gefallen ist – und eine Option in diesem Zustand wird trotzdem geladen.<\/p>\n

Der Weg durch den Quelltext ist kurz. Ein ausdr\u00fcckliches true<\/code>, on<\/code> oder yes<\/code> wird zu on<\/code>. Ein ausdr\u00fcckliches false<\/code>, off<\/code> oder no<\/code> wird zu off<\/code>. Wo nichts Ausdr\u00fcckliches angegeben wurde, bekommt ein Filter das Wort: true wird zu auto-on<\/code>, false zu auto-off<\/code>, und gar keine Antwort zu auto<\/code>.<\/p>\n

Weil auto<\/code> 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.<\/p>\n

Die Grenze bei 150.000 Bytes<\/h2>\n

Ein Filter kommt mit WordPress mit und tut nichts anderes, als auf die Gr\u00f6\u00dfe zu achten. Wird ein Wert beim Serialisieren gr\u00f6\u00dfer als 150.000 Bytes, lautet die Antwort auto-off<\/code>, und die Option bleibt liegen.<\/p>\n

Zwei Einzelheiten lohnen das Merken. Die Grenze ist selbst ein Filter, wp_max_autoloaded_option_size<\/code>, ein Plugin kann sie also verschieben. Und sie greift nur dort, wo nichts Ausdr\u00fcckliches gesagt wurde – eine von Hand auf on<\/code> gesetzte Option wird geladen, wie gro\u00df sie auch ist.<\/p>\n

In den Zahlen dieser Seite ist die Regel deutlich zu sehen. Keine geladene Option \u00fcberschreitet hier 150.000 Bytes, w\u00e4hrend die gr\u00f6\u00dfte Option der ganzen Tabelle – ein zwischengespeicherter Verzeichnisumfang von 102.403 Bytes – auf off<\/code> steht und nie mitreist.<\/p>\n

Was 155 Optionen wirklich kosten<\/h2>\n

Gemessen am 2. September 2026: 155 von 1290 Optionen werden vor jeder Seite gelesen, zusammen 122.435 Bytes, knapp unter 120 KB.<\/p>\n

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.<\/p>\n

Die mit Abstand gr\u00f6\u00dfte ist cron<\/code> 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<\/code> f\u00fcr jeden Beitrag, der noch auf seinen Termin wartet.<\/p>\n

Das ist kein Defekt, und kein Plugin tr\u00e4gt daran Schuld. Genau daf\u00fcr gibt es die Option. Es bedeutet aber, dass ein Blog mit langem Redaktionsplan seinen gesamten Plan liest, bevor \u00fcberhaupt eine Seite ausgeliefert wird – und dass dieses Gewicht mit dem Terminkalender w\u00e4chst, nicht mit dem Verkehr. Gut zu wissen, bevor die Suche nach dem Schuldigen an ganz anderer Stelle beginnt.<\/p>\n

\n

Fragen und Antworten<\/h2>\n

\u00c4ndert ein persistenter Objektcache etwas an der Last der geladenen Optionen?<\/h3>\n

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\u00fcck zur\u00fcck, 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.<\/p>\n

Eine Nebenwirkung verdient Beachtung: Der Satz liegt im Cache als ein einziger Eintrag. W\u00e4chst er, w\u00e4chst dieser Eintrag mit, und Memcached nimmt in der Grundeinstellung keine Eintr\u00e4ge \u00fcber 1 MB an. Von dieser Grenze ist die Seite mit knapp 120 KB weit entfernt; ein Blog, dessen cron-Option mit dem Redaktionsplan w\u00e4chst, sollte die Summe trotzdem im Blick behalten.<\/p>\n

L\u00e4sst sich die cron-Option verkleinern, ohne geplante Beitr\u00e4ge zu gef\u00e4hrden?<\/h3>\n

Nur am Rand. Die 321 Eintr\u00e4ge publish_future_post sind keine Altlast, sondern jeweils der Auftrag, einen wartenden Beitrag zu seinem Termin zu ver\u00f6ffentlichen. Fehlt der Eintrag, bleibt der Beitrag im Status future stehen, auch wenn sein Termin l\u00e4ngst verstrichen ist. Im Mittel entfallen auf ein Ereignis knapp 147 Bytes (49.606 Bytes f\u00fcr 338 Ereignisse); jeder weitere eingeplante Beitrag macht die Option also um ungef\u00e4hr diesen Betrag gr\u00f6\u00dfer, und jede Ver\u00f6ffentlichung nimmt ihn wieder heraus.<\/p>\n

Aufr\u00e4umen lohnt sich bei den \u00fcbrigen 17 Ereignissen. Dort bleiben gelegentlich wiederkehrende Aufgaben von Plugins zur\u00fcck, die l\u00e4ngst entfernt sind, weil ein Plugin seine geplanten Ereignisse beim Entfernen selbst abmelden muss und das nicht jedes tut. Selbst wenn alle 17 verzichtbar w\u00e4ren, br\u00e4chte das bei durchschnittlicher Gr\u00f6\u00dfe nur rund 2,5 KB.<\/p>\n

Nichts \u00e4ndert sich \u00fcbrigens, wenn WP-Cron durch einen System-Cronjob angesto\u00dfen wird. Das betrifft nur, wer die f\u00e4lligen Ereignisse ausl\u00f6st; gespeichert und vor jeder Seite geladen wird die Liste weiterhin in derselben Option.<\/p>\n

Setzt WordPress die Optionen eines deaktivierten Plugins auf off?<\/h3>\n

Nein. Deaktivieren l\u00e4sst die Tabelle unber\u00fchrt, und Optionen verschwinden erst, wenn das Plugin beim L\u00f6schen selbst aufr\u00e4umt; eine Option, die ohne Angabe zum Autoload angelegt wurde, wird deshalb auch dann weiter vor jeder Seite gelesen, wenn ihr Plugin l\u00e4ngst entfernt ist. Bei den 55 Optionen im Zustand auto verraten die Namensvorsilben meist, zu welchem Plugin eine Zeile geh\u00f6rt.<\/p>\n<\/div>\n

\n

Quellen<\/h2>\n