WordPress langsam: Ursache finden statt Plugins stapeln

Die übliche Reaktion auf eine langsame WordPress-Seite ist ein weiteres Plugin, diesmal eins für Caching. Manchmal hilft das. Häufiger liegt die Ursache woanders, und das Caching-Plugin kaschiert sie nur für Besucher, während das Backend weiter hängt. Auf dieser Seite zeige ich, wie Sie richtig messen, in welcher Reihenfolge ich bei einer plötzlich langsamen Seite suche und welche sieben Ursachen ich am häufigsten finde, jeweils mit dem Weg, sie zu erkennen und zu beheben.

Zuerst messen, dann raten

„Die Seite ist langsam“ kann vieles heißen: Der erste Aufruf dauert, die Bilder tauchen spät auf, oder das Speichern im Backend braucht zehn Sekunden. Jedes Symptom hat andere Ursachen. Deshalb messe ich zuerst und hebe die Werte auf, damit sich hinterher zeigen lässt, was eine Maßnahme gebracht hat.

PageSpeed Insights: Labor- und Felddaten

PageSpeed Insights (pagespeed.web.dev) ist das Werkzeug von Google und kostenlos. Es zeigt zwei Arten von Daten, die oft verwechselt werden:

• Felddaten stehen oben im Bereich zu den Erfahrungen echter Nutzer. Sie stammen aus Chrome-Browsern echter Besucher der letzten 28 Tage. Diese Werte nutzt Google für die Bewertung der Seite. Kleine Websites haben oft zu wenige Besucher, dann bleibt dieser Bereich leer.
• Labordaten stehen darunter, mit der bekannten Punktzahl von 0 bis 100. Sie entstehen bei einem einzelnen, simulierten Aufruf, standardmäßig mit einem gedrosselten Mobilgerät. Die Punktzahl schwankt von Messung zu Messung und ist ein Hinweis, kein Zeugnis.

Die Punktzahl allein ist deshalb kein Ziel. Lesen Sie lieber die einzelnen Werte und die Empfehlungen darunter.

Die Werte, auf die es ankommt

LCP, INP und CLS sind die drei Core Web Vitals. Die Serverantwortzeit gehört nicht dazu, ist für mich aber der wichtigste Einzelwert: PageSpeed Insights meldet sie ab 600 Millisekunden als Problem, und alles, was der Server zu spät liefert, kann keine spätere Optimierung mehr aufholen. Liegt die Serverantwort hoch, suche ich bei Hosting, Plugins und Datenbank. Liegt sie niedrig und LCP trotzdem hoch, suche ich bei Bildern, Schriften und Skripten.

Die Google Search Console zeigt unter „Core Web Vitals“ dieselben Felddaten für die ganze Website. Dort sehen Sie, ob eine Verbesserung bei echten Besuchern ankommt, mit einigen Wochen Verzögerung, weil die Werte über 28 Tage gemittelt werden.

GTmetrix und der Wasserfall

GTmetrix (gtmetrix.com) nutzt dieselbe Messtechnik wie das Labor von PageSpeed Insights, zeigt aber zusätzlich ein Wasserfall-Diagramm: jede einzelne Datei, die beim Aufruf geladen wird, mit Größe, Herkunft und Dauer. Dort sieht man auf einen Blick, ob ein 3-MB-Bild, eine Schrift von einem fremden Server oder ein Chat-Widget den Aufbau aufhält. Dieselbe Ansicht liefern die Entwicklerwerkzeuge Ihres Browsers (F12, Reiter „Netzwerk“).

Messen Sie jede Seite mehrmals, und nicht nur die Startseite, sondern auch eine typische Unterseite und, falls vorhanden, eine Shop-Kategorie.

Query Monitor für das Innenleben

Die Werkzeuge oben sehen die Seite nur von außen. Was in WordPress selbst passiert, zeigt das Plugin Query Monitor. Ich installiere es nur zum Messen und lösche es danach wieder. Es zeigt für jeden Seitenaufruf, welches Plugin wie viele Datenbankabfragen auslöst, welche Abfragen langsam sind, welche Anfragen an fremde Server gehen und wie viel Speicher PHP braucht. Mit diesen Zahlen wissen Sie, ob das Problem vor WordPress liegt (Server), in WordPress (Plugins, Datenbank) oder danach (Bilder, Skripte).

Plötzlich langsam: in dieser Reihenfolge suche ich

Eine Seite, die gestern schnell war und heute langsam ist, hat fast immer einen konkreten Auslöser. Dann lohnt es sich nicht, alles auf einmal zu optimieren. Ich gehe die Verdächtigen in dieser Reihenfolge durch, von wahrscheinlich und schnell geprüft zu selten und aufwendig:

