Time to First Byte (TTFB)

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.

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:

1. Redirects. Jeder 301/302 ist ein eigener Roundtrip.
2. DNS-Lookup. Erster Request an deinen Origin pro Session.
3. TCP + TLS Handshake. Je ein Roundtrip auf einer frischen Verbindung (HTTP/2 nutzt Verbindungen wieder; HTTP/3 fasst es weiter zusammen).
4. Request → Server-Verarbeitung → Response. Die Zeit, die der Server denkt, bevor er streamen kann.
5. 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 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

1. HTML am Edge cachen. Eine statische oder nahezu statische Seite sollte aus einem CDN-Cache kommen, nicht von deinem Origin. Der größte Hebel.
2. 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.
3. 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.
4. Redirect-Ketten reduzieren. Jeder Redirect ist ein voller Roundtrip. http:// → https:// → www. → Final-URL sind drei Roundtrips, bevor der Browser überhaupt das HTML hat.
5. 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.