Diese Seite wurde von der Cloud Translation API übersetzt.

Zeit bis zum ersten Byte (TTFB)

Jeremy Wagner

Barry Pollard

Unterstützte Browser

<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">

Quelle

Was ist TTFB?

TTFB ist eine Metrik, die die Zeit zwischen der Anforderung einer Ressource und dem Eintreffen des ersten Byte einer Antwort misst.

Eine Visualisierung des Timings von Netzwerkanfragen. Die Zeitangaben von links nach rechts sind Weiterleitung, Service Worker-Init, Service Worker-Abrufereignis, HTTP Cache, DNS, TCP, Anfrage, Early Hints (103), Antwort (die sich mit Aufforderung zum Entladen überschneidet), Verarbeitung und Laden. Die zugehörigen Timings sind "redirectStart" und "redirectEnd", "fetchStart", "domainLookupStart", "domainLookupEnd", "connectStart", "secureConnectionStart", "connectEnd", "requestStart", "interimResponseStart", "responseStart, unloadEventStart, unloadEventEnd, responseEnd, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, domComplete", "loadEventStart" und "loadEventEnd". — </ph> Ein Diagramm mit den Phasen der Netzwerkanfrage und ihrer zeitlichen Abfolge. TTFB misst die verstrichene Zeit zwischen `startTime` und `responseStart`.

TTFB ist die Summe der folgenden Anfragephasen:

Weiterleitungszeitpunkt
Service Worker-Startzeit (falls zutreffend)
DNS-Lookup
Verbindung und TLS-Verhandlung
Anfrage bis zu dem Punkt, an dem das erste Byte der Antwort eingegangen ist

Wenn Sie die Latenz beim Einrichten der Verbindung und auf dem Back-End reduzieren, kann die TTFB sinken.

Weitere Definitionen von TTFB

Die vorherige Definition entspricht der konventionellen Definition, aber mit der Einführung von Early Hints wird das als „erste Byte“ bezeichnet. zur Diskussion steht. Der firstInterimResponseStart ist ein neuer zusätzlicher Timing-Eintrag für responseStart, mit dem zwischen diesen unterschieden werden kann. Er wird jedoch nur in Chrome- und Chromium-basierten Browsern unterstützt. Daher messen einige Browser und Tools (einschließlich CrUX) bis zum Eingang der ersten Byte, einschließlich Early Hints.

„Early Hints“ ist nur ein neueres Beispiel für frühzeitiges Antworten. Einige Server lassen das Leeren der Dokumentantwort zu, bevor der Haupttext verfügbar ist – entweder nur mit den HTTP-Headern oder mit dem <head>-Element. Beides kann hinsichtlich der Funktion „Early Hints“ als ähnlich angesehen werden, wodurch auch die Definition dessen verschlechtert, was TTFB misst.

Als Maß dafür, wann die „ersten Bytes“ von verwertbaren Daten für das Dokument vom Browser empfangen werden, könnten alle diese Definitionen als gültig betrachtet werden. Es lohnt sich, Daten frühzeitig zurückzusenden, wenn die vollständige Antwort länger dauern wird. Das Wichtigste ist, zu verstehen, was das von Ihnen verwendete Tool misst und wie sich die gemessene Plattform darauf auswirkt. Dadurch ist es schwierig, die TTFB über verschiedene Plattformen oder Technologien hinweg zu vergleichen, je nachdem, welche Funktionen sie verwenden und wie sich das auf die verwendeten TTFB-Messungen auswirkt.

Die TTFB wird auch oft als Indikator für die Antwortzeit von Servern oder Hosts betrachtet. Sie wird jedoch von Faktoren beeinflusst, die außerhalb dieser direkten Kontrolle liegen, z. B. die Weiterleitungszeit, unabhängig davon, ob sie von einem Cache-Treffer eines CDN bereitgestellt wird oder einen potenziell längeren Weg zurück zu einem Ursprungsserver zurücklegen muss. Dies ist besonders bei Felddaten deutlich. Lab-Tests sind in der Regel weniger stark von diesen Faktoren betroffen, da die End-URL normalerweise getestet wird und Caching-Änderungen häufig wiederholt negiert werden. Aus diesem Grund gibt Lighthouse statt der TTFB die Serverantwortzeit an, um dies klarer zu machen. Bei anderen Lab-Tools ist dies jedoch möglicherweise nicht der Fall.