1. Was hat sich zuletzt geändert? Ein Update von Plugin, Theme oder WordPress, ein neues Plugin, eine neue Einbettung. Das Änderungsdatum verrät meist schon den Täter. Testweise deaktivieren, auf einer Staging-Kopie, wenn es geht.
2. Läuft der Cache noch? Nach Updates, Umzügen oder Plugin-Wechseln ist der Seiten-Cache oft leer, abgeschaltet oder doppelt vorhanden. Ein Blick in die Einstellungen des Caching-Plugins und in die Antwort-Header der Seite klärt das.
3. Hat der Hoster ein Problem? Überlastete Server, Wartungsarbeiten, Störungen im Rechenzentrum. Den aktuellen Stand großer deutscher Hoster zeige ich im Hoster-Status.
4. Gibt es ungewöhnlich viel Verkehr? Bots, die massenhaft das Login oder die XML-RPC-Schnittstelle angreifen, Crawler ohne Bremse, Spam-Kommentare. Die Zugriffsprotokolle beim Hoster zeigen das.
5. Hängt ein externer Dienst? Ein Plugin, das bei jedem Aufruf einen Lizenzserver, eine Schnittstelle oder einen Newsfeed abfragt, wartet, wenn dieser Dienst langsam ist. Query Monitor listet solche Anfragen mit ihrer Dauer.
6. Ist die Datenbank übergelaufen? Eine Protokolltabelle, die seit Jahren wächst, Tausende abgelaufene Zwischenspeicher, Sitzungsdaten eines Shops. Ab einer gewissen Größe kippt die Geschwindigkeit, ohne dass sich sonst etwas geändert hat.
7. Wurde PHP umgestellt? Hoster heben veraltete PHP-Versionen von sich aus an. Ist danach OPcache aus oder ein Plugin inkompatibel, wird die Seite langsam oder zeigt Fehler.
8. Ist die Seite gehackt? Cryptominer und Spam-Versand verbrauchen Serverleistung. Wenn keiner der Punkte oben passt, prüfe ich die Anzeichen für einen Hack.

Die 7 Ursachen

Ist die Seite nicht plötzlich, sondern schon lange langsam, finde ich fast immer eine oder mehrere dieser sieben Ursachen:

1. Hosting. Antwortzeit über 600 Millisekunden bei einer leeren Seite: Der Server ist überlastet oder zu klein. Kein Plugin ändert das. Lösung: Tarif wechseln oder Hoster wechseln.
2. Zu viele oder ein schlechtes Plugin. Query Monitor zeigt es sofort: Ein Plugin mit 200 Abfragen pro Seitenaufruf, meist ein Statistik-, Sicherheits- oder Related-Posts-Plugin. Lösung: ersetzen oder entfernen. Faustregel: Unter 20 Plugins, jedes mit einem Grund.
3. Bilder in Originalgröße. Ein 4-MB-Foto vom Handy als Kopfbild, das der Browser auf 800 Pixel schrumpft. Lösung: Bilder vor dem Upload verkleinern, WebP-Format, Plugin für automatische Komprimierung wie ShortPixel oder EWWW.
4. Kein Caching. Ohne Cache baut WordPress jede Seite bei jedem Aufruf neu. Lösung: Server-Cache des Hosters aktivieren, sonst ein Caching-Plugin wie WP Rocket oder LiteSpeed Cache. Eins, nicht zwei.
5. Datenbank voll mit Müll. Revisionen, Transienten, Spam-Kommentare, Tabellen längst gelöschter Plugins. Bei alten Seiten sind das oft Hunderte Megabyte. Lösung: Aufräumen, Revisionen begrenzen, Autoload-Optionen prüfen.
6. Externe Skripte. Google Fonts, Karten, Video-Einbettungen, Chat-Widgets, Tracking. Jedes davon lädt von einem fremden Server und blockiert den Aufbau. Lösung: Schriften lokal hosten, Einbettungen erst bei Klick laden, Tracking prüfen, ob es überhaupt gebraucht wird.
7. Veraltete PHP-Version. Neuere PHP-Versionen arbeiten in der Regel schneller, und PHP 7.4 bekommt seit Ende 2022 keine Sicherheitsupdates mehr. Lösung: im Hosting-Menü umstellen, vorher auf Staging testen.

Die Abschnitte unten gehen auf jede dieser Ursachen genauer ein.

WordPress-Backend langsam, Frontend schnell?

