WordPress schneller machen: Ladezeit gezielt optimieren
Warum WordPress langsam lädt und was wirklich hilft: Messen mit PageSpeed Insights, Cache, PHP-Version, Bilder, Plugins, Datenbank und ein langsames Backend im Überblick.
Von Maik Boche
WordPress wird schneller, wenn Sie zuerst messen und dann die Ebene angehen, die wirklich bremst: meist fehlender Page-Cache, eine veraltete PHP-Version, zu große Bilder, ein schwerer Page-Builder oder zu viele Plugins und Drittskripte. Mit PageSpeed Insights und den Core Web Vitals LCP, INP und CLS sehen Sie, wo Ihre Seite steht, und können jede Änderung überprüfen. Reicht die Konfiguration nicht mehr aus, liegt das Problem meist im Aufbau der Seite und nicht in einer einzelnen Einstellung.
Dieser Ratgeber geht die Ursachen Ebene für Ebene durch, zeigt konkrete Einstellungen und endet mit einer Checkliste. Ein eigener Abschnitt behandelt das langsame Backend, denn dort liegen die Ursachen oft woanders als im Frontend.
Erst messen: PageSpeed Insights und Core Web Vitals
Bevor Sie ein Plugin installieren oder eine Einstellung ändern, brauchen Sie einen Ausgangswert. Das kostenlose Werkzeug PageSpeed Insights von Google liefert zwei Arten von Daten. Laut der Google-Dokumentation basieren die Felddaten auf dem Chrome User Experience Report (CrUX) und spiegeln die Erfahrungen echter Nutzer der letzten 28 Tage wider. Die Labordaten erzeugt Lighthouse in einer simulierten Umgebung. Felddaten zeigen, wie die Seite wirklich erlebt wird, Labordaten helfen bei der Fehlersuche.
Die Schwellenwerte
Laut web.dev gelten nach aktuellem Stand (Oktober 2026) diese Werte als gut, gemessen am 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop:
| Kennzahl | Was sie misst | Guter Wert |
|---|---|---|
| LCP (Largest Contentful Paint) | wann der größte sichtbare Inhalt erscheint | höchstens 2,5 Sekunden |
| INP (Interaction to Next Paint) | wie schnell die Seite auf Klicks und Eingaben reagiert | höchstens 200 Millisekunden |
| CLS (Cumulative Layout Shift) | wie stark das Layout beim Laden springt | höchstens 0,1 |
Messen Sie nicht nur die Startseite, sondern auch eine typische Unterseite und einen Blogbeitrag. Oft lädt die Startseite ordentlich, während Seiten mit Slidern oder eingebetteten Videos deutlich schlechter abschneiden. Was hinter den drei Kennzahlen steckt, erklärt unser Beitrag Core Web Vitals für Unternehmenswebsites.
Für einen eigenen WordPress-Performance-Test reicht diese Kombination: PageSpeed Insights für den Überblick, die Netzwerkansicht der Entwicklerwerkzeuge im Browser für einzelne Dateien und die Antwortzeit des Servers beim ersten Aufruf ohne Cache.
Warum lädt WordPress so langsam? Die Ursachen nach Ebene
Ohne Cache rechnet WordPress jede Seite bei jedem Aufruf neu: PHP fragt die Datenbank ab, Theme und Plugins steuern ihren Teil bei. Jede Ebene kann bremsen.
Hosting und PHP-Version
Ein knapp bemessener Tarif mit wenig Rechenleistung verlängert die Zeit, bis der Server überhaupt antwortet. Dazu kommt die PHP-Version. Laut php.net werden nach aktuellem Stand (Oktober 2026) nur noch PHP 8.2 bis 8.5 unterstützt; aktiv weiterentwickelt werden 8.4 und 8.5, für 8.3 gibt es nur noch Sicherheitsupdates, für 8.2 nur noch bis Ende 2026. Ältere Versionen sind ohne Unterstützung. WordPress empfiehlt laut wordpress.org PHP ab 8.3. In der WordPress-Dokumentation zur Optimierung heißt es außerdem, dass neuere PHP-Versionen in der Regel bessere Leistung bringen.
Datenbank
Mit den Jahren sammeln sich Revisionen, Papierkorb-Einträge, verwaiste Daten gelöschter Plugins und abgelaufene temporäre Einträge. Besonders die Optionen-Tabelle wird zum Problem, wenn Plugins dort große Datenmengen ablegen, die bei jedem Seitenaufruf geladen werden.
Theme und Page-Builder
Ein Multipurpose-Theme oder ein visueller Page-Builder lädt eigene Skripte und Stylesheets oft auf jeder Unterseite, auch dort, wo die zugehörigen Elemente gar nicht vorkommen. Das HTML wird tief verschachtelt, was das Rendern verlangsamt.
Plugins
Nicht die Zahl der Plugins allein entscheidet, sondern was sie tun. Ein Plugin, das bei jedem Aufruf externe Daten abfragt oder Statistiken in die Datenbank schreibt, kostet mehr als zehn kleine. Die WordPress-Dokumentation nennt das Deaktivieren und Löschen unnötiger Plugins als ersten und einfachsten Schritt.
Bilder, Schriften und Drittskripte
Bilder in Kameragröße, mehrere Schriftschnitte von fremden Servern, Chat-Widgets, Karten, Videos und Tracking-Skripte gehören zu den häufigsten Bremsen im Frontend. Sie belasten vor allem LCP und INP. Wie Sie fremde Skripte einordnen, beschreibt unser Beitrag zu Drittanbieter-Skripten.
Konkrete Konfiguration
Page-Cache und Object-Cache
Laut der WordPress-Dokumentation speichern Caching-Plugins Seiten als statische Dateien und liefern diese aus, statt sie bei jedem Aufruf neu zu berechnen. Ein Page-Cache ist deshalb meist der größte einzelne Hebel für die Antwortzeit. Viele Hoster bieten ihn auch serverseitig an, dann brauchen Sie kein zusätzliches Plugin.
Der Object-Cache setzt eine Ebene tiefer an. Er hält laut WordPress-Dokumentation Ergebnisse teurer Abfragen in einem schnellen Speicher vor, zum Beispiel in Redis oder Memcached, und zwar über einzelne Aufrufe hinweg. Das hilft vor allem bei Seiten, die nicht aus dem Page-Cache kommen können, etwa im Backend, im Warenkorb oder für eingeloggte Nutzer.
PHP-Version anheben
Die PHP-Version stellen Sie meist im Kundenmenü des Hosters um. Prüfen Sie vorher unter Werkzeuge, Website-Zustand, ob WordPress Hinweise zu Ihrer Installation anzeigt, und testen Sie den Wechsel möglichst zuerst auf einer Kopie der Seite. Ein Plugin, das die neue Version nicht verträgt, kann sonst die ganze Seite anhalten.
Bilder: Größe, WebP und AVIF
Laden Sie Bilder in der Größe hoch, in der sie angezeigt werden, nicht in voller Kameraauflösung. Moderne Formate sparen zusätzlich Daten. Laut den Entwicklerhinweisen auf make.wordpress.org unterstützt WordPress WebP seit Version 5.8 und AVIF seit Version 6.5, sofern der Server das Format verarbeiten kann. Eine automatische Umwandlung beim Hochladen übernimmt WordPress selbst nicht, dafür gibt es Bildoptimierungs-Plugins oder Sie wandeln die Dateien vorher um. Hintergründe zu Formaten und srcset stehen in unserem Beitrag zur Bildoptimierung mit AVIF und WebP.
Lazy Loading
Seit WordPress 5.5 erhalten Bilder laut make.wordpress.org standardmäßig das HTML-Attribut loading=“lazy”, sofern Breite und Höhe angegeben sind. Bilder weiter unten laden dann erst, wenn sie in die Nähe des sichtbaren Bereichs kommen. Das große Bild ganz oben sollte dagegen sofort laden, weil es häufig das LCP-Element ist. Prüfen Sie das, wenn Ihr Theme oder ein Plugin Lazy Loading zusätzlich steuert.
Skripte verzögern und Schriften lokal einbinden
Skripte, die für den ersten Eindruck nicht gebraucht werden, etwa Chat, Karten oder Bewertungs-Widgets, können verzögert oder erst nach einer Interaktion geladen werden. Viele Performance-Plugins bieten dafür eine Option. Schriften binden Sie lokal ein und beschränken sich auf die Schnitte, die tatsächlich verwendet werden.
Datenbank aufräumen
Löschen Sie alte Revisionen, Spam-Kommentare, den Papierkorb und Tabellen von Plugins, die nicht mehr installiert sind. Die WordPress-Dokumentation empfiehlt außerdem, die Zahl der gespeicherten Revisionen zu begrenzen. Machen Sie vor jedem Aufräumen ein vollständiges Backup.
Heartbeat und Cron
Die Heartbeat-Schnittstelle ist laut WordPress-Entwicklerdokumentation ein eingebautes Polling, bei dem der Browser in Abständen zwischen 15 und 120 Sekunden Anfragen an den Server schickt. Sind viele Redakteure mit offenen Tabs eingeloggt, summiert sich das. Ein längeres Intervall entlastet den Server, sollte aber vorsichtig gewählt werden, weil Funktionen wie das automatische Speichern darauf aufbauen.
WP-Cron, der Zeitplaner von WordPress, läuft laut Dokumentation nicht dauerhaft, sondern wird bei Seitenaufrufen angestoßen. Mit der Zeile define( ‘DISABLE_WP_CRON’, true ); in der wp-config.php schalten Sie das ab und lassen stattdessen den Zeitplaner des Servers die Datei wp-cron.php regelmäßig aufrufen. Geplante Aufgaben laufen dann verlässlich und belasten keine Besucheraufrufe mehr.
Wenn das WordPress-Backend langsam ist
Ein zähes Dashboard hat oft andere Ursachen als ein langsames Frontend, denn der Page-Cache greift im Backend nicht. Jede Seite der Verwaltung wird neu berechnet. Typische Gründe:
- Plugins mit eigenem Dashboard, die beim Öffnen der Verwaltung Statistiken berechnen oder externe Server abfragen.
- Eine aufgeblähte Optionen-Tabelle, deren automatisch geladene Einträge bei jedem Aufruf mitkommen.
- Fehlender Object-Cache, sodass dieselben Datenbankabfragen immer wieder laufen.
- Viele offene Editor-Tabs mit aktivem Heartbeat.
- Ein knapper Hosting-Tarif, dessen Grenzen im Backend früher sichtbar werden als im gecachten Frontend.
Deaktivieren Sie auf einer Kopie der Seite die Plugins einzeln und beobachten Sie, ab wann die Verwaltung wieder flüssig reagiert. So finden Sie den Verursacher meist schneller als über Vermutungen.
Wie kann ich in WordPress den Cache leeren?
Einen zentralen Knopf dafür hat WordPress selbst nicht, weil der Cache je nach Installation an unterschiedlichen Stellen liegt:
- Page-Cache-Plugin: In der Werkzeugleiste oder in den Einstellungen des Plugins gibt es meist einen Eintrag zum Leeren.
- Server-Cache des Hosters: Er wird im Kundenmenü des Hosters oder über ein mitgeliefertes Plugin geleert.
- Object-Cache: Auf der Kommandozeile leert der WP-CLI-Befehl wp cache flush laut WP-CLI-Dokumentation den Object-Cache. Bei Multisite betrifft das in der Regel alle Seiten des Netzwerks.
- CDN: Ein vorgeschaltetes CDN hat einen eigenen Cache, der im Dashboard des Anbieters geleert wird.
- Browser: Ein harter Neuladen oder ein privates Fenster zeigt, ob die Änderung wirklich online ist.
Checkliste: WordPress-Ladezeit optimieren
| Bereich | Maßnahme | Wirkt vor allem auf |
|---|---|---|
| Messen | PageSpeed Insights für Start-, Unter- und Beitragsseite, Felddaten notieren | Ausgangswert |
| Hosting | ausreichender Tarif, aktuelle PHP-Version | Antwortzeit, Backend |
| Cache | Page-Cache aktiv, Object-Cache bei vielen eingeloggten Nutzern | Antwortzeit |
| Plugins | ungenutzte deaktivieren und löschen, schwere ersetzen | alle Werte |
| Theme | schlankes Theme statt Multipurpose, Builder nur wo nötig | LCP, INP |
| Bilder | passende Größe, WebP oder AVIF, Breite und Höhe angeben | LCP, CLS |
| Lazy Loading | für Bilder weiter unten, nicht für das Hauptbild | LCP |
| Schriften | lokal einbinden, wenige Schnitte | LCP, CLS |
| Drittskripte | verzögern oder streichen | INP |
| Datenbank | Revisionen begrenzen, Altlasten löschen, Backup vorher | Backend, Antwortzeit |
| Heartbeat und Cron | Intervall prüfen, WP-Cron über Server-Cron | Serverlast |
| Kontrolle | nach jeder Änderung erneut messen | Nachweis |
Wann Konfiguration nicht mehr reicht
Irgendwann sind Cache, Bilder und PHP-Version in Ordnung, und die Seite bleibt trotzdem träge. Dann liegt das Problem meist tiefer: ein Theme, das auf jeder Seite Dutzende Skripte lädt, ein Builder, dessen Markup sich nicht verschlanken lässt, oder Funktionen, die nur mit schweren Plugins funktionieren.
Spätestens dann stellt sich die Frage, ob die Seite neu aufgebaut werden sollte. Das kann ein schlankes WordPress mit eigenen Blöcken sein oder ein anderes System. Welche Alternativen es gibt und wann sich ein Wechsel lohnt, beschreibt unser Ratgeber WordPress-Alternativen und Ablösung.
Ebenso wichtig ist, dass eine schnelle Seite schnell bleibt. Jedes Update und jedes neue Plugin kann die Werte wieder verschlechtern. Regelmäßige Pflege mit Prüfung vor dem Update verhindert, dass sich alte Probleme wieder einschleichen.
So arbeiten wir
Bei einer bestehenden WordPress-Seite beginnen wir mit einer Messung und einer Bestandsaufnahme von Hosting, PHP-Version, Theme und Plugins. Wie wir bei Ladezeiten methodisch vorgehen, steht auf unserer Seite zur Website-Performance-Optimierung. Neue WordPress-Seiten bauen wir standardmäßig ohne Page-Builder: mit schlankem Theme und eigenen Blöcken im Block-Editor. Mehr dazu auf der Seite WordPress-Agentur Nürnberg.
Für den laufenden Betrieb gibt es unsere WordPress-Wartung: Wartung & Pflege kostet für Websites ab 49 € monatlich. Enthalten sind Updates für Kern, Theme und Plugins, jeweils mit Kompatibilitätsprüfung vorab, dazu Backups, Monitoring und kleinere Änderungen mit höchstens 30 Minuten Aufwand. Eine bestimmte Ladezeit oder einen bestimmten Score sagen wir nicht zu, denn das Ergebnis hängt von Hosting, Inhalten und eingesetzten Erweiterungen ab.
Häufige Fragen
Warum lädt WordPress so langsam?
Meist kommen mehrere Ursachen zusammen: kein Page-Cache, eine alte PHP-Version, ein schwaches Hosting, ein schweres Theme oder ein Page-Builder, zu große Bilder sowie Plugins und Drittskripte, die auf jeder Seite laden. PageSpeed Insights zeigt, welche Kennzahl betroffen ist, und grenzt die Ursache damit ein.
Wie kann ich in WordPress den Cache leeren?
Das hängt davon ab, wo der Cache liegt. Ein Page-Cache-Plugin hat meist einen Eintrag in der Werkzeugleiste, ein Server-Cache wird im Kundenmenü des Hosters geleert, der Object-Cache per WP-CLI mit wp cache flush. Ein vorgeschaltetes CDN und der eigene Browser haben jeweils einen eigenen Cache.
Ist WordPress noch zeitgemäß?
Ja. WordPress wird aktiv weiterentwickelt, unterstützt moderne Bildformate wie WebP und AVIF und lädt Bilder nativ verzögert. Schnell ist eine WordPress-Seite allerdings nur, wenn Hosting, Theme und Plugins dazu passen. Für Seiten mit seltenen Änderungen kann ein statischer Aufbau die schlankere Lösung sein.
Warum ist das WordPress-Backend langsam?
Im Backend greift kein Page-Cache, jede Ansicht wird neu berechnet. Die häufigsten Ursachen und wie Sie den Verursacher finden, stehen im Abschnitt zum langsamen Backend oben.
Welche Werte sollte WordPress in PageSpeed Insights erreichen?
Laut web.dev gelten nach aktuellem Stand ein LCP von höchstens 2,5 Sekunden, ein INP von höchstens 200 Millisekunden und ein CLS von höchstens 0,1 als gut, jeweils für 75 Prozent der Seitenaufrufe. Entscheidend sind die Felddaten echter Nutzer, der Labor-Score dient der Fehlersuche.