Was ist Time to First Byte (TTFB)?
Time to First Byte (TTFB) ist die Zeit, die der Browser braucht, um das erste Byte einer HTTP-Response zu empfangen, nachdem er den Request gesendet hat. Es captured alles, was passiert, bevor Rendering starten kann: DNS-Lookup, TCP-Handshake, TLS-Negotiation, Server-Processing, Database-Queries und Network-Round-Trip.
TTFB ist fundamental für perceived Performance — jede subsequent Metric (LCP, FCP, TTI) ist davon bounded.
TTFB-Phasen
| Phase | Was passiert | Typischer Anteil |
|---|---|---|
| DNS-Lookup | Domain zu IP resolven | 0-100ms |
| TCP-Connection | 3-way Handshake | ~1 RTT |
| TLS-Negotiation | SSL-Handshake | 1-2 RTTs |
| Request gesendet | HTTP-Request | Trivial |
| Server-Processing | App + Database | 0-2000+ ms |
| First Byte ankommt | Network-Transfer back | 1 RTT |
TTFB-Thresholds
| TTFB | Rating |
|---|---|
| ≤ 800ms | Good |
| 800ms - 1800ms | Needs Improvement |
| > 1800ms | Poor |
Wie TTFB messen
JavaScript-API
new PerformanceObserver((list) => {
for (const entry of list.getEntriesByType('navigation')) {
const ttfb = entry.responseStart - entry.requestStart;
console.log('TTFB:', ttfb, 'ms');
}
}).observe({ type: 'navigation', buffered: true });cURL
curl -w "time_starttransfer: %{time_starttransfer}\n" -o /dev/null -s https://example.comTools
| Tool | Typ |
|---|---|
| Lighthouse / PageSpeed Insights | Lab |
| Chrome DevTools Network | Lab |
| WebPageTest | Lab aus mehreren Regionen |
| web-vitals.js | RUM |
| Search Console CWV-Report | Field |
| CrUX Dashboard | Field, public |
| Server-Logs | Server-side, nur App-Phase |
Häufige TTFB-Optimierungen
1. CDN mit Edge-Caching
Edge-Server respondieren aus RAM in < 50ms. Größtes TTFB-Win.
2. Dynamic-HTML cachen
SSR-Pages können oft 60s-5min am CDN gecached werden.
3. Database-Queries optimieren
Slow N+1 Queries sind der #1 Server-side TTFB-Killer.
4. HTTP/2 oder HTTP/3 nutzen
Eliminiert Head-of-Line-Blocking.
5. TLS 1.3 für schnelleren Handshake
1 RTT statt 2 für neue Connections, 0 RTT für resumed.
6. Connection-Reuse
Keep-alive + HTTP/2-Multiplexing.
7. Geo-distributed Origins
Origin in us-east-1, User in Sydney = 200ms+ Network alone.
8. Pre-rendern oder Static-Generate
Wenn Page nicht dynamic sein muss.
TTFB und Core Web Vitals
- LCP startet Measuring vom Request, also TTFB ist in LCP enthalten
- Wenn TTFB 1s ist, LCP ist mindestens 1s
- TTFB um 500ms verbessern verbessert LCP typisch um ~500ms
Häufige TTFB-Fallstricke
- Origin in einer Region, User worldwide.
- SSR ohne Caching.
- N+1 DB-Queries.
- Synchronous External API-Calls.
- Cold-Start Serverless-Functions.
- Heavy Middleware.
- TLS-Resumption disabled.
- HTTP/1.1 only.
FAQ: Time to First Byte
Was ist eine gute TTFB?
≤ 800ms im 75. Perzentil per Google.
Ist TTFB ein Core Web Vital?
Nein — INP, LCP und CLS sind es. Aber TTFB ist empfohlene Diagnostic-Metric.
Wie verbessert CDN TTFB?
Edge-Server cachen Responses nahe an Usern.
Warum ist meine TTFB anders auf Lab vs Field?
Lab-Tests nutzen kontrollierte Networks; Field misst echte User.
Hurts HTTPS TTFB?
Leicht — TLS adds ~1-2 RTTs. Aber TLS 1.3 minimiert Cost.
Wie verbessere ich TTFB auf einer Dynamic-Page?
Am CDN cachen, DB-Queries optimieren, zu Edge-SSR moven.
Unterschied zwischen TTFB und Server-Response-Time?
Server-Response-Time = nur App/DB-Phase. TTFB = Network + App.
TTFB aus echten Regionen mit LoadFocus testen
LoadFocus läuft Lighthouse + Load-Tests aus 25+ globalen Regionen. Registrieren bei loadfocus.com/signup.
Verwandte LoadFocus-Tools
Setze dieses Konzept mit LoadFocus in die Praxis um — derselben Plattform, die alles antreibt, was du gerade gelesen hast.