Time to First Byte (TTFB) ist die Zeit zwischen dem Start einer Anfrage und dem Eintreffen des ersten Bytes der Antwort. Bei Seitenaufrufen umfasst sie Weiterleitungen, DNS-Auflösung, TCP- und TLS-Verbindungsaufbau sowie die Verarbeitung auf dem Server. TTFB ist selbst kein Core Web Vital, begrenzt aber direkt, wie schnell Inhalte erscheinen können.
Was ist Time to First Byte (TTFB)?
Time to First Byte (TTFB) misst, wie lange ein Client vom Start einer Anfrage bis zum Eintreffen des ersten Bytes der Antwort wartet. Sie ist eine der ältesten Web-Performance-Metriken und nach wie vor eine der nützlichsten, denn bevor die ersten Bytes des HTML ankommen, kann nichts gerendert werden. Eine langsame TTFB verschiebt jeden späteren Meilenstein nach hinten, auch den Largest Contentful Paint.
TTFB ist eine grundlegende Diagnosemetrik und keine der Core Web Vitals. Sie zeigt, ob die Verzögerung entsteht, bevor der Browser überhaupt Inhalte erhält. Das deutet meist auf den Netzwerkpfad oder den Server hin.
Was die TTFB umfasst
Bei einem im Browser gemessenen Seitenaufruf setzt sich die TTFB aus mehreren Phasen zusammen:
- Weiterleitungen, falls die angefragte URL zunächst mit 301 oder 302 antwortet.
- Start eines Service Workers, falls einer registriert ist.
- DNS-Auflösung des Hostnamens.
- TCP-Verbindungsaufbau und TLS-Handshake.
- Übertragung der Anfrage und Verarbeitung auf dem Server: Routing, Anwendungscode, Datenbankabfragen, Cache-Zugriffe und Template-Rendering.
- Der Rückweg des ersten Bytes zum Client.
In der Navigation Timing API entspricht die TTFB dem Wert responseStart relativ zum Beginn der Navigation. Serverseitige Werkzeuge melden oft eine engere Zahl, nämlich die Zeit vom Empfang einer Anfrage bis zum Senden des ersten Bytes. Beides ist nützlich, aber nicht dasselbe. Geben Sie daher immer an, welche Variante ein Dashboard zeigt. Die Differenz ist Netzwerk-Latenz plus Verbindungsaufbau.
Was ist ein guter TTFB-Wert?
Die Empfehlungen von Google auf web.dev besagen, dass die meisten Websites eine Navigations-TTFB von höchstens 0,8 Sekunden am 75. Perzentil anstreben sollten; Werte über 1,8 Sekunden gelten als schlecht. Das ist ein grober Richtwert und keine feste Regel: Eine serverseitig gerenderte Seite, die ihr HTML streamt, kann eine höhere TTFB haben und trotzdem schnell laden, während eine clientseitig gerenderte App eine niedrige TTFB, aber spät sichtbare Inhalte haben kann. TTFB sollten Sie deshalb immer zusammen mit dem LCP bewerten.
Hilfreich ist außerdem eine Betrachtung nach Segmenten. Gecachte und nicht gecachte Antworten, angemeldete und anonyme Nutzer sowie verschiedene Regionen haben oft sehr unterschiedliche Werte. Ein gutes p75 für die gesamte Website kann ein schlechtes Erlebnis für Nutzer weit entfernt vom Ursprungsserver verbergen oder für Seiten, die den CDN-Cache stets umgehen. Ebenso wichtig ist der Verlauf über die Zeit: Ein schleichender Anstieg nach Releases ist ein frühes Zeichen für wachsenden Backend-Aufwand pro Anfrage.
Beispiel: TTFB messen und aufschlüsseln
Im Browser lässt sich der Wert direkt auslesen:
const [nav] = performance.getEntriesByType("navigation");
console.log("TTFB ms:", nav.responseStart - nav.startTime);
console.log("DNS ms:", nav.domainLookupEnd - nav.domainLookupStart);
console.log("Connect + TLS ms:", nav.connectEnd - nav.connectStart);Auf der Kommandozeile zeigt curl dieselbe Aufteilung für eine einzelne Anfrage:
curl -o /dev/null -s -w "dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer}\n" https://example.com/Serverseitig kann der Response-Header Server-Timing melden, wie lange einzelne Schritte gedauert haben, etwa Server-Timing: db;dur=120, render;dur=45. Browser und RUM-Werkzeuge können diese Angaben neben der TTFB anzeigen. Die Zahlen in diesem Beispiel sind rein illustrativ; entscheidend ist, welche Phase dominiert.
So senken Sie die TTFB
- Nah am Nutzer cachen mit einem CDN, wo möglich auch für HTML.
- Unnötige Weiterleitungen entfernen, etwa von http auf https und anschließend auf einen www-Host.
- Das Backend beschleunigen: langsame Datenbankabfragen, N+1-Muster und blockierende Aufrufe nachgelagerter Services beheben.
- Verbindungen warm halten mit HTTP/2 oder HTTP/3, Wiederverwendung von Verbindungen und TLS Session Resumption.
- Kaltstarts vermeiden in Serverless- oder automatisch skalierten Umgebungen, wenn der Pfad latenzkritisch ist.
- Die Antwort streamen, damit die ersten Bytes gesendet werden, bevor die gesamte Seite fertig ist.
Häufige Fehler
- Die serverseitige Verarbeitungszeit mit der Browser-TTFB zu vergleichen und sich über die Differenz zu wundern.
- Nur von einem Standort in der Nähe des Rechenzentrums aus zu messen.
- Synthetische Messungen mit warmem Cache für repräsentativ zu halten, obwohl viele echte Nutzer einen Cache-Miss erleben.
- Die TTFB auf Kosten des LCP zu optimieren, etwa durch eine leere Hülle, die Inhalte erst viel später rendert.
- Mittelwerte statt p75 und p95 zu betrachten, wodurch langsame Regionen und Cache-Misses verborgen bleiben.
Wie Obseria hilft
Das Real User Monitoring von Obseria erfasst die TTFB und ihre Phasen aus echten Sitzungen, synthetische Prüfungen messen sie von festgelegten Standorten aus. Da Browser-Spans über Distributed Tracing mit Backend-Traces verknüpft sind, lässt sich eine langsame TTFB bis zu dem Service, der Abfrage oder dem nachgelagerten Aufruf zurückverfolgen, der die Zeit verbraucht hat.
