Time to First Byte (TTFB) Probleme finden und beheben

Time to First Byte (TTFB) Probleme finden und beheben

Dieser Artikel ist Teil unseres Time to First Byte (TTFB)-Leitfadens. TTFB ist eine Diagnosemetrik, die die Zeit zwischen der Anforderung einer Seite durch einen Benutzer und dem Empfang des ersten Bytes der Antwort durch den Browser misst. Obwohl TTFB selbst kein Core Web Vital ist, beeinflusst es direkt sowohl den First Contentful Paint (FCP) als auch den Largest Contentful Paint (LCP). Eine gute TTFB liegt unter 800 Millisekunden beim 75. Perzentil.

In unserem vorherigen Artikel haben wir über die Time to First Byte gesprochen. Wenn Sie sich über die Grundlagen informieren möchten, ist dies ein großartiger Ausgangspunkt.

In diesem Artikel werden wir uns darauf konzentrieren, die verschiedenen Time to First Byte-Probleme zu identifizieren und dann zu erklären, wie man sie behebt.

TTFB-TIPP: In den meisten Fällen ist die TTFB für Erstbesucher viel schlechter, da diese noch keinen DNS-Cache für Ihre Website haben. Beim Tracking der TTFB ist es sehr sinnvoll, zwischen Erst- und wiederkehrenden Besuchern zu unterscheiden.

Schritt 1: Überprüfen Sie die TTFB in der Search Console

"Der erste Schritt zur Besserung ist die Einsicht, dass man ein Problem hat." Bevor wir also etwas tun, um die Time to First Byte zu beheben, sollten wir sicherstellen, dass wir wirklich ein Problem mit der TTFB haben.

Leider wird die Time to First Byte in der Google Search Console nicht erfasst, sodass wir auf pagespeed.web.dev zurückgreifen müssen, um die CrUX-Daten unserer Website abzufragen. Glücklicherweise sind die Schritte einfach: Navigieren Sie zu pagespeed.web.dev, geben Sie die URL Ihrer Seite ein und stellen Sie sicher, dass die Schaltfläche "origin" ("Ursprung") aktiviert ist (da wir seitenweite Daten benötigen und nicht nur Daten der Startseite). Wechseln Sie nun zwischen Mobile und Desktop und überprüfen Sie die Time to First Byte für beide Gerätetypen.

Im folgenden Beispiel sehen Sie eine Website, die die Core Web Vitals aufgrund einer hohen TTFB nicht besteht.

Schritt 1b: Verwenden Sie den Server-Timing-Header für tiefere Einblicke

Der HTTP-Antwort-Header Server-Timing ermöglicht es Ihrem Server, Backend-Leistungsmetriken direkt an den Browser zu übermitteln. Dies macht es möglich, genau zu bestimmen, welcher Teil der Serververarbeitung langsam ist, ohne Zugriff auf Serverprotokolle zu benötigen.

Ein typischer Server-Timing-Header sieht so aus:

Server-Timing: db;dur=53, app;dur=120, cache;desc="miss"

In diesem Beispiel meldet der Server drei Zeitwerte:

• db;dur=53: Die Datenbankabfrage dauerte 53 Millisekunden.
• app;dur=120: Die Anwendungslogik (Template-Rendering, API-Aufrufe usw.) dauerte 120 Millisekunden.
• cache;desc="miss": Der Server-Cache wurde für diese Anfrage nicht verwendet (ein Cache-Miss).

Sie können diese Werte in den Chrome DevTools ablesen, indem Sie den Reiter Network (Netzwerk) öffnen, die Dokumentanforderung auswählen und zum Abschnitt "Server Timing" im Reiter Timing scrollen. Die Werte sind auch über die PerformanceServerTiming-API in JavaScript zugänglich:

const [navigation] = performance.getEntriesByType('navigation');
if (navigation.serverTiming) {
  navigation.serverTiming.forEach(entry => {
    console.log(`${entry.name}: ${entry.duration}ms (${entry.description})`);
  });
}

