Zeit bis zum ersten Byte optimieren

Informationen zum Optimieren für den Messwert „Time to First Byte“

Jeremy Wagner

Barry Pollard

Time to First Byte (TTFB) ist ein grundlegender Messwert für die Webleistung, der allen anderen relevanten Messwerten für die Nutzerfreundlichkeit vorausgeht, z. B. First Contentful Paint (FCP) und Largest Contentful Paint (LCP). Das bedeutet, dass hohe TTFB-Werte die Zeit für die nachfolgenden Messwerte verlängern.

Es wird empfohlen, dass Ihr Server auf Navigationsanfragen schnell genug reagiert, damit der 75. Perzentilwert der Nutzer einen FCP innerhalb des Grenzwerts „gut“ hat. Grob gesagt sollten die meisten Websites eine TTFB von 0, 8 Sekunden oder weniger anstreben.

TTFB messen

Bevor Sie die TTFB optimieren können, müssen Sie beobachten, wie sich diese auf die Nutzer Ihrer Website auswirkt. Sie sollten Felddaten als primäre Quelle für die Beobachtung der TTFB verwenden, da sie von Weiterleitungen beeinflusst wird. Bei gerätebasierten Tools wird häufig die finale URL gemessen, sodass diese zusätzliche Verzögerung nicht berücksichtigt wird.

PageSpeed Insights ist eine Möglichkeit, sowohl Feld- als auch Lab-Informationen für öffentliche Websites zu erhalten, die im Chrome User Experience Report verfügbar sind.

Die TTFB für echte Nutzer wird oben im Bereich So sieht die Leistung auf der Nutzerseite aus angezeigt:

Ein Teil der TTFB wird in der Analyse der Serverantwortzeit angezeigt:

Weitere Informationen zum Messen des TTFB sowohl im Feld als auch im Lab finden Sie auf der Seite zum Messwert „TTFB“.

Hohe TTFB im Feld mit Server-Timing beheben

Der Server-Timing-Antwortheader kann im Anwendungs-Backend verwendet werden, um verschiedene Back-End-Prozesse zu messen, die zu einer hohen Latenz beitragen könnten. Die Struktur des Headerwerts ist flexibel und muss mindestens einen von dir definierten Alias enthalten. Optionale Werte sind ein Wert für die Dauer (über dur) sowie eine optionale menschenlesbare Beschreibung (über desc).

Serving-Timing kann verwendet werden, um viele Anwendungs-Backend-Prozesse zu messen. Es gibt jedoch einige, auf die Sie besonders achten sollten:

• Datenbankabfragen
• Serverseitige Renderingzeit, falls zutreffend
• Laufwerksuchvorgänge
• Edge-Server-Cache-Treffer/-Fehltreffer (bei Verwendung eines CDN)

Alle Teile eines Server-Timing-Eintrags sind durch Doppelpunkte getrennt. Mehrere Einträge können durch Kommas getrennt werden:

// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

Der Header kann in der Sprache des Anwendungs-Backends festgelegt werden. In PHP könnte der Header beispielsweise so festgelegt werden:

<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);

// Perform a database query and get results...
// ...

// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);

// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

Wenn dieser Header festgelegt ist, werden Informationen angezeigt, die Sie sowohl im Lab als auch im Feld verwenden können.

In diesem Feld wird für jede Seite mit einem festgelegten Server-Timing-Antwortheader die Property serverTiming in der Navigation Timing API ausgefüllt:

// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
  // Log the server timing data:
  console.log(entry.name, entry.description, entry.duration);
});

In diesem Lab werden die Daten aus dem Server-Timing-Antwortheader im Bereich „Timings“ auf dem Tab Netzwerk in den Chrome-Entwicklertools visualisiert:

Server-Timing Antwortheader, die im Chrome-Entwicklertools auf dem Tab „Netzwerk“ dargestellt werden. Hier wird Server-Timing verwendet, um zu messen, ob eine Anfrage für eine Ressource den CDN-Cache getroffen hat und wie lange es dauert, bis die Anfrage den Edge-Server des CDN und dann den Ursprung erreicht.

Sobald Sie anhand der verfügbaren Daten festgestellt haben, dass die TTFB zu hoch ist, können Sie mit der Behebung des Problems fortfahren.

Möglichkeiten zur Optimierung der TTFB

