WordPress langsam: So finden Sie die Ursache, bevor Sie ein Caching-Plugin installieren

Warum ist Ihre WordPress-Seite so langsam?

Ist Ihre WordPress-Seite langsam, geht die Zeit beim Server oder im Browser verloren. Entweder braucht der Server lange, bis er die Seite erzeugt und das erste Byte schickt, oder der Browser braucht danach lange, um Bilder, Skripte und Stylesheets zu laden und darzustellen. Eine Messung zeigt, welche Stelle bremst, und davon hängt ab, wo Sie die Ursache suchen.

WordPress baut jede Seite erst, wenn sie aufgerufen wird: PHP-Skripte laufen, die Datenbank liefert Inhalte und Einstellungen, dann schickt der Server die fertige HTML-Seite. Diese Zeit misst die Time to First Byte (TTFB), vom Start des Seitenaufrufs bis zum ersten Byte der Antwort. Danach lädt der Browser Stylesheets, Skripte, Schriften und Bilder; der LCP misst, wann das größte Element sichtbar ist. Google nennt eine TTFB bis 0,8 Sekunden und einen LCP bis 2,5 Sekunden gut (Stand Oktober 2026).

Beide Werte gehören zusammen. Google schreibt auf web.dev, dass die TTFB eine langsame Server-Antwort aufdeckt und der First Contentful Paint (FCP) Dateien, die den Seitenaufbau blockieren; beides erklärt einen schlechten LCP. Ist die TTFB hoch, suchen Sie deshalb auf dem Server: bei PHP-Version, Plugins, Datenbank und Tarif. Ist sie niedrig und der LCP trotzdem hoch, suchen Sie im Browser: bei Bildern, Skripten, Stylesheets und Schriften.

Drei WordPress-Seiten mit Page Builder, die ich 2026 mit Lighthouse im Mobilprofil gemessen habe, zeigen, wie groß der Unterschied sein kann. Der Server antwortete jeweils nach höchstens rund einer Sekunde, gemessen mit einzelnen Abrufen ohne Drosselung; das größte Element der Startseite stand im mobilen Test aber erst nach mindestens sechs Sekunden. Jede der drei Startseiten lud mehr als 20 Stylesheets und mehr als 20 Skriptdateien, bei zwei war das größte Element ein Bild-Slider im Seitenkopf.

Und genau davon hängt ab, ob ein Caching-Plugin hilft:

„Bevor ich ein Caching-Plugin einrichte, messe ich, ob die Zeit beim Server oder im Browser verloren geht. Ein Seiten-Cache verkürzt nur die Antwort des Servers; lädt der Browser danach noch Sekunden lang Bilder und Skripte, ändert er daran nichts und verdeckt nur, wie lange WordPress selbst braucht.“

— Sascha Fix

Bei den drei gemessenen Seiten hätte ein Seiten-Cache also höchstens rund eine Sekunde eingespart.

Und woher kommen mehr als 20 Stylesheets und Skripte? Laut der WordPress-Dokumentation zur Optimierung haben das Theme sowie Zahl und Qualität der Plugins großen Einfluss auf die Leistung. Ich sehe das so: Je einfacher die Website, desto weniger System braucht sie. Jede Schicht, auch jede Erweiterung, bringt Code mit, der gepflegt werden muss, und ohne sie lädt die Seite schneller.

Die Tabelle ordnet Messwerte und Symptome den Stellen zu, an denen Sie zuerst nachsehen:

Plötzlich langsam, ohne dass Sie etwas geändert haben?

Wenn die Seite direkt nach einem Update, einem neuen Plugin oder einem Theme-Wechsel langsam geworden ist, prüfen Sie zuerst diese Änderung in einer Testkopie. Ohne jede Änderung gehört dagegen ein Hack in die Prüfliste. Die WordPress-Dokumentation nennt auch Missbrauch wie Brute-Force-Angriffe auf das Login als Grund für höhere Serverlast. Weitere Anzeichen sammelt der Ratgeber Website gehackt? Malware erkennen und entfernen. Erhärtet sich der Verdacht, kommt zuerst die Bereinigung und erst danach die Beschleunigung; wie ich dabei vorgehe, steht auf der Seite zur WordPress-Hack-Hilfe.

Wie messen Sie, wo WordPress die Zeit verliert?

