TTFB bei echten Nutzern (Felddaten)

Was diese Prüfung macht

Liest das 75.-Perzentil der Time to First Byte aus dem Chrome UX Report aus – die Zeit vom Moment, in dem der Browser einer echten Chrome-Nutzerin den Navigations-Request abschickt, bis zum Eintreffen des ersten Antwort-Bytes. CrUX aggregiert das über ein gleitendes 28-Tage-Fenster. TTFB ist eine experimentelle Core Web Vitals-Metrik, kein eigenständiges Ranking-Signal, aber sie deckelt jede andere Paint-Metrik: Nichts kann gerendert werden, bevor das erste Byte ankommt.

Feld-TTFB (p75)	Bewertung
≤ 800 ms	Gut
800–1.800 ms	Verbesserungsbedürftig
> 1.800 ms	Schlecht

TTFB faltet alles zwischen Nutzer:in und Origin zusammen: DNS-Lookup, TLS-Handshake, Redirect-Ketten, Request-Queuing auf deinem Server, Anwendungsarbeit und die Zeit, die das Rendern serverseitiger Templates braucht. Alles, was passiert, bevor das erste Byte rausgeht, summiert sich in dieser Zahl.

Warum es zählt

TTFB ist kein Core Web Vital, aber er ist die vorgelagerte Schranke für jedes Core Web Vital. Ein TTFB von 2 Sekunden bedeutet, dass LCP unmöglich unter 2,5 s liegen kann – es bleiben nur 500 ms für alles andere. TTFB um 500 ms zu senken, senkt LCP fast geschenkt um einen ähnlichen Betrag.

Er deckt außerdem Probleme auf, die Laborwerkzeuge übersehen:

• Weit entfernte Nutzer:innen. Ein Server in us-east-1 wirkt von einem US-basierten Laborwerkzeug aus schnell, für eine brasilianische Nutzerin furchtbar. Feld-TTFB zeigt dir die geografische Realität.
• Kalte Serverzustände. Wenn dein Origin Serverless-Funktionen ausführt, taucht Cold-Start-Latenz erst in Realnutzer-Daten auf; Laborwerkzeuge wärmen den Cache für dich vor.
• Redirect-Ketten. Ein 301 von example.com → www.example.com → https://www.example.com/ fügt pro Hop einen vollen Round-Trip zum TTFB hinzu. Laborwerkzeuge überspringen diese entweder oder melden sie anders.

Wie du ihn verbesserst

1. Stelle ein CDN vor deinen Origin. Selbst für dynamische Seiten kann ein CDN TLS-Sessions und Verbindungszustände zwischenspeichern. Cloudflare, Fastly, Bunny und Vercel Edge haben alle kostenlose oder nahezu kostenlose Tiers:

# Cloudflare-Proxy an (oranges Wölkchen) — sofort ein CDN
# nslookup deine Domain — du solltest Cloudflare-IPs sehen, nicht deinen Origin

2. Cache das HTML am Edge. Für Seiten, die nicht pro Nutzer:in ausgespielt werden müssen (Marketing, Blog, Docs), setze Cache-Control: s-maxage=86400, stale-while-revalidate=604800, damit das CDN gecachetes HTML in <50 ms zurückgibt:

Cache-Control: public, s-maxage=86400, stale-while-revalidate=604800

Die Direktive stale-while-revalidate erlaubt dem CDN, eine veraltete Antwort sofort auszuliefern, während es im Hintergrund revalidiert – das Beste aus beiden Welten.

3. Eliminiere Redirect-Ketten. Mit curl prüfen:

curl -sIL https://example.com/ | grep -E "^(HTTP|Location)"

Jede Location:-Zeile ist ein zusätzlicher Round-Trip. Häufige Übeltäter: http→https, apex→www (oder www→apex) und Unterschiede beim abschließenden Slash. Falls möglich, auf einen einzigen 301 zusammenfassen.

4. Profiliere deinen Server mit Server-Timing. Füge Response-Header hinzu, die den DevTools verraten, wohin die Zeit geflossen ist:

// Express/Node-Beispiel
res.setHeader("Server-Timing", "db;dur=120, render;dur=45, total;dur=170");

Chromes Network-Tab zeigt dann eine Phasen-Aufschlüsselung, sodass du siehst, ob die Zeit in DB-Queries, Template-Rendering oder Framework-Overhead steckt.

5. Setze HTTP/2 oder HTTP/3 ein. TCP-Slow-Start und Head-of-Line-Blocking unter HTTP/1.1 kosten echten TTFB. Alle modernen CDNs verwenden standardmäßig HTTP/2; viele liefern bereits HTTP/3 (QUIC) für noch bessere Performance in Mobilfunknetzen.

6. Verkürze die Distanz zum Origin. Hast du einen Single-Region-Origin und globale Nutzer:innen, denke über Replikation oder den Umzug auf ein Edge-gerendertes Framework nach (Astro, Next.js auf Vercel, SvelteKit auf Cloudflare Workers).

Häufige Fragen

Mein TTFB ist auf meiner Dev-Maschine schnell, in CrUX aber langsam. Warum?

Du sitzt direkt neben deinem Origin; deine echten Nutzer:innen nicht. Schalte ein CDN davor, und deine globalen Nutzer:innen werden einen TTFB sehen, der näher an deiner Dev-Erfahrung liegt. Die andere häufige Ursache ist Cold-Start-Latenz bei Serverless-Deployments – dein erster Request nach einer Leerlaufphase zahlt 500–2.000 ms Strafe.

Soll ich mir Sorgen um TTFB machen, wenn er in CrUX als „experimentell” markiert ist?

Ja. Experimentell ist er in dem Sinne, dass Google ihn noch nicht zum formalen Core Web Vital gemacht hat, aber der Wert ist sauber definiert und die Schwellen sind stabil. Behandle ihn als Frühindikator für deinen LCP – ist der TTFB schlecht, wird es der LCP fast sicher auch.

Mein TTFB ist gut, aber der LCP ist schlecht. Was ist los?

Der Engpass liegt stromabwärts: Rendering, Bildladevorgänge oder render-blockierende Ressourcen. Sieh dir als Nächstes die LCP-Regel an. Feld-TTFB gut + LCP schlecht heißt, dein Server ist schnell und die Langsamkeit liegt im Client; Feld-TTFB schlecht + LCP schlecht heißt: TTFB zuerst beheben, denn jeder Fix dort schlägt sich geschenkt in LCP-Verbesserungen nieder.