WordPress schneller machen: Ladezeit messen und Engpässe systematisch finden

Eine langsame WordPress-Website kostet Anfragen und Umsatz, und die übliche Reaktion ist ein weiteres Optimierungs-Plugin. Das hilft nur, wenn es den tatsächlichen Engpass trifft. Diese Anleitung zeigt ein festes Vorgehen: Sie messen zuerst die Antwortzeit des Servers, lesen die Einschätzung von WordPress selbst, zerlegen einen Seitenaufruf mit Query Monitor und WP-CLI in seine Bestandteile und prüfen jede Änderung mit derselben Messung. Im Labor wurde dafür ein absichtlich langsames Test-Plugin eingebaut und mit genau diesen Werkzeugen gefunden.

Voraussetzungen

• WordPress: getestet mit WordPress 7.1.2. Query Monitor setzt laut Plugin-Seite WordPress 6.2 oder neuer voraus.
• PHP: mindestens 7.4, im Test lief PHP 8.4.
• Zugriff: Backend-Konto mit der Rolle Administrator. Für die Schritte 4 und 5 zusätzlich SSH mit WP-CLI (getestet mit WP-CLI 2.12.0).
• Ein Rechner mit curl: unter Linux und macOS vorhanden, unter Windows 10 und 11 als curl.exe in der Eingabeaufforderung.
• Backup und Staging: eine aktuelle Sicherung von Dateien und Datenbank. Plugins testweise zu deaktivieren gehört auf eine Staging-Kopie, nicht auf die Live-Website. Wie Sie eine solche Kopie anlegen, zeigt die Anleitung Staging-Umgebung für WordPress mit WP-CLI einrichten.
• Notizdatei: eine einfache Tabelle für Messwerte mit Datum, URL, Änderung und Ergebnis.

Schritt 1: Ausgangswert messen

„Die Seite ist langsam“ ist kein Messwert. Bevor Sie etwas ändern, brauchen Sie eine Zahl, mit der Sie später vergleichen. Für die Serverseite ist das die Zeit bis zum ersten Byte: Sie umfasst Verbindungsaufbau und die Zeit, in der PHP und Datenbank die Seite erzeugen. Bilder, Schriften und Skripte, die der Browser danach lädt, sind darin nicht enthalten.

for i in 1 2 3 4 5; do
  curl -s -o /dev/null -H "Cache-Control: no-cache" \
    -w "ttfb %{time_starttransfer}s gesamt %{time_total}s status %{http_code}\n" \
    https://www.example.de/
done

Messen Sie mindestens fünfmal und nehmen Sie den mittleren Wert (Median), denn der erste Aufruf ist oft langsamer, weil Caches noch leer sind. Messen Sie neben der Startseite eine typische Unterseite, etwa einen Blogbeitrag oder eine Produktseite. Im Labor lieferte eine frische Installation Werte um 0,05 Sekunden. Mit einem absichtlich eingebauten Bremsklotz in einem Test-Plugin stieg die Zeit bis zum ersten Byte auf etwa 0,5 bis 0,7 Sekunden.

Achten Sie auf den Statuscode. Bei 301 messen Sie nur eine Weiterleitung, etwa von http auf https oder von der Domain ohne www. Verwenden Sie die endgültige URL, sonst sind die Werte zu gut.

Verifizieren: Sie haben für mindestens zwei URLs je fünf Messungen mit Status 200 notiert und kennen den Median der Zeit bis zum ersten Byte.

Schritt 2: Einschätzung im Website-Zustand lesen

WordPress prüft einige Leistungsmerkmale selbst. Öffnen Sie im Backend „Werkzeuge > Website-Zustand“, Reiter „Zustand“. Drei Tests sind für die Geschwindigkeit relevant:

Test	Was WordPress prüft	Grenzwert im Quellcode
Seiten-Cache	drei Anfragen an die Startseite, Suche nach Cache-Plugins und Cache-Headern wie age, x-cache oder cf-cache-status, Median der Antwortzeit	600 Millisekunden (Filter site_status_good_response_time_threshold)
Automatisch geladene Optionen	Anzahl und Größe der Optionen, die bei jedem Aufruf geladen werden	800.000 Byte (Filter site_status_autoloaded_options_size_limit)
Persistenter Objekt-Cache	ob ein Objekt-Cache wie Redis empfohlen wird	abhängig von Datenmenge und Serverausstattung