Die größte Herausforderung bei der Optimierung des TTFB besteht darin, dass der Frontend-Stack des Webs immer aus HTML, CSS und JavaScript besteht, während sich Backend-Stacks erheblich unterscheiden können. Es gibt zahlreiche Backend-Stacks und Datenbankprodukte, die jeweils ihre eigenen Optimierungstechniken haben. Daher liegt der Schwerpunkt dieses Leitfadens auf den Aspekten, die für die meisten Architekturen gelten, und nicht nur auf stackspezifischen Empfehlungen.

Plattformspezifische Hinweise

Die Plattform, die Sie für Ihre Website verwenden, kann sich stark auf den TTFB auswirken. Die WordPress-Leistung wird beispielsweise von der Anzahl und Qualität der Plug-ins oder der verwendeten Themen beeinflusst. Andere Plattformen sind ebenfalls betroffen, wenn sie angepasst werden. In der Dokumentation Ihrer Plattform finden Sie anbieterspezifische Hinweise, die die allgemeineren Leistungstipps in diesem Beitrag ergänzen. Die Lighthouse-Analyse zur Verringerung der Serverantwortzeiten enthält auch einige eingeschränkte stackspezifische Hinweise.

Hosting, Hosting, Hosting

Bevor Sie andere Optimierungsansätze in Betracht ziehen, sollten Sie sich zuerst mit dem Hosting befassen. Hier können wir nicht viel Konkretes anbieten. Als Faustregel gilt jedoch, dass der Host Ihrer Website den Traffic verarbeiten können muss, den Sie an ihn senden.

Ein Shared-Hosting-Paket ist in der Regel langsamer. Wenn Sie eine kleine private Website betreiben, auf der hauptsächlich statische Dateien bereitgestellt werden, ist das wahrscheinlich in Ordnung. Mit einigen der folgenden Optimierungstechniken können Sie die TTFB jedoch so weit wie möglich senken.

Wenn Sie jedoch eine größere Anwendung mit vielen Nutzern ausführen, die Personalisierung, Datenbankabfragen und andere intensive serverseitige Vorgänge umfasst, ist die Wahl des Hostings entscheidend, um die TTFB vor Ort zu senken.

Bei der Auswahl eines Hostanbieters sollten Sie auf Folgendes achten:

• Wie viel Arbeitsspeicher ist Ihrer Anwendungsinstanz zugewiesen? Wenn Ihrer Anwendung nicht genügend Arbeitsspeicher zur Verfügung steht, kommt es zu einem Speichermangel und die Seiten werden nicht so schnell wie möglich bereitgestellt.
• Hält Ihr Hostinganbieter Ihren Backend-Stack auf dem neuesten Stand? Mit der Veröffentlichung neuer Versionen von Anwendungs-Backend-Sprachen, HTTP-Implementierungen und Datenbanksoftware wird die Leistung dieser Software im Laufe der Zeit verbessert. Es ist wichtig, mit einem Hostinganbieter zusammenzuarbeiten, der diese Art von wichtiger Wartung priorisiert.
• Wenn Sie sehr spezifische Anwendungsanforderungen haben und den niedrigsten Zugriff auf die Serverkonfigurationsdateien benötigen, fragen Sie, ob es sinnvoll ist, das Backend Ihrer eigenen Anwendungsinstanz anzupassen.

Es gibt viele Hostinganbieter, die sich um diese Dinge für Sie kümmern. Wenn Sie jedoch auch bei einem Anbieter für dedizierter Hosting lange TTFB-Werte feststellen, kann dies ein Zeichen dafür sein, dass Sie die Funktionen Ihres aktuellen Hostinganbieters noch einmal bewerten müssen, damit Sie die bestmögliche Nutzererfahrung bieten können.

Content Delivery Network (CDN) verwenden

Das Thema CDN-Nutzung ist ein viel diskutiertes Thema, und das aus gutem Grund: Sie können ein sehr gut optimiertes Anwendungs-Backend haben, aber Nutzer, die sich weit von Ihrem Ursprungsserver entfernt befinden, können trotzdem eine hohe TTFB vor Ort erleben.

CDNs lösen das Problem der Nutzernähe zu Ihrem Ursprungsserver, indem sie ein verteiltes Netzwerk von Servern verwenden, die Ressourcen auf Servern zwischenspeichern, die sich physisch näher an Ihren Nutzern befinden. Diese Server werden als Edge-Server bezeichnet.

CDN-Anbieter bieten möglicherweise auch Vorteile, die über Edge-Server hinausgehen:

• CDN-Anbieter bieten in der Regel extrem schnelle DNS-Auflösungszeiten.
• Ein CDN liefert Ihre Inhalte wahrscheinlich über Edge-Server mit modernen Protokollen wie HTTP/2 oder HTTP/3 aus.
• HTTP/3 löst insbesondere das Head-of-Line-Blocking-Problem in TCP (auf dem HTTP/2 basiert), indem es das UDP-Protokoll verwendet.
• Ein CDN bietet wahrscheinlich auch moderne TLS-Versionen, wodurch die Latenz bei der TLS-Aushandlung verringert wird. Insbesondere TLS 1.3 ist so konzipiert, dass die TLS-Verhandlung so kurz wie möglich ist.
• Einige CDN-Anbieter bieten eine Funktion, die oft als „Edge Worker“ bezeichnet wird. Dabei wird eine API ähnlich der Service Worker API verwendet, um Anfragen abzufangen, Antworten programmatisch in Edge-Caches zu verwalten oder Antworten vollständig umzuschreiben.
• CDN-Anbieter sind sehr gut darin, die Komprimierung zu optimieren. Die Komprimierung ist schwierig, wenn Sie sie selbst vornehmen. In bestimmten Fällen kann es bei dynamisch generiertem Markup, das „on the fly“ komprimiert werden muss, zu längeren Reaktionszeiten kommen.
• CDN-Anbieter speichern komprimierte Antworten für statische Ressourcen außerdem automatisch im Cache. So wird der beste Mix aus Komprimierungsverhältnis und Antwortzeit erzielt.

Die Einführung eines CDN ist mit unterschiedlichem Aufwand verbunden, von geringfügig bis erheblich. Die Optimierung der TTFB sollte jedoch eine hohe Priorität haben, wenn Ihre Website noch kein CDN verwendet.

Nach Möglichkeit wurden Cache-Inhalte verwendet.

Mit CDNs können Inhalte in Edge-Servern zwischengespeichert werden, die sich physisch näher an den Besuchern befinden, sofern die Inhalte mit den entsprechenden Cache-Control HTTP-Headern konfiguriert sind. Das ist zwar nicht für personalisierte Inhalte geeignet, aber wenn eine Weiterleitung bis zum Ursprung erforderlich ist, kann dies den Wert eines CDNs erheblich beeinträchtigen.

Bei Websites, deren Inhalte häufig aktualisiert werden, kann selbst eine kurze Caching-Zeit zu spürbaren Leistungssteigerungen bei stark frequentierten Websites führen, da nur der erste Besucher während dieser Zeit die volle Latenz bis zum Ursprungsserver erfährt, während alle anderen Besucher die im Edge-Server im Cache gespeicherte Ressource wiederverwenden können. Einige CDNs ermöglichen die Cache-Invalidierung bei Websiteveröffentlichungen. So können Sie das Beste aus beiden Welten nutzen: lange Cache-Zeiten und bei Bedarf sofortige Aktualisierungen.

Selbst wenn das Caching richtig konfiguriert ist, kann dies durch die Verwendung eindeutiger Abfragestringparameter für die Analysemessung ignoriert werden. Diese sehen für das CDN möglicherweise wie unterschiedliche Inhalte aus, obwohl sie identisch sind. Daher wird die im Cache gespeicherte Version nicht verwendet.

Ältere oder weniger besuchte Inhalte werden möglicherweise nicht im Cache gespeichert. Dies kann dazu führen, dass auf einigen Seiten höhere TTFB-Werte als auf anderen auftreten. Durch längere Caching-Zeiten können Sie die Auswirkungen verringern. Beachten Sie jedoch, dass mit längeren Caching-Zeiten die Wahrscheinlichkeit steigt, dass potenziell veraltete Inhalte ausgeliefert werden.

Die Auswirkungen von im Cache gespeicherten Inhalten betreffen nicht nur Nutzer von CDNs. Die Serverinfrastruktur muss möglicherweise Inhalte aus kostspieligen Datenbankabfragen generieren, wenn zwischengespeicherte Inhalte nicht wiederverwendet werden können. Bei Daten, auf die häufiger zugegriffen wird, oder bei vorab im Cache gespeicherten Seiten lässt sich oft eine bessere Leistung erzielen.

Mehrfache Seitenweiterleitungen vermeiden

Eine häufige Ursache für eine hohe TTFB sind Weiterleitungen. Weiterleitungen treten auf, wenn eine Navigationsanfrage für ein Dokument eine Antwort erhält, die den Browser darüber informiert, dass die Ressource an einem anderen Ort vorhanden ist. Eine Weiterleitung kann einer Navigationsanfrage zwar unerwünschte Latenz hinzufügen, aber es kann noch schlimmer werden, wenn diese Weiterleitung auf eine andere Ressource verweist, die zu einer weiteren Weiterleitung führt – und so weiter. Dies kann sich besonders auf Websites auswirken, die viele Besucher über Anzeigen oder Newsletter erhalten, da sie zu Analysezwecken häufig über Analysedienste weitergeleitet werden. Wenn Sie Weiterleitungen, die Sie direkt steuern können, entfernen, lässt sich die TTFB verbessern.