PageSpeed Insights zeigt für Smartphone und Desktop getrennt, wie schnell eine Seite lädt: mit Felddaten echter Besucher, wenn genug vorliegen, und mit Labordaten aus einer simulierten Messung. Für die Ursachensuche brauchen Sie dazu die Entwicklerwerkzeuge Ihres Browsers, deren Wasserfall zeigt, welche Datei wie lange braucht. Das Plugin Query Monitor findet langsame Datenbankabfragen.

Die Felddaten stammen aus dem Chrome User Experience Report (CrUX), der Messwerte echter Nutzer sammelt; PageSpeed Insights fasst die letzten 28 Tage zusammen (Stand Oktober 2026). Wenn eine Seite neu ist oder zu wenige Besucher hat, fehlen diese Daten. Die Labordaten simulieren einen Seitenaufruf auf einem einzigen Gerät mit festen Netzbedingungen. Deshalb weichen sie von den Felddaten ab. Außerdem schwanken sie von Lauf zu Lauf, wie Google zu PageSpeed Insights erklärt. Zum Fehlersuchen taugen sie trotzdem.

Neben dem LCP zählen zu den Core Web Vitals der Cumulative Layout Shift (CLS, gut bis 0,1) und die Interaction to Next Paint (INP, gut bis 200 Millisekunden), die am 12. März 2024 den First Input Delay abgelöst hat (Stand Oktober 2026). Google bewertet dabei das 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop: Ein Zielwert gilt als erreicht, wenn mindestens drei von vier Aufrufen ihn nicht überschreiten. Was die Werte im Einzelnen messen, erklärt der Ratgeber zu den Core Web Vitals. Die TTFB gehört nicht dazu, und Google nennt ihre Schwelle selbst einen groben Richtwert.

Die TTFB messen Sie auch selbst. Öffnen Sie in Chrome die Entwicklerwerkzeuge (DevTools), wechseln Sie in das Netzwerk-Panel, setzen Sie den Haken bei „Disable cache“ und laden Sie die Seite neu; dann lädt der Browser alles wie bei einem ersten Besuch. Die Phase „Waiting (TTFB)“ der ersten Anfrage enthält einen Hin- und Rückweg durchs Netz und die Zeit, die der Server für seine Antwort gebraucht hat. Der Wasserfall daneben zeigt für jede Datei, wann sie beginnt und wie lange sie lädt. Damit sehen Sie, welche Stylesheets, Skripte und Bilder den Aufbau aufhalten.

Ist die TTFB hoch, zeigt das Plugin Query Monitor, was WordPress beim Erzeugen der Seite tut, darunter Datenbankabfragen, die langsam, doppelt oder fehlerhaft sind; die Ausgabe sehen standardmäßig nur Administratoren. Schneller macht Query Monitor nichts: Laut seiner Plugin-Seite kostet es selbst ein wenig Zeit und Speicher (Stand Oktober 2026). Nutzen Sie es deshalb in der Testkopie oder nur während der Suche.

Ist nur das Backend langsam oder auch die Seite für Besucher?

Lädt die Seite für Besucher schnell und reagiert nur das Backend zäh, liegt die Ursache bei dem, was WordPress für angemeldete Nutzer zusätzlich erledigt: Plugins, die im Backend arbeiten, die Heartbeat-API, Datenbankabfragen und automatisch geladene Optionen. Ein Seiten-Cache hilft dabei nicht, denn er speichert Beiträge und Seiten für Besucher, nicht die Verwaltungsoberfläche.

Ein offener Editor schickt Anfragen an den Server, auch wenn gerade niemand schreibt. Dafür sorgt die Heartbeat-API, die das Backend mit dem Server in Verbindung hält: Solange ein Nutzer angemeldet ist, fragt sie laut Quelltext von WordPress alle 15 bis 60 Sekunden beim Server an, etwa für das automatische Speichern und die Warnung vor dem Ablauf der Anmeldung; ist das Browserfenster nicht im Vordergrund, alle 120 Sekunden (Stand Oktober 2026).

Automatisch geladene Optionen sind Einstellungen von Plugins und Themes, die WordPress bei jedem Seitenaufruf mitlädt. Ohne dauerhaften Objekt-Cache liest WordPress solche Optionen bei jedem Aufruf aus der Datenbank, und dadurch verlängert sich die TTFB. Die WordPress-Dokumentation rät, sie zusammen unter 800 KB zu halten, und seit WordPress 6.6 meldet der Website-Zustand (Site Health) im Backend ein kritisches Problem, wenn sie größer sind (Stand Oktober 2026). Ein Objekt-Cache spart diese Abfragen ein, setzt aber einen eigenen Cache-Server voraus, den Ihr Hoster anbieten muss.