Die Grenzwerte stammen aus der Datei wp-admin/includes/class-wp-site-health.php in WordPress 7.1.2. Im Labor meldete der Test „Seiten-Cache“ keinen Wert, sondern einen Loopback-Fehler (cURL error 7: Failed to connect), weil der Container sich selbst unter der nach außen veröffentlichten Adresse nicht erreichen konnte. Dann ist der Test nicht aussagekräftig, und Ihre eigene Messung aus Schritt 1 ist die bessere Grundlage.

Die Größe der automatisch geladenen Optionen können Sie per WP-CLI direkt abfragen:

wp option list --autoload=on --format=total_bytes

Im Labor ergab das 40144 Byte bei 119 Optionen, weit unter dem Grenzwert. Mehrere Hunderttausend Byte sind ein eigener Engpass.

Verifizieren: Sie haben notiert, ob WordPress einen Seiten-Cache erkennt, welche Antwortzeit der Test meldet und wie groß die automatisch geladenen Optionen sind.

Schritt 3: Seitenaufruf mit Query Monitor zerlegen

Query Monitor ist ein Entwickler-Plugin aus dem WordPress-Verzeichnis (getestet Version 4.0.7). Es zeigt für jeden Seitenaufruf Erzeugungszeit, Speicherbedarf, Datenbankabfragen, HTTP-Anfragen an externe Dienste und PHP-Fehler. Laut Plugin-Seite sehen die Ausgabe standardmäßig nur Administratoren, normale Besucher bemerken nichts davon.

1. Installieren Sie unter „Plugins > Plugins hinzufügen“ das Plugin Query Monitor und aktivieren Sie es.
2. Rufen Sie angemeldet die langsame Seite im Frontend auf. In der Werkzeugleiste oben erscheinen vier Werte, im Labor zum Beispiel 0,55 s, 6,8 MB, 0,02 s und 74 Q: Seitenerstellungszeit, Speicher, Zeit für Datenbankabfragen und Anzahl der Abfragen.
3. Klicken Sie auf die Werte. Im Bereich „Datenbankabfragen“ filtern Sie nach Komponente, also nach Plugin, Theme oder WordPress-Kern.

Der Vergleich der beiden Zeiten ist der wichtigste Hinweis. Im Labor lag die Seitenerstellung bei 0,55 Sekunden, die Datenbank brauchte davon aber nur 0,02 Sekunden. Die Datenbank war also nicht das Problem, sondern PHP-Code. Umgekehrt deutet ein hoher Anteil der Datenbankzeit auf langsame oder zu viele Abfragen hin. Das Test-Plugin erzeugte außerdem 50 fast gleiche Einzelabfragen. Solche Wiederholungen markiert Query Monitor als doppelte Abfragen, sie sind ein typisches Zeichen für Code, der Daten in einer Schleife einzeln statt gesammelt lädt.

Prüfen Sie außerdem „HTTP-API-Abrufe“: Plugins, die bei jedem Aufruf einen externen Dienst fragen, bremsen um dessen Antwortzeit. Deaktivieren Sie Query Monitor nach der Analyse wieder.

Verifizieren: Sie kennen für die langsame Seite Erstellungszeit, Datenbankzeit und Anzahl der Abfragen und wissen, ob der größere Anteil auf PHP oder auf die Datenbank entfällt.

Schritt 4: Engpass mit wp profile eingrenzen

Das WP-CLI-Paket profile-command misst einen Seitenaufruf ohne Browser und ohne Plugin im Backend. Im Labor mit WP-CLI 2.12.0 schlug die Installation der neuesten Fassung fehl:

$ wp package install wp-cli/profile-command:@stable
Error: Package installation failed (Composer return code 2).
Reverted composer.json.

Der Grund steht in der composer.json des Pakets: Die Versionen ab 2.1.6 verlangen WP-CLI 2.13 oder neuer. Mit WP-CLI 2.12.0 installieren Sie deshalb gezielt Version 2.1.5, die auf WP-CLI 2.12 ausgelegt ist:

wp package install wp-cli/profile-command:2.1.5
wp profile stage --fields=stage,time,query_count

Der Befehl teilt den Aufruf der Startseite in drei Phasen: bootstrap (WordPress lädt, Plugins und Theme werden initialisiert), main_query (WordPress ermittelt, welcher Inhalt angefragt ist) und template (das Theme erzeugt die Seite). Das Ergebnis im Labor mit dem Test-Plugin:

stage       time     query_count
bootstrap   0.6916s  3
main_query  0.0047s  6
template    0.0768s  64
total (3)   0.773s   73

Die Phase bootstrap dominiert, also bremst etwas beim Laden der Plugins. Gehen Sie eine Ebene tiefer und lassen Sie sich nur die auffälligen Hooks zeigen:

wp profile stage bootstrap --spotlight --fields=hook,callback_count,time
wp profile hook init --spotlight --fields=callback,location,time

Der zweite Befehl nannte die Ursache mit Datei und Zeile:

callback        location                                    time
function(){}    langsam-test.php:3                          0.4014s
check_theme_switched()  wp-includes/theme.php:3483          0.0086s

Für die 64 Abfragen in der Phase template sortieren Sie nach Anzahl: wp profile hook wp_footer --orderby=query_count --order=DESC zeigte das Test-Plugin mit 50 Abfragen an erster Stelle. Eine andere URL messen Sie mit --url=https://www.example.de/beitrag/. Alle Hooks auf einmal liefert wp profile hook --all --spotlight --orderby=time --order=DESC.

Verifizieren: Sie kennen die Phase mit dem größten Zeitanteil und mindestens eine Funktion mit Datei, die deutlich mehr Zeit oder Abfragen verbraucht als der Rest.

Schritt 5: Verdacht bestätigen, ohne die Website zu verändern

Bevor Sie ein Plugin ersetzen, bestätigen Sie den Verdacht. wp profile kann einzelne Plugins für eine Messung überspringen, ohne sie zu deaktivieren:

wp profile stage --fields=stage,time
wp profile stage --skip-plugins=langsam-test --fields=stage,time

Im Labor sank die Gesamtzeit dadurch von 0,80 auf 0,21 Sekunden. Die Live-Website blieb dabei unverändert, weil --skip-plugins nur für diesen einen WP-CLI-Aufruf gilt. Das ist der sicherste Weg, auf einer Produktivseite zu testen. Ersetzen Sie langsam-test durch den Ordnernamen des verdächtigen Plugins, den wp plugin list in der Spalte name zeigt.

Auf der Staging-Kopie können Sie danach auch echt deaktivieren und mit curl aus Schritt 1 messen. Im Labor fiel die Zeit bis zum ersten Byte nach dem Deaktivieren des Test-Plugins von etwa 0,5 auf 0,04 bis 0,06 Sekunden. Die Werte mit und ohne Query Monitor lagen im Labor im selben Bereich, das Plugin verfälscht die Messung also nicht nennenswert.

Danach entscheiden Sie: Plugin ersetzen, Einstellung ändern oder den Autor mit Ihren Messwerten kontaktieren. Ein Seiten-Cache folgt erst, wenn der Code in Ordnung ist.

Verifizieren: Die Messung ohne das verdächtige Plugin ist deutlich schneller als der Ausgangswert. Liegt der Unterschied im Bereich der normalen Schwankung, ist das Plugin nicht die Ursache.

Schritt 6: Eine Änderung, eine Messung

Ändern Sie immer nur eine Sache und messen Sie danach mit demselben Befehl wie in Schritt 1. Werden Cache-Plugin, Bildoptimierung und neue PHP-Version gleichzeitig eingeführt, wissen Sie am Ende nicht, was geholfen und was geschadet hat. Tragen Sie jede Änderung mit Datum und Median in Ihre Tabelle ein.

Prüfen Sie außerdem die Grundlagen, die Query Monitor im Bereich „Arbeitsumgebung“ anzeigt: PHP-Version, Speicherlimit und ob ein Opcode-Cache aktiv ist. Eine veraltete PHP-Version kostet Leistung und Sicherheit zugleich, siehe PHP-Version für WordPress aktualisieren. Bleibt die Seite trotz sauberem Code langsam, liegt der Engpass eher am Server selbst. Hinweise zur Analyse von CPU, Arbeitsspeicher und Festplatte bietet die Anleitung Linux-Performance-Troubleshooting.

Geschwindigkeit ist kein einmaliger Zustand. Jedes Plugin-Update und jede neue Erweiterung kann die Werte verändern. Wiederholen Sie die Messung aus Schritt 1 deshalb nach größeren Updates und etwa einmal im Monat. Wer diese Routine aus Updates, Backups und Kontrolle nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein, sichert wöchentlich auf externen Speicher und beginnt mit einer einmaligen Analyse der Website.

