--- title: "WordPress schneller machen: Ladezeit messen und Engpässe systematisch finden" date: 2026-09-30T21:49:13+02:00 modified: 2026-10-23T22:12:51+02:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-schneller-machen-ladezeit-messen-engpaesse-finden keywords: - WordPress - Performance - Query Monitor - WP-CLI - Ladezeit reading_time: 10 --- # 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. **Kurzfassung:** Messen Sie die Zeit bis zum ersten Byte (TTFB) mit `curl` mehrmals und notieren Sie den Median als Ausgangswert. Prüfen Sie unter „Werkzeuge > Website-Zustand“, ob WordPress einen Seiten-Cache erkennt und wie groß die automatisch geladenen Optionen sind. Query Monitor zeigt pro Aufruf Zeit, Speicher und Datenbankabfragen nach Komponente, `wp profile` nennt die langsame Funktion samt Datei und Zeile. Ändern Sie immer nur eine Sache und messen Sie danach erneut. Arbeiten Sie dafür möglichst auf einer Staging-Kopie. ## 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](https://s-edv.com/anleitungen/wordpress-staging-umgebung-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. ```bash 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. > **Prüfen:** 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: ```bash $ 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. > **Prüfen:** 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. > **Prüfen:** 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: ```plaintext $ 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: Datei: `composer.json` ```bash 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: ```plaintext 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: ```bash $ 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: ```plaintext 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`. > **Prüfen:** 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: ```bash $ 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. > **Prüfen:** 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. Notieren Sie Datum und Median. 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](https://s-edv.com/anleitungen/wordpress-php-version-aktualisieren-kompatibilitaet-pruefen). 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](https://s-edv.com/anleitungen/linux-performance-troubleshooting-hohe-last-iostat-ss-htop). Wiederholen Sie die Messung aus Schritt 1 nach größeren Updates und monatlich. Updates, Backups und Kontrolle können Sie abgeben: Die [WordPress-Wartung von wordpressupdate.de](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=49) 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. > **Prüfen:** 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. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=49) von Marcel Schönfelder. ## Weiterführende Anleitungen und Quellen - [WordPress Debug-Modus aktivieren und Error-Logs analysieren](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) - [Staging-Umgebung für WordPress mit WP-CLI einrichten](https://s-edv.com/anleitungen/wordpress-staging-umgebung-wp-cli-einrichten) - [PHP-Version für WordPress aktualisieren](https://s-edv.com/anleitungen/wordpress-php-version-aktualisieren-kompatibilitaet-pruefen) - [Query Monitor im WordPress-Pluginverzeichnis](https://wordpress.org/plugins/query-monitor/) - [WP-CLI-Handbuch: wp profile](https://developer.wordpress.org/cli/commands/profile/) - [WordPress-Dokumentation: Website-Zustand (englisch)](https://wordpress.org/documentation/article/site-health-screen/)