Wenn Ihr Server noch keine Server-Timing-Header sendet, sollten Sie in Betracht ziehen, diese hinzuzufügen. Die meisten Web-Frameworks machen dies einfach. In PHP können Sie den Header vor jeder Ausgabe hinzufügen:

header('Server-Timing: db;dur=' . $dbTime . ', app;dur=' . $appTime);

In Node.js mit Express:

res.setHeader('Server-Timing', `db;dur=${dbTime}, app;dur=${appTime}`);

Der Server-Timing-Header ist besonders nützlich, wenn er mit Real User Monitoring kombiniert wird, da er es Ihnen ermöglicht, die serverseitige Leistung mit der TTFB zu korrelieren, die echte Benutzer erleben. Erfahren Sie mehr darüber, wie 103 Early Hints die wahrgenommene TTFB weiter reduzieren kann, indem Ressourcenhinweise gesendet werden, bevor die vollständige Antwort bereit ist.

Schritt 2: RUM-Tracking einrichten

Die Time to First Byte ist eine knifflige Metrik. Wir können uns nicht einfach auf synthetische Tests verlassen, um die TTFB zu messen, da im wirklichen Leben andere Faktoren zu Schwankungen der TTFB beitragen. Um Antworten auf alle oben genannten Fragen zu erhalten, müssen wir die Daten im echten Leben messen und alle Probleme protokollieren, die bei der Time to First Byte auftreten können. Dies wird Real User Monitoring genannt, und es gibt verschiedene Möglichkeiten, RUM-Tracking zu aktivieren. Wir haben CoreDash genau für diese Anwendungsfälle entwickelt. CoreDash ist ein kostengünstiges, schnelles und effektives RUM-Tool, das die Arbeit erledigt. Natürlich gibt es viele RUM-Lösungen auf dem Markt, und diese werden die Arbeit ebenfalls erledigen (allerdings zu einem höheren Preis).

Wie man über die TTFB denken sollte: Stellen Sie sich vor, ein Webserver wäre eine Restaurantküche und ein Benutzer, der eine Webseite anfordert, wäre ein hungriger Kunde, der eine Bestellung aufgibt. Time to First Byte (TTFB) ist die Zeitspanne zwischen der Bestellung des Kunden und dem Beginn der Zubereitung des Essens durch die Küche.
Bei der TTFB geht es also NICHT darum, wie schnell die gesamte Mahlzeit gekocht (First Contentful Paint) und serviert (Largest Contentful Paint) wird, sondern vielmehr darum, wie reaktionsschnell die Küche auf die anfängliche Anfrage reagiert.
RUM-Tracking ist vergleichbar mit der Befragung der Kunden, um ihr kulinarisches Erlebnis zu verstehen. Sie könnten feststellen, dass Kunden, die weiter von der Küche entfernt sitzen, weniger Aufmerksamkeit vom Kellner erhalten und später bedient werden, oder dass Stammkunden bevorzugt behandelt werden, während neue Besucher länger auf einen Tisch warten müssen.

Schritt 2b: Erstellen Sie eine Leistungs-Baseline

Bevor Sie Änderungen vornehmen, sollten Sie eine Baseline für Ihre TTFB festlegen. Erfassen Sie die TTFB im 75. Perzentil über die folgenden Dimensionen hinweg, da dies Ihnen später dabei helfen wird, die Wirksamkeit Ihrer Optimierungen zu messen:

1. Gesamte TTFB (Mobile und Desktop separat): Erfassen Sie das 75. Perzentil für jeden Gerätetyp.
2. Top 10 Seiten nach Traffic: Erfassen Sie die TTFB für Ihre am stärksten frequentierten Seiten einzeln.
3. Neue Besucher vs. wiederkehrende Besucher: Erstbesucher haben in der Regel eine höhere TTFB aufgrund von DNS- und Verbindungsaufwand.
4. Top 5 Länder nach Traffic: Die geografische Entfernung zu Ihrem Server wirkt sich erheblich auf die TTFB aus.
5. TTFB-Teilbereichsanalyse: Erfassen Sie das 75. Perzentil für jeden Teilbereich (Waiting, Cache, DNS, Connection, Request).