Auch ohne angemeldete Nutzer kann der Server mehr arbeiten, als die Besucherzahl vermuten lässt. In den Server-Protokollen einer WordPress-Seite, die ich 2026 ausgewertet habe, kam knapp ein Viertel der insgesamt gut zwei Millionen Anfragen von Programmen, die sich selbst als Bot oder Crawler ausweisen. Und wp-cron.php, die Datei für geplante Hintergrundaufgaben, wurde im Schnitt rund 1.500-mal am Tag aufgerufen, also öfter als einmal pro Minute.

WordPress erzeugt solche Aufrufe selbst: Es prüft bei jedem Seitenaufruf, ob geplante Aufgaben fällig sind, und startet sie über eine eigene Anfrage an wp-cron.php, die WordPress noch einmal lädt. Den Besucher soll das laut Quelltext nicht aufhalten, aber der Server hat eine Anfrage mehr; die WordPress-Dokumentation spricht von zusätzlichem Ressourcenverbrauch. Abhilfe schafft ein echter Cronjob des Servers.

In welcher Reihenfolge machen Sie WordPress schneller?

Um WordPress schneller zu machen, gehen Sie eine Ursache nach der anderen an und messen nach jedem Schritt: erst Werte notieren und sichern, dann PHP-Version, Plugins und Theme in einer Testkopie prüfen, danach Bilder, Skripte und Datenbank. Nur so sehen Sie, welche Änderung wie viel gebracht hat. Das Caching-Plugin kommt zum Schluss, wenn Sie wissen, was es noch verbessern soll.

Mehrere Schritte greifen in die Seite ein: Vielleicht stellen Sie die PHP-Version um, schalten Plugins ab und richten am Ende ein neues Plugin ein. Deshalb kommt das Backup gleich nach dem Messen, noch vor dem ersten Eingriff.

1. Werte messen und notieren

   Testen Sie die Startseite und eine typische Unterseite in PageSpeed Insights, jeweils für Smartphone und Desktop, und notieren Sie den LCP, die Felddaten und die TTFB aus den Entwicklerwerkzeugen.

2. Backup anlegen und Wiederherstellung ausprobieren

   Sichern Sie Dateien und Datenbank außerhalb des Webspace und spielen Sie die Sicherung einmal zurück, am besten in eine Testkopie der Seite, eine sogenannte Staging-Umgebung. Dort probieren Sie die folgenden Schritte aus, bevor Sie die Live-Seite anfassen.

3. PHP-Version prüfen

   Laut php.net bekommt PHP 8.1 seit dem 31. Dezember 2025 keine Sicherheitsupdates mehr, PHP 8.2 nur noch bis zum 31. Dezember 2026, PHP 8.4 bis Ende 2028 und PHP 8.5 bis Ende 2029 (Stand Oktober 2026). Dazu bringen neuere Versionen laut WordPress-Dokumentation meist mehr Leistung. Wer umstellt, sollte deshalb gleich auf PHP 8.4 oder 8.5 gehen. Der Beitrag WordPress-PHP-Version aktualisieren zeigt, wo Sie die Version ablesen und wie Sie die Umstellung in der Testkopie prüfen.

4. Plugins und Theme in der Testkopie einzeln prüfen

   Schalten Sie in der Testkopie ein Plugin nach dem anderen ab und messen Sie jedes Mal die TTFB, wie es auch die WordPress-Dokumentation empfiehlt; danach testen Sie ein Standard-Theme. Plugins, die Sie nicht brauchen, deaktivieren und löschen Sie. Bleibt die Server-Antwort auch ohne Plugins und mit Standard-Theme über 0,8 Sekunden, suchen Sie bei Datenbank, Hintergrundlast und zuletzt beim Tarif weiter; wann sich ein Wechsel lohnt, steht im Ratgeber Website umziehen und Hoster wechseln.

