Time to First Byte (TTFB): Definition, Ursachen, Optimierung

TTFB misst die Zeit von Request bis First-Byte der Response. Cappt LCP. ≤ 800ms = gut. Beeinflusst von Server, DB, Network, CDN.

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

PhaseWas passiertTypischer Anteil
DNS-LookupDomain zu IP resolven0-100ms
TCP-Connection3-way Handshake~1 RTT
TLS-NegotiationSSL-Handshake1-2 RTTs
Request gesendetHTTP-RequestTrivial
Server-ProcessingApp + Database0-2000+ ms
First Byte ankommtNetwork-Transfer back1 RTT

TTFB-Thresholds

TTFBRating
≤ 800msGood
800ms - 1800msNeeds Improvement
> 1800msPoor

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.com

Tools

ToolTyp
Lighthouse / PageSpeed InsightsLab
Chrome DevTools NetworkLab
WebPageTestLab aus mehreren Regionen
web-vitals.jsRUM
Search Console CWV-ReportField
CrUX DashboardField, public
Server-LogsServer-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.

Wie schnell ist Ihre Website?

Steigern Sie ihre Geschwindigkeit und SEO nahtlos mit unserem kostenlosen Geschwindigkeitstest.

Kostenloser Websitespeed-Test

Analysieren Sie die Ladegeschwindigkeit Ihrer Website und verbessern Sie ihre Leistung mit unserem kostenlosen Seitengeschwindigkeits-Checker.

×