Dokumentieren Sie diese Zahlen in einer Tabelle. Warten Sie nach der Implementierung jeder Optimierung mindestens 7 Tage, um genügend RUM-Daten zu sammeln, bevor Sie die Ergebnisse vergleichen. Ein guter Ansatz besteht darin, einen TTFB-Teilbereich nach dem anderen in Angriff zu nehmen, zu messen und dann zum nächsten überzugehen.

Schritt 3: Identifizieren Sie Time to First Byte-Probleme

Obwohl der Chrome User Experience Report (CrUX) von Google wertvolle Felddaten liefert, bietet er keine spezifischen Details zu den Ursachen einer hohen TTFB. Um die TTFB effektiv zu verbessern, müssen wir auf einer detaillierteren Ebene genau wissen, was vor sich geht. An diesem Punkt ist es sinnvoll, zwischen allgemein fehlschlagender TTFB und unter bestimmten Bedingungen fehlschlagender TTFB zu unterscheiden (obwohl es in der Realität immer eine Mischung geben wird).

3.1 TTFB schlägt allgemein fehl

1. Überprüfen Sie auf allgemein schlechte "Request-Zeiten": Schlechte Request-Zeiten bedeuten, dass das "Problem" bei der Zeit liegt, die der Server zur Generierung der Seite benötigt. Dies ist die häufigste Ursache für schlechte TTFB-Werte.
2. Überprüfen Sie auf andere schlechte TTFB-Teilbereiche: Die TTFB ist nicht nur eine einzelne Metrik, sondern kann in mehrere Teile zerlegt werden, die jeweils ihr eigenes Optimierungspotenzial haben. Wenn die Waiting Duration, Cache Duration, DNS Lookup Duration oder die Connection Duration langsam sind, müssten Sie wahrscheinlich Ihre Servereinstellungen anpassen oder nach qualitativ hochwertigerem Hosting suchen.

3.2 TTFB schlägt unter bestimmten Bedingungen fehl

1. Ländersegmentierung: Das Verständnis der geografischen Verteilung von hoher TTFB ist wichtig, insbesondere für Websites mit einem globalen Publikum. Wenn Sie Ihre Seiten von nur einem Server in nur einem Land bereitstellen (ohne CDN-Edge-Caching), wird die physische Entfernung zwischen dem Standort des Benutzers und dem Server, auf dem die Website gehostet wird, alle möglichen Verzögerungen verursachen und die TTFB beeinflussen. Erwägen Sie die Konfiguration von Cloudflare oder einem anderen CDN, um Ihre Inhalte weltweit näher an die Benutzer zu bringen.
   
2. Cache-Segmentierung: Caching kann die TTFB reduzieren, indem die serverseitige Generierung des HTML übersprungen wird. Leider ist es häufig der Fall, dass Caching aus vielen Gründen deaktiviert oder umgangen wird. Beispielsweise kann Caching für angemeldete Benutzer, Warenkorbseiten, Seiten mit Query-Strings (z. B. von Google Ads), Suchergebnisseiten und Checkout-Seiten deaktiviert sein. Wenn Ihre Website (Edge-)Caching verwendet, nutzen Sie RUM-Tracking, um die Cache-Trefferrate (Hit Ratio) zu überprüfen.
   
3. Seiten-(Cluster-)Segmentierung: Der Unterschied in der Time to First Byte-Leistung (oder das Fehlen eines Unterschieds) zwischen Seiten oder Seitentypen ist eine weitere Sache, die wir bestimmen müssen. Zu wissen, welche Seiten die TTFB-Metrik nicht bestehen, liefert wertvolle Erkenntnisse darüber, wie die Time to First Byte verbessert werden kann.
   
4. Redirect-Segmentierung: Weiterleitungszeiten werden direkt zur TTFB addiert. Jede Weiterleitung fügt zusätzliche Zeit hinzu, bevor der Webserver mit dem Laden der Seite beginnen kann. Das Messen und Eliminieren unnötiger Weiterleitungen kann helfen, die TTFB zu verbessern. Für einen tieferen Einblick in die Redirect-Optimierung lesen Sie unseren Leitfaden zum Waiting Duration-Teilbereich der TTFB.
   
