ostrelle
Menü

OSTRELLE · WEBSITES MIT KLAREM BLICK

WordPress zu langsam? Erst messen, dann ändern

WordPress lädt langsam oder das Backend hängt? Diagnose in fester Reihenfolge: Frontend und Backend messen, Checkliste, typische Ursachen und Wechselfrage.

← Zum Wissensbereich

Autor: Ostrelle-Projektredaktion · Stand: 30. Oktober 2026. Herausgeber ist das Ostrelle-Projekt (Burak Basci), das ein eigenes CMS entwickelt. Dieser quellenbasierte Ratgeber ist keine unabhängige Produktempfehlung und kein eigener Vergleichstest.

Wenn WordPress zu langsam wirkt, hilft Raten selten. Eine Seite kann im Frontend verlieren (Browser, Bilder, Skripte) oder im Backend (Server, PHP, Datenbank), und beides braucht andere Maßnahmen. Dieser Ratgeber zeigt eine feste Reihenfolge: messen, eine Sache ändern, erneut messen. Schwellenwerte stammen von web.dev, die Hinweise zu WordPress aus der offiziellen Entwicklerdokumentation.

1. Erst benennen, was „langsam“ heißt

Hinter „WordPress lädt langsam“ stecken drei verschiedene Beobachtungen: Die Seite erscheint spät, sie reagiert träge auf Eingaben, oder das WordPress-Backend ist zäh. Notiere vor jeder Änderung, welche gemeint ist, auf welcher Seite und mit welchem Gerät. Ohne diese Notiz weißt du später nicht, ob eine Maßnahme etwas gebracht hat.

Unsere Faustregel: Kommt schon das erste Byte der Antwort spät, liegt die Ursache eher auf dem Server (PHP, Datenbank, fehlender Cache). Kommt die Antwort schnell, aber die Seite baut sich langsam auf, liegt sie eher im Frontend (große Bilder, viele Skripte, schwerer Page Builder). Die Messung unten prüft diese Vermutung.

2. Frontend messen: PageSpeed Insights und Core Web Vitals

PageSpeed Insights zeigt zwei Datenarten. Felddaten stammen aus dem Chrome User Experience Report und beschreiben echte Nutzer. Labordaten entstehen mit Lighthouse in einer simulierten Umgebung auf einem Gerät mit festen Netzwerkbedingungen. Google schreibt dazu, Labordaten seien zum Debuggen nützlich, könnten aber reale Engpässe verfehlen. Beide Werte dürfen also voneinander abweichen. Quelle: PageSpeed Insights, Dokumentation.

Für die drei Core Web Vitals nennt web.dev diese Grenzen. Bewertet wird jeweils das 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop:

  • Largest Contentful Paint (LCP): gut bis 2,5 Sekunden, schlecht ab mehr als 4,0 Sekunden. web.dev zu LCP
  • Interaction to Next Paint (INP): gut bis 200 Millisekunden, schlecht ab mehr als 500 Millisekunden. web.dev zu INP
  • Cumulative Layout Shift (CLS): gut bis 0,1, schlecht ab mehr als 0,25. web.dev zu CLS

3. Den Lighthouse-Wert richtig lesen

Der Performance-Wert ist laut Chrome-Dokumentation ein gewichteter Mittelwert einzelner Metriken. Die Farbbereiche sind 0 bis 49 (rot), 50 bis 89 (orange) und 90 bis 100 (grün). In Lighthouse 10 fließen unter anderem Total Blocking Time mit 30 Prozent sowie LCP und CLS mit je 25 Prozent ein; andere Versionen können anders gewichten. Quelle: Lighthouse Performance Scoring.

Schau deshalb nicht nur auf die Gesamtzahl, sondern auf die einzelne Metrik, die schlecht ausfällt. Miss mobil und Desktop getrennt, mehrere Seitentypen (Startseite, Beitrag, eine Seite mit Page Builder) und wiederhole die Messung. Ein einzelner Lauf ist eine Momentaufnahme.

4. Backend messen: TTFB und Query Monitor

Die Time to First Byte (TTFB) misst die Zeit von Beginn der Navigation bis zum ersten Byte der Antwort. web.dev nennt Werte bis 0,8 Sekunden gut und Werte über 1,8 Sekunden schlecht. Ein hoher Wert deutet auf Serverzeit hin, etwa PHP, Datenbankabfragen oder fehlendes Caching. Du kannst ihn in den Entwicklertools des Browsers im Netzwerk-Tab ablesen. Quelle: web.dev zu TTFB.

