Ihre PageSpeed Insights zeigen einen roten TTFB an. Der unmittelbare Reflex: „Sie brauchen mehr CPU“ oder „Sie brauchen einen VPS“. Drei Wochen später hat sich die Rechnung verdoppelt und die Serververzögerung hat sich nur um 40 ms verändert. Das Szenario ist banal: Wir haben ein Symptom behandelt, ohne den Link zu identifizieren, der das erste Byte verzögert.
Time To First Byte misst die Zeit zwischen der HTTP-Anfrage und dem Empfang des ersten Antwortbytes. Es verdichtet DNS, TLS, Netzwerkrouting, Serverwarteschlange, PHP-Ausführung, SQL-Abfragen und optional API-Aufrufe. Durch den Kauf von CPU wird die langsame DNS-Auflösung oder ein nicht indizierter SQL-Join nicht verkürzt.
Richtig messen – ohne im Cache hängen zu bleiben
Ein „Labor“-TTFB und ein „echter Benutzer“-TTFB erzählen zwei Geschichten. PageSpeed und Lighthouse messen häufig aus Google-Rechenzentren, teilweise mit Hot-Caching. WebPageTest, ein Curl von Ihrem Computer oder RUM-Berichte (Real User Monitoring) runden das Bild ab.
Mindestverfahren:
- **Testen Sie „origin“ – Direkte Server-URL oder „Cache-Control: no-cache“-Header.
- Cache EIN/AUS vergleichen – eine statische Seite (
/favicon.ico) mit einer dynamischen PHP-Seite. - Wiederholung aus zwei Regionen – Netzwerklatenz ≠ Anwendungslangsamkeit.
- Beachten Sie die Uhrzeit – ein langsamer Pool um 14:00 Uhr. kann um 3 Uhr morgens akzeptabel sein.
| Messung | Was es isoliert | Grenze |
|---|---|---|
| TTFB statische „.html“-Seite | Netzwerk + Webserver | PHP/SQL ignorieren |
| Dynamische TTFB-Seite | Volle Kette | Mischt mehrere Ursachen |
curl -w '%{time_starttransfer}' | Rohserver, reproduzierbar | Kein Browser-Rendering |
| PHP-FPM-Protokolle „slowlog“ | Skripte > Schwellenwert (z. B. 5 s) | Kann MySQL allein nicht sehen |
Ein exzellenter TTFB auf einer CDN-Seite beweist nicht, dass Ihr WordPress schnell ist. Es beweist vor allem, dass der Edge-Cache funktioniert.
Die Kette der Verdächtigen, in nützlicher Reihenfolge
Sehen Sie sich diese Liste an, bevor Sie ein „Langsamer Server“-Ticket eröffnen. Jeder Link hat unterschiedliche Signale.
DNS. Eine falsch konfigurierte TTL oder ein langsamer Resolver verlängert die Zeit um 100–300 ms, bevor der Server überhaupt antwortet. Überprüfen Sie dies mit „dig“ oder Tools wie DNSPerf.
TLS und HTTP/2. Die SSL-Aushandlung über ein schlecht verkettetes Zertifikat oder eine veraltete Verschlüsselung kostet Zeit. Selten der Hauptengpass, aber messbar.
PHP-FPM-Warteschlange. Wenn alle Worker beschäftigt sind, wartet die Anfrage – der TTFB geht hoch, ohne dass das Skript langsam ist. Symptom: Variable TTFB, Spitzen korrelieren mit dem Verkehr.
Langsames PHP-Skript. WordPress-Plugins, starkes Autoload, unnötige Schleifen. Das FPM „slowlog“ und Blackfire identifizieren die Täterfunktion.
Datenbank. Abfragen ohne Indizes, überladene „Postmeta“-Tabellen, fehlender Objektcache (Redis). MySQL „slow_query_log“ ist dein Freund.
Externe Aufrufe. Synchrone Wetter-, CRM- und Zahlungs-APIs beim Seitenrendering blockieren den gesamten TTFB.
Typische Szenarien: A vs. B
| Symptom | Wahrscheinliche Ursache | Aktion vor dem Upgrade |
|---|---|---|
| TTFB stabil ~800 ms, geringer Datenverkehr | SQL-Abfrage oder Plugin | Profiler, Index, Objektcache |
| TTFB 200 ms morgens, 2 s mittags | Gesättigte FPM-Arbeiter | Passen Sie „pm.max_children“ an, nicht nur CPU |
| TTFB OK in Frankreich, langsam in den USA | Geographie, nicht Server | CDN oder nächstgelegene Region |
| TTFB 50 ms auf „.html“, 900 ms auf „/“ | Anwendung, kein Hosting | OPcache, Seitencache, WP optimieren |
Der Gipfel: Die CPU ist selten der erste Hebel
Folgendes wird auf den Seiten „Premium 8 vCPU-Angebot“ behandelt.
Der Host kann einen schnellen Server bereitstellen. Ihre Abfrage „SELECT * FROM wp_postmeta“ wird nicht neu geschrieben. Die Verwechslung der beiden verzögert die tatsächliche Korrektur und erhöht das Budget ohne Beweise.
Entscheide dich und gehe ohne blinden Fleck voran
- Messung Original-TTFB, mit und ohne Cache, über 24 Stunden.
- Isolieren Sie den Link (DNS → FPM → SQL → API).
- Reparieren Sie die Anwendung, bevor Sie Hosting-Angebote vergleichen.
- Erneuter Test mit demselben Szenario; Bewerten Sie erst dann einen höheren Plan oder einen Unterkunftsvergleicher.
Vergleichen Sie diese Diagnose bei WordPress-Sites mit den Anleitungen OPcache und PHP-FPM. Um Hosts entsprechend Ihren Netzwerkbeschränkungen zu filtern, konsultieren Sie das Verzeichnis.
Häufig gestellte Fragen
Welcher TTFB ist für eine PHP-Site akzeptabel?
Unter 200 ms auf der Serverseite für eine dynamische, nicht zwischengespeicherte Seite ist solide. Graben Sie die Kette zwischen 200 und 600 ms. Darüber hinaus sollten Sie messen, bevor Sie weitere Ressourcen kaufen.
Beinhaltet TTFB CDN?
Ja, wenn die Anfrage über ein CDN erfolgt. Testen Sie den Ursprung mit Cache-Bypass, um die tatsächliche PHP-Leistung zu sehen.
Woher weiß ich, ob es PHP oder die Datenbank ist?
Vergleichen Sie eine statische Seite mit einer dynamischen, aktivieren Sie das MySQL-Protokoll für langsame Abfragen und profilieren Sie es im Staging mit Blackfire oder Xdebug.
Löst ein Wechsel des Hosts hohe TTFB auf?
Selten ohne Korrektur der Anwendung. Ein überlasteter Server kann die Latenz erhöhen; Eine langsame SQL-Abfrage bleibt überall langsam.
Wenn das nächste Mal ein roter TTFB erscheint, stellen Sie vor dem CPU-Kauf eine Frage: Welcher Schritt in der Kette hat wie lange gedauert? Die Antwort steht oft in einem Protokoll, nicht in einem Zitat.