Es gibt zwei Arten von Weiterleitungen:

• Weiterleitungen vom selben Ursprung, bei denen die Weiterleitung vollständig auf Ihrer Website erfolgt.
• Ursprungsübergreifende Weiterleitungen, bei denen die Weiterleitung zuerst an einem anderen Ursprung erfolgt, z. B. über einen URL-Kürzungsdienst in sozialen Medien, bevor die Nutzer Ihre Website erreichen.

Konzentrieren Sie sich darauf, Weiterleitungen vom selben Ursprung zu entfernen, da Sie diese direkt steuern können. Dazu müssen Sie die Links auf Ihrer Website prüfen, um festzustellen, ob einer von ihnen zu einem Antwortcode vom Typ 302 oder 301 führt. Häufig ist das darauf zurückzuführen, dass das https://-Schema nicht enthalten ist (Browser verwenden dann standardmäßig http://, was zu einer Weiterleitung führt) oder dass abschließende Schrägstriche nicht richtig in die URL ein- oder ausgeschlossen sind.

Mehrfachweiterleitungen sind etwas schwieriger, da sie oft nicht von dir gesteuert werden können. Versuche aber, nach Möglichkeit mehrere Weiterleitungen zu vermeiden. Du kannst beispielsweise mehrere Linkkürzel verwenden, wenn du Links teilst. Achten Sie darauf, dass die für Werbetreibende oder Newsletter angegebene URL die richtige finale URL ist, damit nicht noch eine weitere Weiterleitung zu den von diesen Diensten verwendeten hinzugefügt wird.

Eine weitere wichtige Quelle für die Weiterleitungszeit können HTTP-zu-HTTPS-Weiterleitungen sein. Eine Möglichkeit, dies zu umgehen, ist die Verwendung des Strict-Transport-Security-Headers (HSTS). Damit wird beim ersten Besuch eines Ursprungs HTTPS erzwungen und der Browser angewiesen, bei zukünftigen Besuchen sofort über das HTTPS-Schema auf den Ursprung zuzugreifen.

Sobald Sie eine gute HSTS-Richtlinie haben, können Sie den ersten Besuch eines Ursprungs beschleunigen, indem Sie Ihre Website der HSTS-Vorabladeliste hinzufügen.

Markup an den Browser streamen

Browser sind für die effiziente Verarbeitung von Markup beim Streamen optimiert. Das bedeutet, dass das Markup in Teilen verarbeitet wird, sobald es vom Server ankommt. Das ist bei großen Markup-Nutzlastdaten entscheidend, da der Browser die Markup-Chunks dann schrittweise parsen kann, anstatt zu warten, bis die gesamte Antwort eingegangen ist, bevor das Parsen beginnen kann.

Obwohl Browser Streaming-Markups gut verarbeiten, ist es wichtig, alles zu tun, um den Stream aufrechtzuerhalten, damit die ersten Markup-Bits so schnell wie möglich gesendet werden. Wenn das Backend die Abläufe verzögert, ist das ein Problem. Da es viele Backend-Stacks gibt, würde es den Rahmen dieses Leitfadens sprengen, jeden einzelnen Stack und die Probleme zu behandeln, die bei jedem einzelnen auftreten können.

React und andere Frameworks, die Markup auf dem Server bei Bedarf rendern können, haben einen synchronen Ansatz für das serverseitige Rendering verwendet. In neueren Versionen von React wurden jedoch Servermethoden zum Streaming von Markup implementiert, während es gerendert wird. Sie müssen also nicht warten, bis eine React-Server-API-Methode die gesamte Antwort gerendert hat, bevor sie gesendet wird.

Eine weitere Möglichkeit, das schnelle Streamen von Markup an den Browser zu gewährleisten, ist das statische Rendering, bei dem HTML-Dateien während der Buildzeit generiert werden. Da die vollständige Datei sofort verfügbar ist, können Webserver mit dem Senden der Datei sofort beginnen. Die Natur von HTTP führt dann zu Streaming-Markup. Dieser Ansatz eignet sich zwar nicht für jede Seite auf jeder Website, z. B. für Seiten, die im Rahmen der Nutzerfreundlichkeit eine dynamische Antwort erfordern, kann aber für Seiten nützlich sein, bei denen das Markup nicht für einen bestimmten Nutzer personalisiert werden muss.