Das Plugin Query Monitor ist laut Beschreibung ein Entwickler-Panel für WordPress. Es zeigt langsame, doppelte und fehlerhafte Datenbankabfragen, aufgeschlüsselt nach Komponente und aufrufender Funktion, außerdem Hooks, PHP-Fehler und HTTP-API-Anfragen mit Dauer. Die Ausgabe lässt sich auf ein Plugin oder Theme eingrenzen. So erkennst du, ob ein einzelnes Plugin Abfragen oder externe Anfragen verursacht. Quelle: Query Monitor im Plugin-Verzeichnis.

Die WordPress-Dokumentation rät, Debug-Werkzeuge in einer lokalen oder Staging-Umgebung zu nutzen und nicht direkt auf der Live-Seite. Die Konstante SAVEQUERIES etwa speichert alle Abfragen und wirkt sich laut Dokumentation auf die Leistung aus. Quelle: WordPress-Debugging.

5. Die Diagnose-Checkliste in fester Reihenfolge

Arbeite die Punkte von oben nach unten ab und ändere pro Schritt nur eine Sache. Lege vorher eine Sicherung an und teste Änderungen möglichst auf einer Staging-Kopie.

  • 1. Drei Testseiten festlegen und Ausgangswerte notieren: PageSpeed Insights mobil und Desktop, TTFB, Datum und Uhrzeit.
  • 2. Frontend oder Backend? Ist die TTFB hoch, zuerst Punkte 3 bis 7. Ist sie niedrig und LCP, INP oder CLS schlecht, zuerst Punkt 8.
  • 3. PHP-Version prüfen und mit dem Unterstützungsstatus bei php.net vergleichen.
  • 4. Caching prüfen: Seitencache, Browser-Cache und ein persistenter Object Cache.
  • 5. Plugins per Bisect testen: auf Staging die Hälfte deaktivieren, messen, die verdächtige Hälfte wieder teilen, bis der Verursacher feststeht.
  • 6. Mit Query Monitor langsame oder doppelte Abfragen und lange externe Anfragen suchen.
  • 7. Autoload-Optionen in wp_options und das Hosting-Paket (CPU, RAM, Speicher) prüfen.
  • 8. Bilder, Schriften, Skripte und Page-Builder-Seiten prüfen, die den LCP bestimmen.
  • 9. Nach jeder Änderung erneut messen und das Ergebnis notieren, auch wenn es nichts bringt.

6. Typische Ursachen und was die Dokumentation dazu sagt

PHP-Version: Am 30.10.2026 listet php.net die Zweige 8.2 bis 8.5 als unterstützt. 8.2 erhält laut Seite nur noch Sicherheitskorrekturen, bis 31.12.2026. Ältere Zweige stehen nicht mehr in der Liste. Die WordPress-Dokumentation nennt aktuelle Versionen von PHP, Webserver und Datenbank als Performance-Hebel, weil Updates oft die Leistung verbessern. Teste den Wechsel zuerst auf Staging, denn Plugins können mit einer neueren Version Fehler zeigen. Quelle: php.net, unterstützte Versionen.

Caching: Laut WordPress-Doku speichern Caching-Plugins Seiten als statische Dateien; hinzu kommen serverseitiges Caching und Browser-Caching über Header wie max-age. Ein persistenter Object Cache reduziert Datenbankzugriffe, setzt aber einen Cache-Server beim Hoster und ein passendes Plugin voraus. Mit einem Memcached-Plugin liegen Transients im schnellen Speicher statt in der Datenbank. Quelle: WordPress, Performance-Optimierung.

wp_options und Autoload: Optionen mit Autoload werden beim Start von WordPress geladen. Zu viele davon können laut Dokumentation Performance-Probleme verursachen, besonders wenn sie selten gebraucht werden. Seit WordPress 6.6 warnt Site Health standardmäßig ab 800.000 Byte. Prüfe vor jeder Änderung, welches Plugin eine Option angelegt hat, und lösche nichts auf Verdacht. Quelle: add_option(), Parameter autoload.