5. Bilder und Medien verkleinern

   Ist das LCP-Element ein großes Bild oder ein Slider, verkleinern und komprimieren Sie die Bilder und liefern Sie sie als WebP aus; die WordPress-Dokumentation empfiehlt dieses kleinere Format. Wie das geht, zeigt der Ratgeber Bilder für das Web optimieren.

   Videos vom eigenen Webspace belasten vor allem den Server: Bei einer WordPress-Seite, deren Server-Protokolle ich 2026 ausgewertet habe, entfielen knapp zwei Drittel des übertragenen Datenvolumens auf Videodateien, und fast jeder Videoabruf war ein Teilabruf, mit dem der Browser das Video Stück für Stück nachlädt. Große Videos gehören deshalb auf einen Dienst für Videos oder zumindest auf ein Content Delivery Network (CDN).

6. Skripte, Stylesheets und Schriften entschlacken

   Sehen Sie im Wasserfall nach, welche Stylesheets, Skripte und Schriften den Aufbau aufhalten und ob sie von fremden Servern kommen, und entfernen Sie, was keine Funktion mehr hat. Das Netzwerk-Panel zeigt mit der Einstellung „Big request rows“, ob eine Datei komprimiert ankommt: Ist die übertragene Größe in der Spalte „Size“ so groß wie die unkomprimierte darunter, kam die Datei unkomprimiert. Skripte, die der erste Bildschirm nicht braucht, laden Sie verzögert. Danach prüfen Sie Formulare, Menü und Cookie-Banner und sehen in der Konsole der Entwicklerwerkzeuge nach Fehlermeldungen.

7. Datenbank und WP-Cron entlasten

   Sehen Sie im Website-Zustand nach, ob WordPress zu große automatisch geladene Optionen meldet; wie Sie einzelne Optionen ansehen und ändern, erfahren Sie laut WordPress-Dokumentation bei Ihrem Hoster. Für den WP-Cron richten Sie zuerst einen Cronjob ein, der wp-cron.php in festen Abständen aufruft, etwa alle 15 Minuten. Mit Zugang zur Server-Shell tragen Sie diese Zeile mit crontab -e ein und ersetzen example.com durch die Adresse Ihrer Website:

   */15 * * * * wget --delete-after https://example.com/wp-cron.php
   

   Erst wenn dieser Aufruf läuft, schalten Sie den WP-Cron bei Seitenaufrufen ab, mit dieser Zeile in der wp-config.php oberhalb von „That's all, stop editing!“:

   define( 'DISABLE_WP_CRON', true );
   

   Danach startet WordPress geplante Aufgaben nur noch über den Cronjob. Um das rückgängig zu machen, entfernen Sie die Zeile und löschen den Cronjob. Das Plugin-Handbuch von WordPress beschreibt den Aufruf per wget und die Konstante (Stand Oktober 2026). Ohne Shell-Zugang fragen Sie Ihren Hoster, wo sich geplante Aufgaben einrichten lassen.

8. Erneut messen und vergleichen

   Messen Sie nach jeder Änderung dieselben Seiten mit demselben Werkzeug und vergleichen Sie die Sekunden von LCP und TTFB mit Ihren Notizen; bei knappen Unterschieden mehrmals, weil Laborwerte schwanken.

Und die Punktzahl von 0 bis 100 ganz oben in PageSpeed Insights? Sie ist ein gewichteter Mittelwert aus den Labormesswerten; in Lighthouse 10 zählt der LCP mit 25 Prozent. Jeden Messwert übersetzt Lighthouse dafür über eine Kurve aus Daten echter Websites in Punkte von 0 bis 100, und annähernd linear hängen Messwert und Punkte nur zwischen 50 und 92 Punkten zusammen.

Eine WordPress-Seite mit Page Builder, die ich 2026 beschleunigt habe, zeigt, wie wenig die Punktzahl über den Erfolg sagen kann. Der Server antwortete schon vorher nach weniger als einer halben Sekunde, die Zeit ging also im Browser verloren: Stylesheets und Skripte kamen unkomprimiert, mehrere Dutzend davon blockierten den Aufbau, und die Bilder waren nicht fürs Web aufbereitet. Nach Komprimierung, WebP-Bildern, einem Seiten-Cache und verzögert geladenen Skripten war der LCP der Startseite im mobilen Lighthouse-Test auf weniger als die Hälfte gesunken, die Leistungspunktzahl stieg über die ganze Messreihe aber nur um einen Punkt. Die Stylesheets von Theme und Erweiterungen hielten die Punktzahl unten, weil sie den Aufbau weiter blockierten.

Der Fall zeigt: Solange die Werte weit über dem Ziel liegen, taugt die Punktzahl schlecht als Erfolgsmesser. Vergleichen Sie deshalb die Sekunden.