Dienstworker verwenden

Die Service Worker API kann sich erheblich auf die TTFB sowohl für Dokumente als auch für die von ihnen geladenen Ressourcen auswirken. Das liegt daran, dass ein Service Worker als Proxy zwischen dem Browser und dem Server fungiert. Ob sich dies auf die TTFB Ihrer Website auswirkt, hängt davon ab, wie Sie Ihren Service Worker einrichten und ob diese Einrichtung Ihren Anwendungsanforderungen entspricht.

• Verwenden Sie für Assets die Strategie „Stale-While-Revalidate“. Wenn sich ein Asset im Service Worker-Cache befindet, sei es ein Dokument oder eine für das Dokument erforderliche Ressource, wird es mit der Strategie „Stale-While-Revalidate“ zuerst aus dem Cache bereitgestellt. Anschließend wird es im Hintergrund heruntergeladen und für zukünftige Interaktionen aus dem Cache bereitgestellt.
  • Wenn sich Ihre Dokumentressourcen nicht sehr oft ändern, kann die TTFB einer Seite mit einer Strategie vom Typ „Stale-While-Revalidate“ nahezu sofort erfolgen. Das funktioniert jedoch nicht so gut, wenn Ihre Website dynamisch generiertes Markup sendet, z. B. Markup, das sich je nachdem ändert, ob ein Nutzer authentifiziert ist. In solchen Fällen sollten Sie immer zuerst das Netzwerk nutzen, damit das Dokument so aktuell wie möglich ist.
  • Wenn Ihr Dokument nicht kritische Ressourcen lädt, die sich mit einiger Regelmäßigkeit ändern, sich das Abrufen der veralteten Ressource aber nicht wesentlich auf die Nutzerfreundlichkeit auswirkt (z. B. ausgewählte Bilder oder andere nicht kritische Ressourcen), kann die TTFB für diese Ressourcen mithilfe einer Strategie für veraltete Ressourcen, die noch einmal validiert werden, erheblich reduziert werden.
• Verwenden Sie das App-Shell-Modell für clientseitig gerenderte Anwendungen. Dieses Modell eignet sich am besten für SPAs, bei denen die „Shell“ der Seite sofort aus dem Service-Worker-Cache bereitgestellt werden kann und die dynamischen Inhalte der Seite später im Seitenlebenszyklus eingefügt und gerendert werden.

103 Early Hints für renderkritische Ressourcen verwenden

Unabhängig davon, wie gut Ihr Anwendungs-Backend optimiert ist, kann der Server noch erhebliche Arbeit leisten müssen, um eine Antwort vorzubereiten. Dazu gehören teure (aber notwendige) Datenbankarbeiten, die die Navigationsantwort verzögern. Dies kann dazu führen, dass einige nachfolgende renderkritische Ressourcen verzögert werden, z. B. CSS oder in einigen Fällen JavaScript, das Markup auf dem Client rendert.

Der 103 Early Hints-Header ist ein früher Antwortcode, den der Server an den Browser senden kann, während das Backend das Markup vorbereitet. Mit diesem Header kann der Browser darauf hingewiesen werden, dass es renderkritische Ressourcen gibt, die die Seite während der Vorbereitung des Markups herunterladen sollte. Bei unterstützen Browsern kann das zu einem schnelleren Dokument-Rendering (CSS) und einer schnelleren Verfügbarkeit der Hauptfunktionen der Seite (JavaScript) führen.

Fazit

Da es so viele Kombinationen von Back-End-Anwendungsstacks gibt, kann kein Artikel alles zusammenfassen, was Sie tun können, um die TTFB Ihrer Website zu senken. Es gibt jedoch einige Optionen, mit denen du die Dinge auf der Serverseite ein wenig beschleunigen kannst.

Wie bei der Optimierung jedes Messwerts ist der Ansatz weitgehend ähnlich: Messen Sie die TTFB vor Ort, verwenden Sie Lab-Tools, um die Ursachen zu ermitteln, und wenden Sie dann nach Möglichkeit Optimierungen an. Nicht jede der hier genannten Techniken ist für Ihre Situation geeignet, aber einige schon. Wie immer sollten Sie Ihre Felddaten im Blick behalten und bei Bedarf Anpassungen vornehmen, um Nutzern die bestmögliche Leistung zu bieten.

Hero-Image von Taylor Vick, bereitgestellt von Unsplash