Das ist der Fall, bei dem Caching-Plugins nichts nützen. Besucher bekommen eine fertige Seite aus dem Cache, das Backend dagegen wird bei jedem Klick frisch berechnet, mit allen Plugins, allen Abfragen und allen Anfragen an fremde Server. Ein langsames WordPress-Backend zeigt deshalb ehrlicher als jede Messung von außen, wie schwer die Installation wirklich ist.

Meine Prüfschritte, wenn das Backend hängt:

• Query Monitor im Backend öffnen, auf der langsamen Seite, etwa beim Bearbeiten eines Beitrags. Unter „Abfragen nach Komponente“ steht das Plugin mit der meisten Zeit ganz oben. Das ist in den meisten Fällen der Täter.
• Anfragen an fremde Server prüfen. Query Monitor listet sie unter „HTTP-API-Aufrufe“. Ein Plugin, das bei jedem Laden des Dashboards seinen Lizenzserver oder einen Newsfeed fragt, bremst jede Seite um die Antwortzeit dieses Servers. Ist der Server nicht erreichbar, wartet WordPress bis zum Zeitlimit.
• Den Heartbeat prüfen. WordPress schickt im Backend regelmäßig eine Anfrage an den Server, standardmäßig alle 15 Sekunden im Editor und alle 60 Sekunden auf anderen Seiten. Damit funktionieren automatisches Speichern und die Sperre, wenn zwei Personen denselben Beitrag bearbeiten. Mit mehreren offenen Tabs und einem knappen Tarif summiert sich das. Das Intervall lässt sich mit einem kleinen Plugin verlängern; ganz abschalten würde ich den Heartbeat im Editor nicht.
• admin-ajax.php im Blick behalten. Viele Plugins schicken ihre Anfragen über diese Datei, im Backend und oft auch auf der öffentlichen Seite. Solche Anfragen werden nie gecacht. In den Entwicklerwerkzeugen des Browsers (Reiter „Netzwerk“, Filter „admin-ajax“) sieht man, wie viele es sind und wie lange jede dauert.
• WP-Cron prüfen. WordPress erledigt geplante Aufgaben, wenn jemand die Seite aufruft. Hängen dort Hunderte Aufgaben, etwa im Action Scheduler von WooCommerce, bremst das einzelne Aufrufe spürbar. Besser: WP-Cron abschalten und einen echten Cronjob beim Hoster einrichten.
• Page-Builder und Sicherheits-Plugins verdächtigen. Ein Page-Builder, der bei jedem Speichern alle Stile neu berechnet, oder ein Sicherheits-Plugin mit Live-Verkehrsanzeige, das jeden Zugriff in die Datenbank schreibt, sind die häufigsten Bremsen im Backend.

Hilft das alles nicht, bringt ein Objekt-Cache wie Redis oder Memcached oft die größte Verbesserung im Backend und im Shop. Er hält häufig gebrauchte Datenbankergebnisse im Arbeitsspeicher. Nicht jeder Tarif bietet das an; fragen Sie Ihren Hoster.

Was Ihr Hoster beitragen kann

Bevor Sie Plugins tauschen, lohnt der Blick ins Kundenmenü des Hosters. Drei Stellschrauben gibt es bei praktisch jedem Anbieter:

• PHP-Version. Sie wird nicht in WordPress eingestellt, sondern beim Hoster, meist je Webspace oder je Domain. Welche Version aktuell ist und wie lange Ihre noch Sicherheitsupdates bekommt, zeigt meine Seite zur aktuellen PHP-Version. Vorher Backup, danach Startseite, Formulare, Anmeldung und Kasse testen.
• OPcache. PHP übersetzt den Code von WordPress bei jedem Aufruf neu, wenn kein OPcache aktiv ist. Mit OPcache bleibt der übersetzte Code im Speicher. Bei den meisten Hostern ist er standardmäßig an; ob er läuft, steht in WordPress unter „Werkzeuge → Website-Zustand → Bericht → Server“ oder in der PHP-Info des Hosters.
• Tarif-Limits. Günstige Tarife begrenzen den Arbeitsspeicher für PHP, die Zahl gleichzeitiger PHP-Prozesse und die Rechenzeit. Wird ein Limit erreicht, warten Aufrufe in einer Schlange, ohne dass eine Fehlermeldung erscheint. Die genauen Werte stehen in den Tarifdetails, oft unter Begriffen wie „PHP-Speicher“ oder „Prozesse“.