Wann bringt ein Caching-Plugin etwas und wann überdeckt es die Ursache?

Ein Caching-Plugin speichert Beiträge und Seiten als statische Dateien und erspart dem Server, sie bei jedem Aufruf neu zu erzeugen. Das hilft, wenn die Server-Antwort langsam ist oder viele Anfragen gleichzeitig kommen. Bilder und Skripte im Browser, das Backend sowie Warenkorb und Kasse beschleunigt es nicht. Wenn Sie es vor der Messung einrichten, verdeckt es, wie lange WordPress selbst braucht.

Die WordPress-Dokumentation nennt Caching selbst den schnellsten Weg zu mehr Leistung, mit dem größten Nutzen für den geringsten Aufwand; bei weitgehend statischen Seiten könne ein Caching-Plugin die Leistung um das Mehrhundertfache verbessern. Für die Server-Seite stimmt das: Ohne Cache stauen sich bei viel Verkehr die Anfragen, die Seite wird immer langsamer, und Web- oder Datenbankserver können abstürzen. Ein Caching-Plugin verstärkt deshalb, was Sie vorher verbessert haben.

Seine Grenzen folgen aus seiner Arbeitsweise. Das Plugin WP Super Cache zum Beispiel liefert seine statischen HTML-Dateien an Besucher aus, die nicht angemeldet sind, und rät in seinen empfohlenen Einstellungen, Seiten für angemeldete Nutzer nicht zwischenzuspeichern (Stand Oktober 2026). Wenn Sie einen Beitrag ändern oder ein Kommentar dazukommt, löscht das Plugin die betroffenen Cache-Dateien; beim nächsten Aufruf erzeugt WordPress die Seite wieder dynamisch. In einem Shop müssen Warenkorb, Kundenkonto und Kasse laut WooCommerce-Dokumentation ganz vom Cache ausgenommen bleiben, weil sie Daten des einzelnen Kunden zeigen.

Drei Arten von Cache beschleunigen Verschiedenes:

Der Ratgeber Browser-Caching einrichten zeigt, wie Sie den Browser-Cache über die Header Ihres Servers einrichten.

Seien Sie vorsichtig mit der Funktion, alle Skripte zu einer Datei zusammenzufassen. Die WordPress-Dokumentation empfiehlt sie für Seiten, die noch über HTTP/1.x ausgeliefert werden. Bei der Seite, die ich 2026 beschleunigt habe, fehlte nach dem Zusammenfassen die Skript-Bibliothek jQuery, die Konsole meldete Fehler, und die Seite baute sich sogar später auf als vorher; ich habe die Funktion deshalb wieder abgeschaltet.

Selbst beheben oder beauftragen?

Eine langsame WordPress-Seite können Sie selbst angehen, wenn Sie an Dateien und Datenbank herankommen, eine Testkopie anlegen können und ein Backup haben, dessen Wiederherstellung Sie ausprobiert haben. Hilfe lohnt sich, wenn eigener Code im Theme steckt, Warenkorb und Kundenkonten betroffen sind oder die Seite ohne jede Änderung langsam geworden ist.

Wenn Sie das nicht selbst übernehmen möchten, mache ich Ihre Seite schneller: Nach einer Einschätzung für 49 € nenne ich Ihnen einen Festpreis ab 199 €, jeweils zzgl. 19 % USt. Wie das abläuft, steht auf der Seite WordPress schneller machen lassen.

Wenn Sie in der Testkopie auf einen Fehler stoßen, etwa auf ein Plugin, das nach der PHP-Umstellung nicht mehr läuft, oder eine Seite, die nach dem Abschalten eines Plugins bricht, lassen Sie WordPress die Fehlermeldungen dort in ein Protokoll schreiben. Wie das geht, zeigt der Beitrag zum WordPress-Debug-Modus. Wenn Sie damit nicht weiterkommen, finde ich heraus, welches Plugin, welches Theme oder welche PHP-Version den Fehler auslöst, und behebe ihn. Wie das abläuft, steht auf der Seite zur Website-Reparatur; die Einschätzung vorab ist kostenlos.

Vorbeugend helfen drei Dinge: eine PHP-Version mit Sicherheitsupdates, keine Plugins, die niemand mehr pflegt, und Updates nur mit einem Backup davor. Welche dieser Aufgaben ich in der laufenden Betreuung übernehme, beschreibe ich auf der Seite zur WordPress-Wartung.