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 sinkt
1. Was Misst TTFB? (Echter AufschlĂĽsselung)
TTFB = DNS + TCP + SSL + Server Processing
Den 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 ms
3. 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 → Response
Mit Cache:
Request → Cache → Response
5. 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 steigt
6. 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 steigt
Wenn CPU niedrig:
Ausführung langsam → Response verzögert sich → TTFB steigt
7. 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.com
Alternative 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
+
CDN
Mit dieser Konfiguration wird in der Regel erreicht:
TTFB: 70 – 200 ms
11. 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