IONOS und Strato begegnen mir bei langsamen Seiten besonders oft, schlicht weil dort sehr viele kleine WordPress-Seiten liegen. Beide Anbieter haben ordentliche WordPress-Tarife. Die typischen Probleme sind dieselben: ein alter Vertrag, der noch auf einer überholten PHP-Version läuft, ein Einsteigertarif, der für die heutige Seite zu klein geworden ist, und kein serverseitiger Seiten-Cache. Prüfen Sie dort zuerst PHP-Version und Tarifdetails im Kundenbereich und vergleichen Sie Ihren Vertrag mit den aktuellen Tarifen. Ältere Verträge werden selten automatisch umgestellt.

Ob das Hosting die Ursache ist, zeigt ein einfacher Test: eine leere Testseite ohne Bilder anlegen und deren Serverantwort messen. Liegt sie schon dort über 600 Millisekunden, hilft kein Plugin. Dann lohnt sich ein besserer Tarif oder ein Hosterwechsel. Ich hoste die Seiten, die ich warte, bei Mittwald, sage aber offen, wenn ein Tarifwechsel beim bisherigen Hoster reicht.

Die Datenbank aufräumen

WordPress speichert fast alles in der Datenbank: Inhalte, Einstellungen, Zwischenergebnisse von Plugins. Mit den Jahren sammelt sich dort viel an, das niemand mehr braucht. Vor jedem Aufräumen gilt: erst ein vollständiges Backup, dann löschen.

• Autoload-Optionen. Ein Teil der Einstellungen wird bei jedem Seitenaufruf komplett geladen, egal ob er gebraucht wird. Gelöschte Plugins hinterlassen dort oft große Datenpakete. Seit Version 6.6 warnt WordPress im Website-Zustand, wenn diese Daten zu groß werden. Ich prüfe, welche Einträge die größten sind, und entferne die von Plugins, die nicht mehr installiert sind.
• Revisionen. WordPress speichert bei jedem Speichern eine Kopie des Beitrags, unbegrenzt. Eine Seite, die hundertmal überarbeitet wurde, liegt hundertmal in der Datenbank. Eine Zeile in der wp-config.php begrenzt das für die Zukunft: define( 'WP_POST_REVISIONS', 5 ); Alte Revisionen lassen sich danach gezielt löschen.
• Transienten. Das sind Zwischenspeicher, die Plugins mit Ablaufdatum anlegen. Abgelaufene Transienten räumt WordPress normalerweise selbst auf. Funktioniert WP-Cron nicht zuverlässig, bleiben sie liegen. Mit WP-CLI geht das in einem Befehl: wp transient delete --expired
• Verwaiste Tabellen und Protokolle. Plugins für Statistik, Weiterleitungen, Sicherheit oder E-Mail-Protokolle legen eigene Tabellen an, die beim Deinstallieren oft stehen bleiben oder unbegrenzt wachsen. wp db size --tables zeigt, welche Tabellen am größten sind.

Ohne Kommandozeile helfen Plugins wie WP-Optimize. Sie löschen auf Knopfdruck aber auch, was noch gebraucht wird, deshalb nur mit Backup.

Caching-Plugins im Vergleich

Ein Seiten-Cache speichert die fertige HTML-Seite und liefert sie beim nächsten Aufruf direkt aus, ohne PHP und Datenbank. Für Besucher ist das meist der größte einzelne Gewinn. Wichtig: nur ein Caching-Plugin, und wenn der Hoster einen eigenen Server-Cache anbietet, hat dieser Vorrang.

Zwei häufige Fehler: Alle Optionen zum Zusammenfassen und Verzögern von CSS und JavaScript auf einmal einschalten, danach geht das Menü auf dem Handy nicht mehr. Ich schalte sie einzeln ein und teste nach jeder. Und bei Shops müssen Warenkorb, Kasse und Kundenkonto vom Cache ausgenommen sein.

Bilder: Format, Größe, Lazy Load

Bilder sind auf den meisten Seiten der größte Teil der Datenmenge. Drei Dinge machen den Unterschied:

• Format. WebP ist bei gleicher Qualität deutlich kleiner als JPEG und wird von allen aktuellen Browsern unterstützt. AVIF ist noch kleiner, braucht aber mehr Rechenzeit beim Umwandeln; WordPress kann es hochladen, wenn der Server es unterstützt. Plugins wie ShortPixel, EWWW oder Imagify wandeln vorhandene Bilder automatisch um.
• Größe. Ein Bild sollte nicht breiter sein als der breiteste Platz, an dem es erscheint, bei hochauflösenden Bildschirmen doppelt so breit. Ein Kopfbild mit 6.000 Pixel Breite ist nie nötig. WordPress erzeugt beim Hochladen kleinere Varianten und lässt den Browser die passende wählen; manche Themes und Page-Builder umgehen das und laden immer das Original.
• Lazy Load. Bilder weiter unten auf der Seite lädt der Browser erst, wenn sie in die Nähe des sichtbaren Bereichs kommen. WordPress macht das von sich aus. Aber: Das Bild ganz oben, meist das LCP-Element, darf nicht verzögert geladen werden, sonst wartet der Browser genau auf das Bild, das er zuerst zeigen sollte. Neuere WordPress-Versionen nehmen das erste Bild automatisch aus, Slider, Page-Builder und manche Optimierungs-Plugins hebeln das jedoch wieder aus. In PageSpeed Insights steht dann der Hinweis, dass das LCP-Bild verzögert geladen wurde.