5. Andere Segmentierung: Während die Segmentierung nach den oben genannten Variablen die üblichen Verdächtigen abdeckt, ist jede Website einzigartig und hat ihre eigenen Herausforderungen. Glücklicherweise ist RUM-Tracking darauf ausgelegt, die Segmentierung nach vielen weiteren Variablen wie Geräte-RAM, Netzwerkgeschwindigkeit, Gerätetyp, Betriebssystem, benutzerdefinierten Variablen und vielem mehr zu ermöglichen.

Schritt 4: Probleme genauer untersuchen und beheben

Die Teilbereiche der Time to First Byte (TTFB) sind:

• Waiting + Redirect (oder Waiting Duration)
• Worker + Cache (oder Cache Duration)
• DNS (oder DNS Duration)
• Connection (oder Connection Duration)
• Request (oder Request Duration)

Schritt 5: Quick-Fix-Checkliste für häufige TTFB-Probleme

Basierend auf dem Teilbereich, der am meisten zu Ihrer TTFB beiträgt, finden Sie hier eine Kurzreferenz für die häufigsten Korrekturen:

Messen der TTFB mit JavaScript

Sie können die gesamte TTFB und ihre Teilbereiche mithilfe der Navigation Timing API direkt im Browser messen. Das folgende Snippet berechnet die TTFB und protokolliert jeden Teilbereich:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const activationStart = nav.activationStart || 0;

  const ttfb = nav.responseStart - activationStart;
  const waitingDuration = (nav.workerStart || nav.fetchStart) - activationStart;
  const cacheDuration = nav.domainLookupStart - (nav.workerStart || nav.fetchStart);
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;
  const connectionDuration = nav.connectEnd - nav.connectStart;
  const requestDuration = nav.responseStart - nav.requestStart;

  console.log('TTFB:', ttfb.toFixed(0), 'ms');
  console.log('  Waiting:', waitingDuration.toFixed(0), 'ms');
  console.log('  Cache:', cacheDuration.toFixed(0), 'ms');
  console.log('  DNS:', dnsDuration.toFixed(0), 'ms');
  console.log('  Connection:', connectionDuration.toFixed(0), 'ms');
  console.log('  Request:', requestDuration.toFixed(0), 'ms');
}).observe({
  type: 'navigation',
  buffered: true
});

Dieser Code liefert dieselbe Aufschlüsselung, die Tools wie CoreDash im TTFB-Attributions-Panel anzeigen. Das Ausführen dieses Snippets in der Browserkonsole liefert Ihnen sofortige Werte für einen einzelnen Seitenaufruf, während RUM-Tools diese Daten über Tausende von echten Benutzern hinweg sammeln, um zuverlässige Werte für das 75. Perzentil zu generieren.

Weiterführende Literatur: Optimierungsleitfäden

Verwandte Leitfäden:

• 103 Early Hints: Senden Sie Ressourcenhinweise, bevor die vollständige Antwort bereit ist, sodass der Browser mit dem Laden kritischer Ressourcen beginnen kann, während der Server noch verarbeitet.
• Cloudflare für Leistung konfigurieren: Richten Sie das CDN, Caching und die Edge-Funktionen von Cloudflare ein, um die TTFB für ein globales Publikum zu reduzieren.

TTFB-Teilbereiche: Vollständige Leitfäden

Jeder Teilbereich der Time to First Byte hat seine eigenen Optimierungsstrategien. Beginnen Sie mit dem Teilbereich, den Ihre RUM-Daten als Engpass identifizieren:

• Waiting Duration: Weiterleitungen, Browser-Warteschlangen und HSTS-Optimierung.
• Cache Duration: Service-Worker-Leistung, Browser-Cache und bfcache.
• DNS Duration: Auswahl des DNS-Anbieters, TTL-Konfiguration und dns-prefetch.
• Connection Duration: TCP-Handshake, TLS-Optimierung, HTTP/3 und preconnect.
• Request Duration: Serververarbeitungszeit, Datenbankabfragen und Backend-Optimierung.