Transloadit

Was ist die Zeit bis zum ersten Byte?

Die Zeit bis zum ersten Byte (TTFB) ist die Zeitspanne vom Start einer Anfrage oder Navigation bis zum Eintreffen des ersten Bytes der Antwort. Je nach Startpunkt der Messung kann sie neben der Serververarbeitung auch Weiterleitungen, DNS-Auflösung sowie Verbindungs- und TLS-Aufbau umfassen.

Wie die Zeit bis zum ersten Byte zustande kommt

TTFB markiert den Zeitpunkt, an dem eine Antwort einzutreffen beginnt. Alles davor zählt dazu, alles danach nicht. Für eine im Browser gemessene Seitennavigation nennt web.dev die Phasen, die addiert werden: Weiterleitungszeit, Start des Service Workers, DNS-Auflösung, Verbindungsaufbau und TLS-Aushandlung sowie die Anfrage bis zum ersten Antwortbyte. Browser stellen diesen Zeitpunkt als responseStart in den APIs Navigation Timing und Resource Timing bereit. Bei einem CDN-Cache-Treffer entfällt der Weg zum Origin-Server. Deshalb kann dieselbe URL bei einem Cache-Miss und einem Cache-Treffer sehr unterschiedliche Werte aufweisen. Wenn ein CDN zwischengeschaltet ist, kann ein Antwortheader namens Server-Timing den Wert weiter aufschlüsseln: Amazon CloudFront kann beispielsweise melden, ob eine Antwort ein Cache-Treffer oder ein Cache-Miss war, und bei einem Cache-Miss die Latenz bis zum ersten Byte am Origin-Server getrennt von der eigenen ausweisen. Server und Vermittler wählen aus, welche Metriken für Server-Timing sie senden. Der Header zeigt daher nur, was sie melden. Bei der Medienauslieferung erfasst TTFB die Verzögerung, bevor die Übertragung einer Playlist, eines Segments, eines Bildes oder einer API-Antwort beginnt. Wie lange der anschließende Download des Antwortkörpers dauert, sagt der Wert nicht aus.

Wichtige Fakten

  1. Warum melden zwei Tools für dieselbe Anfrage unterschiedliche TTFB-Werte? Sie beginnen die Zeitmessung an unterschiedlichen Punkten. Die Bibliothek web-vitals misst eine Navigation von ihrem Start beziehungsweise bei einer vorgerenderten Seite von deren Aktivierung bis zu responseStart. Das umfasst Weiterleitungen, DNS-Auflösung, Verbindungsaufbau und TLS. Chrome DevTools bezeichnet eine enger gefasste Phase als „Waiting (TTFB)“: Sie folgt auf die separaten Phasen für DNS-Auflösung, Verbindungsaufbau und das Senden der Anfrage und umfasst die Latenz für einen Hin- und Rückweg sowie die Zeit, die der Server zur Vorbereitung der Antwort benötigt hat. Bei curl läuft die Messung von time_starttransfer ab Beginn der Übertragung und umfasst Namensauflösung, Verbindungsaufbau und TLS-Handshake. Ein CDN-Protokoll ist noch enger gefasst: Das Feld time-to-first-byte von CloudFront wird auf dem Server gemessen, vom Empfang der Anfrage bis zum Schreiben des ersten Antwortbytes. Es enthält daher keine Netzwerkzeit auf Clientseite. Gleichen Sie die Definitionen ab, bevor Sie Werte vergleichen oder einen Zielwert festlegen.
  2. Gibt es einen Zielwert? Für Seitennavigationen gibt web.dev eine grobe Orientierung: 0,8 Sekunden oder weniger sind gut, mehr als 1,8 Sekunden sind schlecht. TTFB ist kein Core Web Vital. web.dev bezeichnet die Schwellenwerte als grobe Orientierung, weil eine serverseitig gerenderte Seite einen höheren TTFB-Wert haben und ihre Inhalte trotzdem früher anzeigen kann als eine Seite, die im Browser gerendert wird. Diese Orientierung gilt für Navigationsanfragen, also HTML-Dokumente. Für Bilder, Videosegmente oder API-Aufrufe nennt web.dev keinen Schwellenwert.
  3. Lässt sich TTFB im tatsächlichen Einsatz für Medien messen, die von einem CDN-Hostnamen ausgeliefert werden? Nur wenn das CDN dies erlaubt, indem es einen Antwortheader namens Timing-Allow-Origin sendet, der den Ursprung der Seite oder den Platzhalter * aufführt. Bei einer ursprungsübergreifenden Ressource, die ohne diesen Header gesendet wird, meldet die Resource Timing API für responseStart den Wert 0, ebenso für die Zeitstempel von DNS-Auflösung, Verbindungsaufbau und Anfrage. Auch responseStart hat bei einer sofort aus einem Cache abgerufenen Ressource den Wert 0. Filtern Sie Nullwerte daher heraus, statt sie in den Durchschnitt einzubeziehen. Derselbe Header steuert, ob eine Seite Metriken für Server-Timing von einem anderen Ursprung lesen kann.
  4. Zählt eine Early-Hints-Antwort mit Statuscode 103 als erstes Byte? In den Browser-APIs ja: responseStart gibt den Zeitpunkt der ersten vorläufigen Antwort zurück, sofern eine vorliegt. web.dev erklärt, dass eine Antwort mit Statuscode 103 als erste Bytes zählt. finalResponseHeadersStart gibt stattdessen den Beginn der endgültigen Antwort an. Chrome meldete ab Version 115 die endgültige Antwort als responseStart und nahm diese Änderung in Version 133 zurück. Deshalb können sich TTFB-Daten aus Chrome bei Websites, die Early Hints senden, zwischen diesen Versionen verschieben. Ein frühzeitiges Senden der Antwortheader hat einen ähnlichen Effekt. Ein niedrigerer TTFB-Wert nach dem Aktivieren einer der beiden Maßnahmen ist daher für sich genommen kein Beleg dafür, dass der Hauptinhalt früher eintrifft.