Dazu gehört: Bilder brauchen eine feste Breite und Höhe im HTML, sonst springt die Seite beim Laden, und der CLS-Wert steigt.

Page-Builder und Plugins

Page-Builder wie Elementor, Divi oder WPBakery machen die Gestaltung bequem, laden aber eigene Stylesheets, Skripte und tief verschachteltes HTML. Ersetzen muss man sie deshalb nicht, aber ihre Leistungsoptionen nutzen: nicht benutzte Module abschalten, Stile als Datei ausgeben, Schriften lokal laden. Bei einem Neubau empfehle ich meist den Block-Editor mit einem schlanken Theme.

Bei Plugins zählt nicht die Anzahl, sondern was sie bei jedem Aufruf tun. Zehn kleine Plugins, die nur im Backend arbeiten, sind harmloser als ein einziges, das auf jeder Seite drei Skripte lädt und zwanzig Abfragen stellt. Mein Vorgehen bei einem Plugin-Audit: Jedes Plugin bekommt eine Zeile mit Zweck, letzter Aktualisierung und Last laut Query Monitor. Was keinen Zweck mehr hat, wird gelöscht, nicht nur deaktiviert. Was viel Last erzeugt, wird ersetzt oder so eingestellt, dass es nur auf den Seiten lädt, auf denen es gebraucht wird, etwa ein Formular-Plugin nur auf der Kontaktseite.

Externe Skripte und Einbettungen

Alles, was von einem fremden Server kommt, entzieht sich Ihrer Kontrolle: Google Fonts, YouTube-Videos, Google Maps, Chat-Widgets, Bewertungs-Badges, Tag Manager, Werbe- und Tracking-Skripte. Jedes davon braucht eine eigene Verbindung, lädt oft weitere Dateien nach und kann den Aufbau der Seite oder die Reaktion auf Klicks verzögern. Ein schlechter INP-Wert geht häufig auf solche Skripte zurück.

• Schriften lokal hosten. Die Schriftdateien liegen dann auf Ihrem eigenen Server. Das ist schneller und erspart die Übertragung von Besucherdaten an Google.
• Einbettungen erst bei Klick laden. Statt des YouTube-Players erscheint ein Vorschaubild, der Player lädt erst, wenn jemand auf „Abspielen“ klickt. Dasselbe geht für Karten.
• Tracking ausmisten. Ich finde regelmäßig zwei Analyse-Werkzeuge parallel, alte Pixel von beendeten Kampagnen und Tag Manager, in denen niemand mehr weiß, was drinsteckt. Was niemand auswertet, kommt raus.

Nebeneffekt: Jedes externe Skript weniger ist ein Punkt weniger im Cookie-Banner.

Optimierung durch mich

Ich messe, finde die Ursachen und behebe sie in einem Durchgang: Plugin-Audit, Bilder, Caching, Datenbank, PHP-Version, externe Skripte. Sie bekommen die Messwerte vorher und nachher. Festpreis 349 € netto, zusammen mit der Absicherung 499 €. Wenn das Hosting die Ursache ist, sage ich das vorher und rechne den Umzug an.

So läuft es ab:

1. Messung. Felddaten, Labordaten, Serverantwort und Query Monitor auf den wichtigsten Seiten, im Frontend und im Backend.
2. Befund. Sie bekommen eine kurze Liste der Ursachen, sortiert nach Wirkung, bevor ich etwas ändere.
3. Umsetzung. Zuerst auf einer Staging-Kopie, dann live, mit Backup davor.
4. Nachmessung. Dieselben Messungen wie am Anfang, damit Sie die Wirkung schwarz auf weiß haben.

Schnell bleiben ist allerdings eine Daueraufgabe: Jedes neue Plugin, jedes Update und jedes hochgeladene Foto kann die Werte wieder verschlechtern. In den Paketen Plus und Betreuung der WordPress-Wartung ist deshalb ein vierteljährlicher Performance-Check enthalten, mit Messwerten vorher und nachher.

Häufige Fragen

Anfrage

---