Verifizieren: Ihre Tabelle enthält den Ausgangswert, jede Änderung und den Median danach. Der aktuelle Wert liegt unter dem Ausgangswert.

Typische Fehler

• Nur einmal gemessen: Einzelne Messungen schwanken stark. Im Labor lagen drei direkt aufeinanderfolgende Aufrufe zwischen 0,13 und 0,29 Sekunden. Arbeiten Sie immer mit dem Median mehrerer Messungen.
• Weiterleitung gemessen: Status 301 oder 302 in der curl-Ausgabe bedeutet, dass Sie nicht die eigentliche Seite messen. Verwenden Sie die endgültige URL.
• Loopback-Fehler im Website-Zustand: cURL error 7: Failed to connect beim Test „Seiten-Cache“ heißt, dass der Server sich selbst nicht erreicht. Der Test ist dann wertlos, das Problem liegt in der Server- oder DNS-Konfiguration und sollte mit dem Hoster geklärt werden, weil auch WP-Cron und der Website-Zustand selbst Loopback-Anfragen nutzen.
• wp package install scheitert mit Composer return code 2: Die neueste Version von profile-command passt nicht zu Ihrer WP-CLI-Version. Installieren Sie wp-cli/profile-command:2.1.5 oder aktualisieren Sie WP-CLI.
• Composer directory '/.wp-cli/packages' for packages couldn't be created: WP-CLI läuft ohne gültiges Home-Verzeichnis, typisch in Containern oder unter einem Systembenutzer. Setzen Sie die Umgebungsvariable WP_CLI_PACKAGES_DIR auf ein beschreibbares Verzeichnis.
• Cache verdeckt das Problem: Mit aktivem Seiten-Cache misst curl die zwischengespeicherte Seite. Für die Ursachensuche messen Sie angemeldet, mit wp profile oder auf Staging ohne Cache.

Häufige Fragen

Welche Zeit bis zum ersten Byte ist gut?

WordPress selbst bewertet im Website-Zustand eine mittlere Antwortzeit unter 600 Millisekunden als gut. Das ist eine Obergrenze, kein Ziel. Entscheidend ist, ob Ihre Änderungen den eigenen Ausgangswert verbessern.

Reicht nicht einfach ein Cache-Plugin?

Ein Seiten-Cache beschleunigt wiederholte Aufrufe durch nicht angemeldete Besucher. Er hilft nicht bei Backend, Warenkorb, Kasse, Suche und Formularen. Wenn ein Plugin bei jedem Aufruf 0,4 Sekunden verbraucht, bleibt dieser Teil der Website langsam. Finden Sie zuerst die Ursache und setzen Sie den Cache danach ein.

Was, wenn ich keinen SSH-Zugang habe?

Dann entfallen die Schritte 4 und 5 mit WP-CLI. Query Monitor liefert die meisten Hinweise auch allein über das Backend, und die Bestätigung erfolgt dann durch Deaktivieren auf einer Staging-Kopie. Fragen Sie Ihren Hoster, ob SSH in Ihrem Tarif verfügbar ist.

Testumfang

Wir haben das Ganze mit WordPress 7.1.2 in einer Docker-Testumgebung nachgestellt. Ein eigenes Test-Plugin bremste den Hook init um 0,4 Sekunden und erzeugte 50 Einzelabfragen, die sich mit Query Monitor gut aufspüren ließen. Seiten- und Objekt-Caches sowie Messungen bei einem Hoster haben wir nicht geprüft. Probieren Sie die Schritte deshalb zuerst auf einer Kopie Ihrer Website aus.

Fazit

Schneller wird WordPress durch Messen, nicht durch Raten: Ausgangswert mit curl, Einschätzung im Website-Zustand, Aufschlüsselung mit Query Monitor, Ursache mit wp profile und Bestätigung mit --skip-plugins. Danach ändern Sie eine Sache und messen wieder. Wer die regelmäßigen Updates und Backups rund um solche Kontrollen abgeben möchte, findet sie bei der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress Debug-Modus aktivieren und Error-Logs analysieren
• Staging-Umgebung für WordPress mit WP-CLI einrichten
• PHP-Version für WordPress aktualisieren
• Query Monitor im WordPress-Pluginverzeichnis
• WP-CLI-Handbuch: wp profile
• WordPress-Dokumentation: Website-Zustand (englisch)