Wann die Zeit bis zum ersten Byte wichtig ist

Vergleichen Sie die TTFB bei einem CDN-Cache-Miss und einem Cache-Treffer für dieselbe URL unter ansonsten ähnlichen Bedingungen. So erkennen Sie, wie viel zusätzliche Latenz der Ablauf bei einem Cache-Miss gegenüber dem reinen Auslieferungsweg verursacht. Eine niedrige TTFB garantiert keine schnelle vollständige Antwort, da Download- und Rendering-Zeit separat hinzukommen.

Wie Transloadit bei der Zeit bis zum ersten Byte hilft

Im Smart CDN von Transloadit fällt bei einem Cache-Miss Verarbeitungsaufwand an, der bei einem Cache-Treffer entfällt. Bei einem Cache-Miss importiert die Anfrage das Original aus Ihrem Speicher und führt Ihr Template aus, um das Ergebnis zu erzeugen; bei einem Cache-Treffer wird das zwischengespeicherte Ergebnis vom Edge ausgeliefert, ohne etwas auszuführen. Die Produktseite zum Smart CDN führt die gemessenen Anfragezeiten bei kaltem und warmem Cache getrennt auf und empfiehlt, bei kaltem Cache die Zeit für den Abruf der Quelle und die Transformation einzuplanen.

Die Produktseite gibt weder an, ob ihre Zeitmessungen die Zeit bis zum ersten Byte oder die vollständige Antwortzeit erfassen, noch ob bei einem Cache-Miss bereits Antwortbytes gesendet werden, bevor die Verarbeitung abgeschlossen ist. Sie kennzeichnet die Zeiten als Messwerte mit Datumsangabe, die je nach Arbeitslast variieren. Messen Sie Ihr eigenes Template, indem Sie einen Cache-Miss mit einem Cache-Treffer für dieselbe URL vergleichen. Eine erste und eine wiederholte Anfrage bilden nicht automatisch dieses Paar: Die URL kann bereits am Edge zwischengespeichert sein, und der Robot /file/serve weist Browser standardmäßig an, Ergebnisse zwischenzuspeichern. Daher kann eine wiederholte Browseranfrage lokal beantwortet werden. Die Produktseite empfiehlt, bei der Fehlersuche die Cache-Antwortheader zu prüfen.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline

Verbinden Sie Uploads, Verarbeitung, KI, Storage und Auslieferung über eine deklarative API – um Encoding-Stack, Skalierung und ständig wechselnde Formate müssen Sie sich nicht selbst kümmern.

Transloadit kostenlos ausprobieren