Performance
Was WordPress mitlädt, ohne dass du es brauchst
Du hast Plugins ausgemistet.
10 Min. Lesezeit
Von Timo Wessels Veröffentlicht am
Du hast Plugins ausgemistet. Die Bilder sind kleiner. Die Schriften liegen auf dem eigenen Server. Und die Seite ist immer noch schwerer, als sie sein müsste.
Dann lohnt der Blick auf eine Schicht, die fast nie jemand ansieht: das, was WordPress selbst mitliefert. Nicht dein Theme, nicht deine Plugins — der Kern. Er bringt eine Reihe von Dateien und Kopfzeilen mit, die für Funktionen da sind, die viele Websites nie benutzen.
Das ist kein Fehler von WordPress. Es ist ein System, das nicht weiß, was du vorhast, und deshalb erst einmal alles bereitstellt. Die Entscheidung, was davon wirklich gebraucht wird, kann nur jemand treffen, der die Seite kennt.
Warum das überhaupt zählt
Jede Datei, die eine Seite lädt, ist eine eigene Anfrage. Der Browser muss sie anfordern, warten, empfangen, auswerten. Eine einzelne kleine Datei fällt nicht auf. Zwölf davon schon — besonders auf dem Handy, wo jede Verbindung teurer ist als am Schreibtisch.
Dazu kommt ein zweiter Effekt, der nichts mit Größe zu tun hat: Manches davon läuft im Hintergrund weiter, während der Besucher liest. Es fordert regelmäßig neue Daten vom Server an, ohne dass irgendjemand darauf wartet.
Und drittens gibt es Einträge im Kopfbereich der Seite, die gar nichts laden, sondern nur etwas verraten — welche Schnittstellen offenstehen, welche Version läuft, welche Dienste erreichbar sind. Die kosten keine Ladezeit, sind aber trotzdem Ballast.
Drei Gruppen, drei verschiedene Fragen
Es hilft, das Zeug nicht als eine Liste zu sehen, sondern als drei Gruppen. Für jede gilt eine andere Prüffrage.
Erstens: Funktionen, die du nicht benutzt. Hier lautet die Frage schlicht — kommt das auf meiner Website vor? Wenn nicht, kann es weg.
Zweitens: Sachen, die nur die Verwaltung braucht. Hier lautet die Frage — sieht das ein Besucher überhaupt? Vieles, was WordPress ausliefert, ist für dich im Backend gedacht und landet trotzdem bei jedem anonymen Leser.
Drittens: Sachen, die überall geladen werden, obwohl sie nur an einer Stelle gebraucht werden. Hier lautet die Frage — muss das auf jeder Seite sein? Das ist die interessanteste Gruppe, weil man hier selten etwas ganz abschaltet, sondern nur eingrenzt.
Gruppe eins: Funktionen, die du nicht benutzt
Die Emoji-Unterstützung. WordPress lädt auf jeder Seite ein kleines Skript und ein Stück Gestaltungsanweisung, damit Emojis auch in älteren Browsern gleich aussehen. Moderne Browser können das längst selbst. Wenn auf deiner Seite keine Emojis vorkommen — und auf den meisten Geschäftsseiten kommen keine vor —, wird hier etwas geladen, das nichts tut.
Die Einbettungs-Funktion. WordPress kann fremde Inhalte automatisch einbetten, wenn du eine Adresse in den Text schreibst — ein Video, ein Beitrag von anderswo. Dafür bringt es ein eigenes Skript mit und schreibt Erkennungs-Einträge in den Kopfbereich. Wer keine solchen Einbettungen nutzt, lädt es trotzdem.
Die Verweise auf Dienste, die niemand mehr benutzt. Im Kopfbereich einer Standard-WordPress-Seite stehen Einträge für längst eingestellte Blog-Werkzeuge — ein Verweis auf einen Editor aus den Zweitausendern, ein Erkennungslink für Dienste, die es nicht mehr gibt, ein Kurzlink, den fast niemand aufruft. Sie kosten keine Ladezeit, aber sie stehen dort ohne Grund.
Die Kommentarfunktion, wenn du keine Kommentare hast. Sind Kommentare abgeschaltet, braucht die Seite auch nichts dafür zu laden.
Selbst-Verweise beim Veröffentlichen. Verlinkst du in einem Beitrag auf eine eigene andere Seite, meldet WordPress das standardmäßig an sich selbst — ein Vorgang, der bei jeder Veröffentlichung Arbeit erzeugt und keinem nützt.
Fremde Profilbilder. WordPress holt Autorenbilder standardmäßig von einem externen Dienst. Das ist eine Verbindung zu einem fremden Server bei jedem Seitenaufruf, auf dem ein solches Bild vorkommt — mit allem, was das für den Datenschutz bedeutet. (Dazu gibt es einen eigenen Artikel über das, was vor der Einwilligung lädt.)
Gruppe zwei: Sachen, die nur die Verwaltung braucht
Die Symbolschrift des Backends. WordPress bringt eine eigene Schrift für die Symbole im Verwaltungsbereich mit. Auf vielen Seiten wird sie auch dann ausgeliefert, wenn ein anonymer Besucher die Seite aufruft — jemand, der den Verwaltungsbereich nie zu sehen bekommt. Eine komplette Schriftdatei für Symbole, die er nicht sieht.
Die Hintergrund-Verbindung. WordPress hält eine regelmäßige Verbindung zum Server offen. Sie ist dafür da, dass dir beim Schreiben eines Beitrags nichts verlorengeht und dass du gewarnt wirst, wenn jemand denselben Text bearbeitet. Im Verwaltungsbereich ist das nützlich und soll dort auch bleiben. Auf einer öffentlichen Seite, die nur gelesen wird, erzeugt sie regelmäßige Anfragen ohne Zweck.
Wichtig dabei: ganz abschalten ist der falsche Griff. Wer die Verbindung überall entfernt, verliert das automatische Zwischenspeichern beim Schreiben. Der richtige Weg ist, sie im öffentlichen Bereich wegzulassen und im Verwaltungsbereich zu behalten — oder ihren Takt zu verlangsamen statt sie zu beenden.
Die Anzeige der Passwortstärke. Das ist ein vergleichsweise großes Skript, das prüft, wie sicher ein eingegebenes Passwort ist. Gebraucht wird es bei der Registrierung und beim Zurücksetzen. Ausgeliefert wird es oft überall.
Die alte Kompatibilitätsschicht für JavaScript. WordPress bringt eine Hilfsdatei mit, die veralteten Code lauffähig hält. Wenn dein Theme und deine Plugins aktuell sind, braucht sie niemand.
Gruppe drei: überall geladen, an einer Stelle gebraucht
Diese Gruppe ist die interessanteste, weil man hier nichts abschaltet, sondern eingrenzt.
Die Gestaltungsanweisungen der Blöcke. Der Blockeditor liefert standardmäßig ein Stylesheet aus, das die Gestaltung aller Blocktypen enthält — auch derer, die auf der aktuellen Seite gar nicht vorkommen. Seit neueren WordPress-Versionen lässt sich das umstellen: Dann wird nur noch geladen, was auf dieser Seite tatsächlich verwendet wird. Auf Seiten mit wenigen Blöcken ist das eine der größten einzelnen Einsparungen im ganzen Kern.
Die zentralen Gestaltungsvorgaben des Themes. Block-Themes erzeugen aus ihrer Konfigurationsdatei einen Satz Gestaltungsvariablen und liefern ihn auf jeder Seite aus. Das lässt sich abschalten — aber nur, wenn ein anderes System diese Variablen vollständig bereitstellt. Andernfalls fehlen der Seite ihre Grundwerte, und die Gestaltung bricht.
Das ist der eine Punkt in diesem Artikel, bei dem ich zur Vorsicht rate: Hier hängt sichtbare Gestaltung dran, nicht nur unsichtbarer Ballast.
Die Falle: es sieht bei dir immer gut aus
Ein praktischer Punkt, der viele in die Irre führt.
Wer angemeldet ist, sieht die Website oft in einem anderen Zustand als ein anonymer Besucher. Manche Optimierungen greifen für angemeldete Nutzer bewusst nicht — damit ein Bearbeiter sieht, was wirklich im System steht, und nicht die zusammengeschnittene Fassung. Das ist richtig so, führt aber dazu, dass du beim eigenen Nachsehen den falschen Zustand misst.
Prüfe immer abgemeldet. Ein privates Browserfenster reicht.
Und was ist mit den Datenbank-Altlasten?
Zwei Einstellungen gehören in dieselbe Richtung, auch wenn sie nichts laden.
Beitragsversionen. WordPress speichert bei jedem Zwischenspeichern eine vollständige Kopie des Beitrags. Ohne Begrenzung sammeln sich davon über die Jahre hunderte an. Sie machen die Seite nicht langsamer beim Aufruf, aber sie blähen die Datenbank auf und verlängern jede Sicherung.
Das automatische Zwischenspeichern. Es läuft standardmäßig im Minutentakt. Ein etwas längerer Abstand reduziert die Schreibvorgänge spürbar, ohne dass jemand etwas verliert.
Wie du das selbst prüfst
Du brauchst dafür kein Werkzeug und keinen Zugang zum Server.
Der Blick in den Quelltext. Öffne deine Startseite in einem privaten Fenster, klicke mit der rechten Maustaste und wähle „Seitenquelltext anzeigen". Ganz oben steht der Kopfbereich. Lies ihn einmal durch. Alles, was dort steht und dir nichts sagt, ist ein Kandidat für die Frage: Wofür ist das da?
Der Netzwerk-Reiter. Drücke F12, wechsle auf „Netzwerk" und lade die Seite neu. Du siehst jede einzelne Datei, die geladen wird, mit Name und Größe. Sortiere nach Größe. Namen, in denen emoji, dashicons, heartbeat oder block-library vorkommen, sind genau die aus diesem Artikel.
Das ist die verlässlichere der beiden Prüfungen, weil sie zeigt, was tatsächlich geladen wurde — nicht nur, was im Quelltext angekündigt ist.
Zähl einfach mit. Wie viele Anfragen macht deine Startseite? Und wie viele davon kannst du einem Zweck zuordnen, den du tatsächlich anbietest?
Was zu tun ist — nach Hebelwirkung geordnet
Zuerst: die Blockgestaltung eingrenzen. Auf Seiten mit wenigen Blöcken ist das die größte einzelne Einsparung, und sie ist ungefährlich — es wird nur weggelassen, was auf der Seite nicht vorkommt.
Dann: die Symbolschrift für abgemeldete Besucher weglassen. Eine ganze Schriftdatei weniger, ohne dass sich für irgendjemanden etwas ändert.
Dann: die Hintergrund-Verbindung im öffentlichen Bereich beenden — aber im Verwaltungsbereich behalten.
Dann: die Funktionen, die du nicht benutzt — Emojis, Einbettungen, Passwortstärke, alte Kompatibilitätsschicht, Selbst-Verweise. Jedes einzelne ist klein, zusammen sind es mehrere Anfragen.
Dann: den Kopfbereich aufräumen. Kostet keine Ladezeit, macht die Seite aber ehrlicher darüber, was sie anbietet.
Zuletzt: Versionen begrenzen und den Speichertakt verlängern. Wirkt nicht auf die Ladezeit, sondern auf die Datenbank und auf die Dauer deiner Sicherungen.
Eine Warnung zum Schluss
Für all das gibt es Plugins, und einige davon sind gut. Aber der Reiz, alle Schalter auf einmal umzulegen, ist groß — und genau daraus entstehen die Fehler.
Jeder abgeschaltete Bestandteil ist ein Versprechen, dass ihn nichts braucht. Ein Theme kann die Symbolschrift für ein Menü verwenden. Ein Plugin kann die Einbettungsfunktion für seine Darstellung nutzen. Das merkt man nicht sofort, sondern zwei Wochen später an einer Stelle, die niemand mehr mit dem Schalter in Verbindung bringt.
Deshalb: einzeln umlegen, danach die Seite ansehen, abgemeldet. Und notieren, was du abgeschaltet hast — damit in einem Jahr noch jemand weiß, warum ein Detail fehlt.
Das ist die unspektakuläre Wahrheit an dieser Stelle. Es ist kein Trick und kein Geheimnis, sondern eine Liste, die jemand einmal geduldig durchgeht und dokumentiert.
Quellen
- Atlas,
wordpress/core/patterns/performance-toggles.md— dass die Emoji-Unterstützung aus einem Erkennungsskript im Kopfbereich, einer eingebetteten Gestaltungsanweisung und mehreren Filtern für Feeds und E-Mail besteht; dass die Einbettungsfunktion eine Route, mehrere Filter, zwei Kopfbereichs-Einträge und ein eigenes Skript umfasst; dass die alte JavaScript-Kompatibilitätsschicht nur außerhalb des Verwaltungsbereichs entfernt wird; dass die Symbolschrift für nicht angemeldete Besucher abgemeldet werden kann; dass die Hintergrund-Verbindung entweder ganz entfernt, im Takt verlangsamt oder außerhalb der Bearbeitungsseiten beendet werden kann, mit dem ausdrücklichen Hinweis, sie während einer laufenden Bearbeitung nicht abzuschalten; dass die Passwortstärke-Anzeige über ihre Vorbedingung entfernt wird; dass die Schnittstellen-Erkennung aus zwei Stellen kommt, einer im Kopfbereich und einer im Antwortkopf; dass Selbst-Verweise beim Veröffentlichen über die Adresse der eigenen Website gefiltert werden; dass sich die Gestaltungsanweisungen der Blöcke seit WordPress 6.9 auf die tatsächlich verwendeten Blöcke begrenzen lassen und das auf Seiten mit wenigen Blöcken eine deutliche Reduktion ergibt; dass das Abschalten der zentralen Theme-Gestaltungsvorgaben die Variablen aus der Konfigurationsdatei entfernt und nur zulässig ist, wenn ein anderes System sie vollständig bereitstellt; dass Optimierungen für angemeldete Nutzer bewusst übersprungen werden; sowie die Begrenzung der Beitragsversionen und die Verlängerung des automatischen Speichertakts. - Eigene Prüfliste
page-speed-tune-wp-core— die Zusammenstellung der Schalter mit ihren Voreinstellungen, darunter das Entfernen der Emoji-Unterstützung, das Verlangsamen der Hintergrund-Verbindung auf 60 Sekunden als Standardweg gegenüber dem vollständigen Abschalten, das Entfernen von Kurzlink, Editor-Erkennung, Manifest-Verweis, Schnittstellen-Verweis, Einbettungs-Erkennung, Vor- und Zurück-Verweisen und Feed-Verweisen aus dem Kopfbereich, das Unterbinden der Selbst-Verweise, das Ersetzen des externen Profilbild-Dienstes durch ein leeres Bild, das Abschalten der Passwortstärke-Anzeige und die Begrenzung der Beitragsversionen — sowie die Feststellung, dass diese Ebene auf jedem Aufbau sicher ist, weil sie weder von einem Plugin noch von einem Theme abhängt. - Udemy, WordPress Speed Optimization & Core Web Vitals, Abschnitt 4 — die Grundeinstellungen, die in der Praxis zuerst umgelegt werden: Entfernen der alten JavaScript-Kompatibilitätsschicht, Verbergen der Versionsangabe, Entfernen von Kurzlink und Editor-Erkennung, Abschalten der Feeds und Selbst-Verweise wenn ungenutzt, Abschalten der Schnittstelle für abgemeldete Besucher, Entfernen der Schnittstellen-Verweise, Abschalten der Passwortstärke-Anzeige, Begrenzung der Beitragsversionen, Verlängerung des Speichertakts auf fünf Minuten, Beibehalten der Kommentare bei gleichzeitigem Entfernen der Kommentar-Adressfelder, sowie der Hinweis, das Abschalten weiterer Funktionen vorher mit dem Betreiber abzustimmen. Ebenso die Beobachtung aus dem Skript-Verwalter, dass Skripte einzelner Bereiche auf Seiten mitlaufen, auf denen ihre Funktion nicht vorkommt.
- Eigene Prüfpraxis — der Ablauf der Selbstprüfung über Quelltext und Netzwerk-Reiter, die Notwendigkeit, abgemeldet zu prüfen, die Reihenfolge nach Hebelwirkung, und die Erfahrung, dass Schalter einzeln umgelegt und dokumentiert gehören, weil ein abgeschalteter Bestandteil erst Wochen später an anderer Stelle auffällt.