Einleitung
TTFB (Time To First Byte) ist die Zeit, die vergeht, nachdem der Browser eines Nutzers eine Anfrage an den Server gesendet hat, bis das erste Byte zurĂĽckkommt. Diese Metrik misst direkt die Server-Verarbeitungsleistung, das Netzwerk und die Backend-Stack-Performance.
Die kritische Kette aus Core Web Vitals-Perspektive:
TTFB ↑ → HTML kommt spät → Rendering verzögert sich → LCP ↑ → CWV FAIL → Ranking sinkt1. Was Misst TTFB? (Echter Aufschlüsselung)
TTFB = DNS + TCP + SSL + Server ProcessingDen größten Anteil hat in der Regel der Bereich Server Processing (60–80 %).
Diese Phase umfasst:
- PHP-AusfĂĽhrung
- WordPress-Bootstrap
- Plugin-AusfĂĽhrung
- Datenbankabfrage
- Cache-Lookup
2. Gute TTFB-Werte
| TTFB | Status |
|---|---|
| <100 ms | Ausgezeichnet |
| 100–300 ms | Gut |
| 300–600 ms | Mittel |
| 600–1000 ms | Schlecht |
| >1000 ms | Kritisch |
SEO-Ziel:
TTFB < 300 ms3. Benchmark-Testumgebung (Kontext)
Die numerischen Beispiele in diesem Artikel stammen aus der folgenden Umgebung:
Testumgebung:
- 2 vCPU
- 4 GB RAM
- NVMe-Festplatte
- Ubuntu + Nginx
- PHP 8.2
- MariaDB
Last:
- 20 gleichzeitige Nutzer
- 1.000 Anfragen
Test-Tool:
ab -n 1000 -c 20 https://site.com/4. Cache-Auswirkung (Echter Benchmark)
Szenario: Cache vs. kein Cache
| Setup | TTFB | Beschreibung |
|---|---|---|
| Kein Cache | 920 ms | PHP + DB bei jeder Anfrage |
| Nginx FastCGI | 280 ms | HTML-Cache |
| LiteSpeed + LSCache | 120 ms | Full-Page-Cache |
Warum der Unterschied?
Ohne Cache:
Request → PHP → Plugin → DB → Render → ResponseMit Cache:
Request → Cache → Response5. Festplattentyp (I/O → DB-Latenz → TTFB)
| Festplatte | Durchschn. Abfragelatenz | TTFB |
|---|---|---|
| HDD | 10–20 ms | 900+ ms |
| SATA SSD | 2–5 ms | 300–500 ms |
| NVMe | <1 ms | 120–250 ms |
Technische Erklärung
WordPress führt beim Laden einer Seite in der Regel 100–300 Datenbankabfragen aus. Wenn die Festplatte langsam ist, wartet jede Abfrage:
Langsame Festplatte → Query-Wait ↑ → PHP wartet → Response verzögert sich → TTFB steigt6. PHP-Worker & CPU-Auswirkung
Benchmark
| PHP-Worker | Warteschlange | TTFB |
|---|---|---|
| 2 | Ja | 880 ms |
| 4 | Gering | 420 ms |
| 8 | Keine | 180 ms |
Warum?
Worker voll → Request-Warteschlange → Wartezeit → TTFB steigtWenn CPU niedrig:
Ausführung langsam → Response verzögert sich → TTFB steigt7. CDN-Auswirkung (Edge-Response)
| Setup | TTFB |
|---|---|
| Kein CDN | 620 ms |
| CDN (Cache aus) | 280 ms |
| CDN (Cache an) | 110 ms |
Warum?
- Edge-Server ist näher am Nutzer
- TCP-Verbindungszeit sinkt
- Bei Cache wird der Origin-Server nicht kontaktiert
8. Server-Stack-Vergleich
| Stack | TTFB | Grund |
|---|---|---|
| Apache (kein Cache) | 900 ms | Prozessbasiert, kein Cache |
| Nginx + FastCGI | 320 ms | Ereignisgesteuert |
| LiteSpeed + LSCache | 120 ms | Eingebauter Cache |
Kommentar
- Apache → prozessbasiert → langsam
- Nginx → ereignisgesteuert → schnell
- LiteSpeed → integrierter Cache → am schnellsten
9. Wie Wird TTFB Gemessen?
Per Kommandozeile:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\n" https://site.comAlternative Tools:
| Tool | Funktion |
|---|---|
| PageSpeed Insights | Lab + echte Nutzerdaten |
| WebPageTest | Waterfall |
| GTmetrix | Performance-Analyse |
| Pingdom | Standortbasiertes Testen |
10. Ideale Server-Architektur
Empfohlener Stack fĂĽr guten TTFB:
Nginx / LiteSpeed
+
FastCGI Cache
+
Redis Object Cache
+
PHP 8.2+
+
MariaDB
+
NVMe-Festplatte
+
CDNMit dieser Konfiguration wird in der Regel erreicht:
TTFB: 70 – 200 ms11. Reale Einflussverteilung
| Faktor | Einfluss |
|---|---|
| Cache | 35 % |
| Festplatte | 20 % |
| CPU | 15 % |
| PHP-Worker | 15 % |
| CDN | 10 % |
| Netzwerk | 5 % |
FAZIT
TTFB ist kein Frontend-Problem. Es liegt größtenteils am Server und am Hosting.
Ohne einen niedrigeren TTFB:
- Kann LCP nicht sinken
- Können sich die Core Web Vitals nicht verbessern
- Kann PageSpeed nicht steigen
- Kann die SEO-Performance nicht steigen
Deshalb lautet die Reihenfolge fĂĽr die Performance-Optimierung:
1. Server
2. Cache
3. CDN
4. Datenbank
5. Frontend