Zeit bis zum ersten Byte (TTFB)

Browser Support

  • Chrome: 43.
  • Edge: 12.
  • Firefox: 35.
  • Safari: 11.

Source

Was ist TTFB?

Mit diesem Messwert wird die Zeit zwischen der Anfrage einer Ressource und dem Eintreffen des ersten Bytes einer Antwort gemessen.

Eine Visualisierung der Zeitangaben für Netzwerkanfragen. Die Zeitangaben von links nach rechts sind „Weiterleitung“, „Service Worker Init“, „Service Worker Fetch-Ereignis“, „HTTP-Cache“, „DNS“, „TCP“, „Anfrage“, „Early Hints (103)“, „Antwort“ (überschneidet sich mit „Prompt for Unload“), „Verarbeitung“ und „Laden“. Die zugehörigen Zeitangaben sind „redirectStart“ und „redirectEnd“, „fetchStart“, „domainLookupStart“, „domainLookupEnd“, „connectStart“, „secureConnectionStart“, „connectEnd“, „requestStart“, „interimResponseStart“, „responseStart“, „unloadEventStart“, „unloadEventEnd“, „responseEnd“, „domInteractive“, „domContentLoadedEventStart“, „domContentLoadedEventEnd“, „domComplete“, „loadEventStart“ und „loadEventEnd“.
Ein Diagramm der Phasen von Netzwerkanfragen und die zugehörigen Zeitangaben. Mit der TTFB wird die Zeit gemessen, die zwischen startTime und responseStart verstrichen ist.

Die TTFB ist die Summe der folgenden Anfragephasen:

  • Weiterleitungszeit
  • Startzeit des Service Workers (falls zutreffend)
  • DNS-Lookup
  • Verbindung und TLS-Verhandlung
  • Anfrage bis zum Zeitpunkt, an dem das erste Byte der Antwort eingegangen ist

Wenn Sie die Latenz bei der Verbindungseinrichtung und im Backend reduzieren, kann sich die TTFB verringern.

TTFB und frühzeitige Hinweise

Die Einführung von 103 Early Hints führt zu einiger Verwirrung darüber, was mit „erstes Byte“ bei der TTFB gemessen wird. Die 103 Early Hints werden als „erste Bytes“ gezählt. finalResponseHeadersStart ist ein zusätzlicher Zeiteintrag für responseStart, mit dem der Beginn der zu erfassenden endgültigen Dokumentantwort (normalerweise eine HTTP 200-Antwort) gemessen wird.

Frühzeitige Hinweise sind nur ein neueres Beispiel für eine schnelle Reaktion. Einige Server ermöglichen das frühzeitige Ausgeben der Dokumentantwort, bevor der Haupttext verfügbar ist – entweder nur mit den HTTP-Headern oder mit dem <head>-Element. Beides kann als ähnlich wie Early Hints betrachtet werden. Dies ist ein weiterer Grund dafür, dass diese Messwerte als reponseStart und damit als TTFB gemessen werden.

Es ist sinnvoll, Daten frühzeitig zurückzusenden, wenn die vollständige Antwort noch etwas Zeit in Anspruch nimmt. Dies erschwert jedoch den Vergleich der TTFB-Werte zwischen verschiedenen Plattformen oder Technologien, je nachdem, welche Funktionen verwendet werden und wie sich dies auf die verwendete TTFB-Messung auswirkt. Am wichtigsten ist es, zu verstehen, was mit dem von Ihnen verwendeten Tool gemessen wird und wie sich das auf die gemessene Plattform auswirkt.

Was ist ein guter TTFB-Wert?

Da der TTFB vor nutzerorientierten Messwerten wie First Contentful Paint (FCP) und Largest Contentful Paint (LCP) kommt, sollte Ihr Server auf Navigationsanfragen schnell genug reagieren, damit für den 75. Perzentil der Nutzer ein FCP innerhalb des Grenzwerts „gut“ erreicht wird. Grob gesagt sollten die meisten Websites eine TTFB von 0, 8 Sekunden oder weniger anstreben.

Gute TTFB-Werte liegen bei 0,8 Sekunden oder weniger, schlechte Werte bei mehr als 1,8 Sekunden.Werte dazwischen müssen verbessert werden.
Gute TTFB-Werte liegen bei 0,8 Sekunden oder weniger, schlechte Werte bei mehr als 1,8 Sekunden.

TTFB messen

Die TTFB kann auf folgende Arten im Lab oder im Feld gemessen werden.

Tools für die Arbeit im Außendienst

Lab-Tools

TTFB in JavaScript messen

Mit der Navigation Timing API können Sie die TTFB von Navigationsanfragen im Browser messen. Im folgenden Beispiel wird gezeigt, wie eine PerformanceObserver erstellt wird, die auf einen navigation-Eintrag wartet und ihn in der Console protokolliert:

new PerformanceObserver((entryList) => {
  const [pageNav] = entryList.getEntriesByType('navigation');

  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
  type: 'navigation',
  buffered: true
});

Mit der web-vitals-JavaScript-Bibliothek lässt sich der TTFB auch noch kürzer im Browser messen:

import {onTTFB} from 'web-vitals';

// Measure and log TTFB as soon as it's available.
onTTFB(console.log);

Ressourcenanfragen messen

Der TTFB gilt für alle Anfragen, nicht nur für Navigationsanfragen. Insbesondere Ressourcen, die auf Servern mit unterschiedlichen Ursprüngen gehostet werden, können zu Latenzen führen, da Verbindungen zu diesen Servern eingerichtet werden müssen. Wenn Sie den TTFB für Ressourcen im Feld messen möchten, verwenden Sie die Resource Timing API in einer PerformanceObserver:

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();

  for (const entry of entries) {
    // Some resources may have a responseStart value of 0, due
    // to the resource being cached, or a cross-origin resource
    // being served without a Timing-Allow-Origin header set.
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

Das vorherige Code-Snippet ähnelt dem, das zum Ermitteln der TTFB für eine Navigationsanfrage verwendet wurde. Der einzige Unterschied besteht darin, dass hier nicht nach 'navigation'-Einträgen, sondern nach 'resource'-Einträgen abgefragt wird. Außerdem wird berücksichtigt, dass einige vom primären Ursprung geladene Ressourcen den Wert 0 zurückgeben können, da die Verbindung bereits geöffnet ist oder eine Ressource sofort aus einem Cache abgerufen wird.

TTFB verbessern

Eine Anleitung zur Verbesserung des TTFB Ihrer Website finden Sie in unserem ausführlichen Leitfaden zur TTFB-Optimierung.