WordPress ist nicht langsam, aber es baut jede Seite bei jedem Aufruf serverseitig zusammen, sofern kein Cache davor liegt. Zusammen mit den üblichen Beigaben, also einem Theme mit vielen Funktionen, einem Pagebuilder und mehreren Fremdskripten, entsteht der Ruf.
Die gute Nachricht: Die Ursachen sind fast immer dieselben vier, und sie lassen sich in dieser Reihenfolge abarbeiten.
Reihenfolge nach Wirkung
1. Bilder
Bei einer typischen Seite der größte Posten. Drei Schritte, in dieser Folge:
- Vor dem Hochladen auf die benötigte Pixelbreite verkleinern. Kein Plugin kann das nachholen: Ein 4.000 Pixel breites Foto, das mit 800 Pixel dargestellt wird, bleibt 4.000 Pixel breit.
- In ein modernes Format überführen, üblicherweise WebP. Ein Plugin übernimmt das beim Hochladen.
- Verzögertes Laden für alles unterhalb des ersten Bildschirms, ausdrücklich nicht für das Hero-Bild.
Die Bildgrößen, die WordPress automatisch erzeugt, sollten zum tatsächlichen Layout passen. Standardwerte, die nicht zum Theme passen, führen dazu, dass zu große Varianten ausgeliefert werden. Details in Bilder optimieren.
2. Seiten-Cache
Die wirksamste Einzelmaßnahme auf der Serverseite. Statt bei jedem Aufruf PHP auszuführen und die Datenbank zu befragen, wird eine fertige HTML-Datei ausgeliefert.
Zwei Wege: ein Caching-Plugin, oder serverseitiges Caching beim Hoster. Bei Managed WordPress ist Letzteres üblich, dann ist ein Plugin überflüssig und kann sogar Konflikte erzeugen. Zwei Caching-Lösungen parallel sind eine bekannte Fehlerquelle.
Wichtig ist der Test nach der Aktivierung: Formulare, Warenkorb und Anmeldebereich dürfen nicht zwischengespeichert werden.
3. Skripte und Stilangaben begrenzen
Jedes Plugin lädt in der Regel eigene Stilangaben und Skripte auf jeder Seite, auch dort, wo es nicht gebraucht wird. Ein Formular-Plugin lädt sein Skript auf der Startseite, obwohl dort kein Formular steht.
Was hilft:
- Anzahl der Plugins reduzieren, siehe WordPress-Plugins
- Fremdskripte reduzieren: Chat-Widget, zweites Analysewerkzeug, Bewertungs-Widget
- Karten und Videos erst nach Klick laden, was gleichzeitig ein Datenschutzvorteil ist
- Nicht kritische Skripte verzögert ausführen
Die Fremdskripte sind auch der Hauptgrund für schlechte Werte bei der Reaktionsfähigkeit. Siehe Core Web Vitals.
4. Schriften
Zwei Familien mit den tatsächlich benutzten Schnitten, lokal ausgeliefert, mit passender Anzeigeeinstellung, damit Text sofort sichtbar ist. Ein Theme, das sechs Schriftschnitte von einem fremden Server lädt, verliert mehrere hundert Millisekunden und erzeugt eine datenschutzrechtliche Pflicht. Siehe Google Fonts lokal.
5. Theme und Pagebuilder
Die aufwendigste Maßnahme und deshalb die letzte, aber manchmal die einzige wirksame.
Der Test: eine leere Seite mit einer Überschrift und einem Absatz anlegen und die übertragene Datenmenge messen. Unter 200 Kilobyte für CSS und JavaScript ist gut. Über 800 Kilobyte bedeutet, dass das Theme Funktionen mitbringt, die immer geladen und nie gebraucht werden.
Ist das der Fall, hilft Optimierung nur begrenzt. Dann ist der Wechsel auf ein schlankes Theme mit dem Block-Editor die eigentliche Lösung, mit dem entsprechenden Aufwand. Siehe Theme auswählen.
6. Hosting
Relevant, wenn die Zeit bis zum ersten Byte hoch ist, also der Server lange braucht, bevor überhaupt etwas kommt. Prüfbar mit einem Ladezeittest, der diesen Wert einzeln ausgibt. Ursachen: begrenzte Prozesse im Tarif, veraltete PHP-Version, fehlendes OPcache, überbelegte Maschine.
Nicht relevant, wenn die Zeit bis zum ersten Byte gut ist und die Ladezeit an Bildern und Skripten hängt. Siehe Webhosting vergleichen.
Datenbank und Aufräumen
Weniger wirksam als oft behauptet, aber bei gewachsenen Installationen sinnvoll: Revisionen begrenzen, Papierkorb leeren, Kommentar-Spam entfernen, Tabellen verwaister Plugins prüfen.
Der Effekt auf die Ladezeit ist bei kleinen Seiten gering. Der Effekt auf Backup-Größe und Übersicht ist real.
Messen, nicht raten
Vor jeder Maßnahme ein Referenzwert, danach eine erneute Messung. Gemessen wird mobil und live, nicht im eigenen Browser mit gefülltem Cache.
Sinnvoll sind drei bis fünf Messungen, weil Einzelwerte je nach Serverlast schwanken. Und die Felddaten aus echten Besuchen sind aussagekräftiger als jeder Labortest. Details in Ladezeit messen.
Realistische Erwartung
Eine WordPress-Seite mit optimierten Bildern, aktivem Cache, zwei Schriftschnitten und ohne Fremdskripte erreicht auf einem normalen Shared Hosting gute Werte. Eine Seite mit schwerem Multipurpose-Theme, Pagebuilder, drei Fremdskripten und unoptimierten Bildern erreicht sie auf keinem Server.