Heartbeat und externe Anfragen: Die Heartbeat-API ist eine Polling-Schnittstelle, die über den admin-ajax-Handler läuft; der Takt liegt laut Entwicklerhandbuch zwischen 15 und 120 Sekunden. Ist das Backend zäh, zeigt Query Monitor außerdem, welche HTTP-API-Anfragen wie lange dauern. Eine langsame externe Anfrage kann eine Seite im Admin ausbremsen. Quelle: Heartbeat API.

Bilder und Hosting: Die Doku empfiehlt, nur nötige Bilder zu verwenden, passende Formate und Kompression zu wählen und moderne Formate wie WebP einzusetzen. Mehr CPU, RAM und SSD- oder NVMe-Speicher können die Leistung ebenfalls verbessern. Das ist eine Option, aber erst nach der Messung: Ein größeres Paket behebt keine Abfrage, die zu oft läuft.

Elementor und andere Page Builder: Elementor schreibt in seiner Hilfe, es gebe mehrere mögliche Ursachen für eine langsame Seite oder einen langsamen Editor, jede sei zu prüfen. Auch Add-ons sollten auf Kompatibilität und Leistungsauswirkung geprüft werden. Behandle „WordPress Elementor langsam“ daher wie jeden anderen Fall: messen, dann Plugins und Seitenaufbau einzeln testen. Quelle: Elementor, langsame Website beschleunigen. Zu Add-ons: Elementor Help Center.

7. Wenn die Ursache die Architektur ist

Manchmal bleibt nach allen Schritten ein Befund wie: viele Plugins, die jeweils eigene Abfragen auslösen, und eine Datenbank, die sich nicht entlasten lässt, ohne Funktionen zu streichen. Dann ist es legitim, über einen Systemwechsel nachzudenken. Entscheide das aber erst nach der Messung und mit einem Plan für Inhalte, Adressen und Rückweg. Ein Umzug ist selbst ein Risiko; die Schritte stehen in der Checkliste zum WordPress-Umzug.

Offenlegung: Der Herausgeber dieser Seite entwickelt das CMS Ostrelle. Ostrelle ist ein Entwicklungsprojekt, kein Hosting-Angebot, und WordPress-Plugins laufen dort nicht unverändert. Belegt ist nur, dass die Produktwebsite selbst am 30.10.2026 bei PageSpeed Insights 100/100/100/100 erreicht hat, selbst gemessen und nur für diese Seiten. Das ist kein Vergleich mit anderen Systemen und keine Aussage über deine Website. Details im Entwicklungsstand. Verwandt: WordPress umziehen: Checkliste und Plugin nicht mehr gepflegt: was tun?.

Häufige Fragen

Warum ist mein WordPress-Backend langsam, obwohl die Website schnell ist?

Besucher bekommen oft Seiten aus dem Cache, das Backend nicht. Prüfe mit Query Monitor langsame Datenbankabfragen und lange externe HTTP-Anfragen, danach PHP-Version, Autoload-Optionen und Plugins per Bisect.

Was ist ein guter Wert für die TTFB?

web.dev nennt Werte bis 0,8 Sekunden gut und Werte über 1,8 Sekunden schlecht. Die Werte dazwischen gelten als verbesserungswürdig.

Welche PHP-Version sollte ich verwenden?

Eine, die php.net als unterstützt führt. Am 30.10.2026 sind das die Zweige 8.2 bis 8.5, wobei 8.2 nur noch Sicherheitskorrekturen bis 31.12.2026 erhält. Teste den Wechsel vorher auf einer Staging-Kopie.

Wie finde ich das Plugin, das WordPress ausbremst?

Auf einer Staging-Kopie Plugins schrittweise deaktivieren und nach jedem Schritt neu messen. Ergänzend zeigt Query Monitor Abfragen und HTTP-Anfragen nach Komponente.

Primärquellen und Quellenstand

Die folgenden Quellen wurden am 30. Oktober 2026 für diesen Ratgeber abgerufen. Einordnung und Empfehlungen sind unsere Auswertung; sie ersetzen keine Rechtsberatung und keinen Test deines konkreten Vorhabens.

Weiterlesen

Selbst betreiben statt gehostet: Ostrelle ist als Apache-2.0-Projekt angelegt. Wie das heute geht, steht unter Selbst hosten; was bei einem Ausfall zu tun ist, unter Hilfe bei Ausfällen. Ein öffentlicher Quellcode-Download ist geplant, aber noch nicht verfügbar.