Was ist ein guter TTFB-Wert?

Da TTFB nutzerbezogenen Messwerten wie First Contentful Paint (FCP) und Largest Contentful Paint (LCP) vorausgeht, sollte Ihr Server schnell genug auf Navigationsanfragen reagieren, damit das 75. Perzentil der Nutzer eine FCP innerhalb des „guten“ Grenzwert. Als groben Anhaltspunkt sollten die meisten Websites eine TTFB von 0, 8 Sekunden oder weniger anstreben.

Gute TTFB-Werte sind maximal 0,8 Sekunden, schlechte Werte über 1,8 Sekunden und alles dazwischen muss verbessert werden — . Gute TTFB-Werte liegen bei maximal 0,8 Sekunden, schlechte Werte über 1,8 Sekunden.

Wichtiger Hinweis:Da die TTFB kein Core Web Vitals-Messwert ist, müssen Websites die „guten“ Messwerte nicht unbedingt erfüllen. TTFB-Grenzwert, vorausgesetzt, dass dies nicht daran hindert, bei den wichtigsten Messwerten gute Ergebnisse zu erzielen.

Websites unterscheiden sich in der Art und Weise, wie sie Inhalte bereitstellen. Eine niedrige TTFB ist entscheidend, um dem Kunden das Markup so schnell wie möglich zu vermitteln. Wenn eine Website jedoch das ursprüngliche Markup schnell liefert, dieses Markup jedoch von JavaScript mit aussagekräftigen Inhalten gefüllt wird, was bei Single-Page-Anwendungen (SPAs) der Fall ist, ist es besonders wichtig, die geringstmögliche TTFB zu erreichen, damit der Client das Markup früher rendern kann.

Umgekehrt kann eine vom Server gerenderte Website, die weniger clientseitige Arbeit erfordert, eine höhere TTFB haben, aber bessere FCP- und LCP-Werte als eine vollständig vom Kunden gerenderte Erfahrung. Aus diesem Grund stellen die TTFB-Grenzwerte nur einen groben Leitfaden dar und müssen mit der Bereitstellung der Hauptinhalte auf Ihrer Website abgewogen werden.

TTFB messen

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

Feld-Tools

Lab-Tools

Im Bereich „Netzwerk“ der Entwicklertools von Chrome
WebPageTest

TTFB in JavaScript messen

Sie können die TTFB von Navigationsanfragen im Browser mit der Navigation Timing API messen. Das folgende Beispiel zeigt, wie Sie einen PerformanceObserver erstellen, der 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
});

Die web-vitals-JavaScript-Bibliothek kann die TTFB im Browser auch präziser messen:

import {onTTFB} from 'web-vitals';

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

Ressourcenanfragen messen

TTFB gilt für alle Anfragen, nicht nur für Navigationsanfragen. Besonders Ressourcen, die auf ursprungsübergreifenden Servern gehostet werden, können zu Latenz führen, da Verbindungen zu diesen Servern eingerichtet werden müssen. Um die TTFB für Ressourcen im Feld zu messen, verwenden Sie die Resource Timing API in einem 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 Snippet, das zum Messen der TTFB für eine Navigationsanfrage verwendet wurde, mit der Ausnahme, dass Sie nicht nach 'navigation'-Einträgen, sondern nach 'resource'-Einträgen fragen. Dabei wird auch berücksichtigt, dass einige vom primären Ursprung geladene Ressourcen möglicherweise den Wert 0 zurückgeben, da die Verbindung bereits offen ist oder eine Ressource sofort aus einem Cache abgerufen wird.

TTFB verbessern

Tipps zur Verbesserung der TTFB für Ihre Website finden Sie in unserem ausführlichen Leitfaden zur Optimierung der TTFB.