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. Das ist der Boden, auf dem alles andere steht: bevor das erste Byte da ist, kann visuell nichts passieren.
TTFB ist kein Core Web Vital. Eine diagnostische Metrik, aber die wichtigste, wenn du langsamen LCP oder FCP auseinandernehmen willst.
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 |
Die Schwellen rechnen die realistischen Kosten eines kalten Caches auf typischen Mobilnetzen schon ein. TTFB unter 200 ms (warmer Cache, naher PoP) ist top. Über 1 Sekunde fühlt sich für den Besucher an wie eine Seite, die einfach nicht losläuft.
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. Die beiden messen unterschiedliche Responses desselben Requests.
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 zeigt die TTFB-Seite ein Panel Early Hints, wo sich die beiden Werte unterscheiden: den Vorsprung am gewählten Perzentil, die zwei ersten Bytes als einen geteilten Balken und den Anteil der Pageviews, auf denen das finale gemessen wurde (ein Chromium-Timing, und Soft-Navigationen haben keins). Die Response-Aufschlüsselung zeichnet den Vorsprung als eigene Zeile „Early Hints" innerhalb der Wartezeit, lässt die Server-Phasen dort enden und beginnt den Übertragungsbalken bei den finalen Response-Headern statt beim ersten Byte. Im Explorer ist ttfb_final eine zeichenbare Metrik, eine sortierbare Spalte und ein Drawer-Feld; der Pageview-Drawer zeigt es nur, wenn es von TTFB abweicht.
TTFB in fastmon ansehen
Der Performance-Bereich zeigt TTFB bei p50, p75, p95.
- Nach Land: Group by
country. RTT zu deinem Origin ist der dominante Faktor für kalte Verbindungen, und er ist regional schief. Liegt dein Origin in Frankfurt, ist TTFB nach São Paulo schlecht, egal wie schnell dein Server ist. - Nach URL: Group by URL. Wenn eine einzelne Seite deutlich schlechter ist, macht die Application Per-Page-Arbeit (DB-Query, Third-Party-Fetch), die andere nicht haben.
- Nach Release:
compare_to_release_id. Ein Backend-Deploy mit einem neuen synchronen externen Call zeigt sich hier zuerst.
Schlechten TTFB verbessern
- HTML am Edge cachen. Eine statische oder nahezu statische Seite sollte aus einem CDN-Cache kommen, nicht von deinem Origin. Der größte Hebel.
- 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. Die meisten modernen Stacks tun das schon, aber prüfen; ä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.