Time to First Byte (TTFB)
Wie lange der Server bis zum ersten Byte braucht und warum jede andere Metrik darauf aufsetzt.
TTFB misst die Zeit zwischen Navigation Start und dem ersten Byte, das beim Browser ankommt. Bevor es da ist, kann visuell nichts passieren.
TTFB ist kein Core Web Vital. Bei langsamem LCP oder FCP ist es die Diagnose-Metrik, die du zuerst prüfst.
Was ist ein guter TTFB?
TTFB wird in Millisekunden gemessen. Beobachte das 75. Perzentil.
| TTFB bei p75 | Rating |
|---|---|
| ≤ 800 ms | Gut |
| ≤ 1.800 ms | Verbesserungswürdig |
| > 1.800 ms | Schlecht |
TTFB unter 200 ms ist top.
Was in TTFB einfließt
TTFB ist die Summe aus:
- Redirects. Jeder
301/302ist ein eigener Roundtrip. - DNS-Lookup. Erster Request an deinen Origin pro Session.
- TCP + TLS Handshake. Je ein Roundtrip auf einer frischen Verbindung (HTTP/2 nutzt Verbindungen wieder; HTTP/3 fasst es weiter zusammen).
- Request → Server-Verarbeitung → Response. Die Zeit, die der Server denkt, bevor er streamen kann.
- First-Byte-Ankunft. Netzwerk-Propagation vom Server zum Client.
Wird dein TTFB von Schritt 4 dominiert, liegt der Fix in deiner Application. Wird er von 1–3 oder 5 dominiert, liegt der Fix in deinem Netzwerk und deiner Edge-Aufstellung.
Wann TTFB reportet wird
TTFB wird aus der Navigation-Timing-API als responseStart - fetchStart errechnet. Der Tracker nimmt es bei jedem Pageview mit neuem Navigation-Eintrag mit.
TTFB hinter 103 Early Hints
Auf Sites hinter 103 Early Hints (Shopify-Storefronts, Cloudflare) liegt TTFB regelmäßig unter den Server-Timing-Phasen des Servers für denselben Pageview. Beides stimmt. responseStart markiert das erste Byte der ersten Response, und mit Early Hints ist das die vorläufige 103, die die Edge in etwa einem Roundtrip beantwortet; die echte Antwort deines Servers, mit dem Server-Timing-Header darauf, kommt später.
Um sie auseinanderzuhalten, speichert fastmon zusätzlich ttfb_final: das finalResponseHeadersStart des Browsers, das erste Byte der finalen Response. Der Tracker liest es mit derselben Aktivierungs-Korrektur und derselben 60-Sekunden-Kappung wie TTFB (Wire-Key frs), und der Collector verwirft einen Wert unter ttfb. So liest du das Paar:
ttfb_final | Bedeutung |
|---|---|
leer (NULL) | Der Browser meldet den Wert nicht (Safari, Firefox; Chromium vor 115), oder der Pageview war eine Soft-Navigation oder ein bfcache-Restore. |
gleich ttfb | Keine vorläufige Response; das erste Byte war das echte. |
größer als ttfb | Early Hints aktiv. Die Differenz ist der Vorsprung der Edge, und ttfb_final ist der Wert, in den edge_dur + backend_dur des Servers passen muss. |
TTFB selbst bleibt responseStart und damit vergleichbar mit CrUX und den Web-Vitals-Felddaten. ttfb_final ist ein Zeilenfeld auf POST /analytics/beacons, Teil des Besucher-Pageview-Details und eine aggregierbare Metrik (avg, p50 bis p99).
Im Dashboard laufen die Balken von Wohin die Zeit geht bis zum finalen ersten Byte, und eine Marke zeigt, wo der Browser das erste Byte gezählt hat. Die Response-Aufschlüsselung zeichnet den Vorsprung als eigene Zeile „Early Hints" in der Wartezeit und lässt den Übertragungsbalken bei den finalen Response-Headern beginnen. Im Explorer ist ttfb_final Metrik, Spalte und Drawer-Feld; der Pageview-Drawer zeigt es nur, wenn es von TTFB abweicht.
TTFB in fastmon ansehen
Die TTFB-Seite findest du unter Performance → TTFB. Oben stehen der Wert mit Bewertung und Trend, die Seitenaufrufe nach Bewertung und ein paar Sätze dazu, wohin die Zeit geht.
- Wohin die Zeit geht: Verbindung, Server, der Weg dazwischen und bei Seitenaufrufen ohne Server-Timing die ungemessene Wartezeit. Je ein Balken für alle Seitenaufrufe und für die, die CDN, Origin-Cache oder keins von beiden beantwortet hat.
- Server-Aufteilung: was Server-Timing meldet, also Edge, Origin, Datenbank, Cache, Suche, HTTP-Calls, eigener Code und Templates. Ohne den Header siehst du einen Block und einen Link zur Einrichtung.
- Verlauf: das gewählte Perzentil vor den Bewertungszonen, eine Linie pro Phase oder eine Linie pro Seitentyp, daneben die Verteilung. Das Maximieren-Icon zeigt das Diagramm im ganzen Fenster.
- Wo der TTFB langsam ist: Seitentypen, Seiten, CDN-Status, Login-Status, Origin-Hosts und mehr, nach langsamen Seitenaufrufen sortiert, jede Zeile mit Aufteilung.
- Cache und Origin: jede Cache-Ebene mit und ohne Hit, ihre Hit-Rate und die Backend-Zeit pro Origin-Host. Ein Host, der aus der Reihe fällt, wird hervorgehoben.
- Vergleichen: funktioniert wie auf der LCP-Seite, siehe Mit einem früheren Zeitraum vergleichen.
Schlechten TTFB verbessern
- HTML am Edge cachen. Eine statische oder nahezu statische Seite sollte aus einem CDN-Cache kommen, nicht von deinem Origin.
- Näher an deine Besucher rücken. Multi-Region-Origins oder ein gut verteilter Edge-Layer senken die RTT für alle außerhalb deiner Hauptregion.
- Server-Response profilen. APM, Server-Logs oder ein Server-Timing-Header, um den Engpass zu finden. Üblicherweise: eine langsame DB-Query, ein synchroner Third-Party-Call, oder SSR-React-Hydration, die zu viele Daten durchläuft.
- Redirect-Ketten reduzieren. Jeder Redirect ist ein voller Roundtrip.
http://→https://→www.→ Final-URL sind drei Roundtrips, bevor der Browser überhaupt das HTML hat. - HTTP/2 oder HTTP/3 nutzen. Ältere Origins handeln noch HTTP/1.1 aus.
Häufige Überraschungen
- Ein schneller TTFB auf Vercel/Netlify kann einen langsamen Origin verbergen. Der Edge cacht die Response; Cache-Misses können 10× langsamer sein. Cache-Hit-Rate neben TTFB checken.
- TTFB enthält keine Client-Render-Zeit. Eine Seite mit schnellem TTFB und langsamem LCP schickt viel Arbeit an den Browser, nicht den Server. SSR hilft nicht, wenn Hydration der Bottleneck ist.
- Service-Worker-Caches beeinflussen den TTFB-Wert. Wenn dein Service Worker die Navigation bedient, kann TTFB bei Wiederbesuchen nahezu null sein.
Nächste Schritte
- FCP: TTFBs nachgelagerter Nachbar.
- LCP: was ein langsamer TTFB meist kaputt macht.
- Web-Vitals-Übersicht.