Zeit bis zum ersten Byte optimieren

Informationen zum Optimieren des Messwerts „Time to First Byte“.

Jeremy Wagner

Barry Pollard

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

Ihr Server sollte so schnell auf Navigationsanfragen reagieren, dass beim 75. Perzentil der FCP innerhalb des Grenzwerts „gut“ liegt. Als grober Richtwert sollten die meisten Websites eine TTFB von maximal 0, 8 Sekunden anstreben.

TTFB messen

Bevor Sie die TTFB optimieren können, müssen Sie ermitteln, welche Auswirkungen das auf die Nutzer Ihrer Website hat. Bei der Beobachtung von TTFB, die von Weiterleitungen beeinflusst wird, sollten Sie sich auf Felddaten stützen. Bei laborbasierten Tools wird hingegen häufig die finale URL verwendet, sodass diese zusätzliche Verzögerung nicht gegeben ist.

Mit PageSpeed Insights erhalten Sie ganz einfach Feld- und Laborinformationen für öffentliche Websites, die im Bericht zur Nutzererfahrung in Chrome verfügbar sind.

TTFB für echte Nutzer wird im Abschnitt Entdecken, was Ihre echten Nutzer erleben angezeigt:

Ein Teil der TTFB wird in der Prüfung der Serverantwortzeit angezeigt:

Weitere Möglichkeiten zum Messen von TTFB im Fachgebiet und im Labor finden Sie auf der Seite mit den TTFB-Messwerten.

Hohe TTFB mit Server-Timing verstehen

Mit dem Server-Timing-Antwortheader können Sie im Anwendungs-Back-End verschiedene Back-End-Prozesse messen, die zu hoher Latenz beitragen könnten. Die Struktur des Header-Werts ist flexibel und akzeptiert zumindest einen von Ihnen definierten Alias. Optionale Werte umfassen einen Wert für die Dauer (über dur) sowie eine optionale, visuell lesbare Beschreibung (über desc).

Mit Serving-Timing können viele Back-End-Prozesse für Anwendungen gemessen werden. Es gibt jedoch einige, auf die Sie besonders achten sollten:

• Datenbankabfragen
• Serverseitige Renderingzeit, falls zutreffend
• Laufwerkssuchen
• Edge-Server-Cache-Treffer/-Fehler (bei Verwendung eines CDN)

Alle Teile eines Server-Timing-Eintrags sind durch einen Doppelpunkt getrennt und mehrere Einträge können durch ein Komma 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 mit der Sprache Ihrer Wahl des Anwendungs-Back-Ends festgelegt werden. In PHP könnten Sie den Header beispielsweise wie folgt festlegen:

<?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 - $dbReadStarTime) / 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 jede Seite, auf der ein Server-Timing-Antwortheader festgelegt ist, in das Attribut serverTiming in der Navigation Timing API eingetragen:

// 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);
});

Im Lab werden Daten aus dem Antwortheader Server-Timing in den Chrome-Entwicklertools auf dem Tab Netzwerk im Bereich „Timing“ angezeigt:

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

Sobald Sie durch Analysieren der verfügbaren Daten festgestellt haben, dass Sie eine problematische TTFB haben, können Sie mit der Behebung des Problems fortfahren.

Optimierung der TTFB

Der schwierigste Aspekt bei der Optimierung von TTFB besteht darin, dass der Frontend-Stack des Web immer aus HTML, CSS und JavaScript besteht, die Backend-Stacks jedoch erheblich variieren können. Es gibt zahlreiche Backend-Stacks und Datenbankprodukte, die jeweils ihre eigenen Optimierungstechniken haben. Daher konzentrieren wir uns in diesem Leitfaden nicht nur auf Stack-spezifische Anleitungen, sondern auf die Aspekte, die für die meisten Architekturen gelten.

Plattformspezifische Anleitung

Die Plattform, die Sie für Ihre Website verwenden, kann sich stark auf die TTFB auswirken. Die Leistung von WordPress hängt beispielsweise von der Anzahl und Qualität der Plug-ins oder den verwendeten Themes ab. Andere Plattformen sind von der Anpassung ähnlich betroffen. In der Dokumentation zu Ihrer Plattform finden Sie anbieterspezifische Tipps, die die allgemeineren Tipps zur Leistungsoptimierung in diesem Beitrag ergänzen. Die Lighthouse-Prüfung zur Verringerung der Serverantwortzeiten enthält auch einige begrenzte Stack-spezifische Richtlinien.

Hosting, Hosting, Hosting

Bevor Sie überhaupt andere Optimierungsansätze erwägen, sollte das Hosting als Erstes in Betracht gezogen werden. Hier gibt es nicht viel spezifische Anweisungen, aber als Faustregel gilt: Stellen Sie sicher, dass der Host Ihrer Website in der Lage ist, den von Ihnen gesendeten Traffic zu verarbeiten.

Geteiltes Hosting ist in der Regel langsamer. Wenn Sie eine kleine private Website betreiben, die hauptsächlich statische Dateien bereitstellt, ist das wahrscheinlich in Ordnung, und einige der folgenden Optimierungstechniken helfen Ihnen, diese TTFB so weit wie möglich zu deaktivieren.

Wenn Sie jedoch eine größere Anwendung mit vielen Nutzern ausführen, die Personalisierung, Datenbankabfragen und andere intensive serverseitige Vorgänge erfordert, ist Ihre Wahl des Hostings für eine niedrigere TTFB in Ihrem Gebiet von entscheidender Bedeutung.

Bei der Auswahl eines Hostanbieters sind einige Dinge zu beachten:

• Wie viel Arbeitsspeicher ist Ihrer Anwendungsinstanz zugewiesen? Wenn Ihre Anwendung nicht genügend Speicher hat, wird sie vernichtet und Seiten so schnell wie möglich bereitgestellt.
• Hält Ihr Hostanbieter Ihren Backend-Stack auf dem neuesten Stand? Wenn neue Versionen von Back-End-Sprachen, HTTP-Implementierungen und Datenbanksoftware veröffentlicht werden, wird die Leistung dieser Software mit der Zeit verbessert. Es ist wichtig, mit einem Hostanbieter zusammenzuarbeiten, der diese Art von entscheidender Wartung priorisiert.
• Wenn Sie sehr spezifische Anwendungsanforderungen haben und Zugriff auf die niedrigste Zugriffsebene auf Ihre Serverkonfigurationsdateien haben möchten, fragen Sie, ob es sinnvoll ist, das Back-End Ihrer eigenen Anwendungsinstanz anzupassen.

Es gibt viele Hostanbieter, die sich um diese Dinge kümmern. Wenn Sie jedoch langsame TTFB-Werte auch bei dedizierten Hostanbietern beobachten, kann dies ein Zeichen dafür sein, dass Sie die Fähigkeiten Ihres aktuellen Hostanbieters möglicherweise neu bewerten müssen, damit Sie die bestmögliche Nutzererfahrung bieten können.

Content Delivery Network (CDN) verwenden

Das Thema CDN-Nutzung ist veraltet, aber aus gutem Grund: Ihr Anwendungs-Back-End könnte sehr gut optimiert sein, aber Nutzer, die sich weit von Ihrem Ursprungsserver befinden, haben möglicherweise trotzdem eine hohe TTFB.

CDNs lösen das Problem der Nutzernähe zu Ihrem Ursprungsserver, indem sie ein verteiltes Servernetzwerk nutzen, das Ressourcen auf Servern im Cache speichert, die sich physisch näher bei Ihren Nutzern befinden. Diese Server werden als Edge-Server bezeichnet.

CDN-Anbieter können auch Vorteile bieten, die über Edge-Server hinausgehen:

• CDN-Anbieter bieten in der Regel extrem schnelle DNS-Auflösungszeiten.
• Ein CDN stellt Ihre Inhalte wahrscheinlich über Edge-Server mit modernen Protokollen wie HTTP/2 oder HTTP/3 bereit.
• HTTP/3 löst mithilfe des UDP-Protokolls insbesondere das Head-of-Line-Blockierproblem in TCP, auf dem HTTP/2 basiert.
• Ein CDN stellt wahrscheinlich auch moderne Versionen von TLS bereit, wodurch die Latenz bei der TLS-Verhandlungszeit verringert wird. Insbesondere ist TLS 1.3 darauf ausgelegt, die TLS-Verhandlung so kurz wie möglich zu halten.
• Einige CDN-Anbieter stellen eine Funktion bereit, die oft als „Edge-Worker“ bezeichnet wird. Dabei wird eine API ähnlich der Service Worker API verwendet, um Anfragen abzufangen, Antworten in Edge-Caches programmatisch zu verwalten oder Antworten komplett umzuschreiben.
• CDN-Anbieter sind sehr gut darin, die Komprimierung zu optimieren. Die Komprimierung ist schwierig zu erledigen und kann in bestimmten Fällen mit dynamisch generiertem Markup, das spontan komprimiert werden muss, zu längeren Antwortzeiten führen.
• CDN-Anbieter speichern komprimierte Antworten für statische Ressourcen außerdem automatisch im Cache, was zu einer optimalen Mischung aus Komprimierungsverhältnis und Antwortzeit führt.

Die Einführung eines CDNs ist mit einem unterschiedlichen Aufwand verbunden, von trivial bis erheblich. Es sollte jedoch bei der Optimierung Ihrer TTFB höchste Priorität haben, falls auf Ihrer Website noch kein solches verwendet wird.

Nach Möglichkeit im Cache gespeicherte Inhalte verwendet

CDNs ermöglichen das Zwischenspeichern von Inhalten auf Edge-Servern, die sich physisch näher bei den Besuchern befinden, sofern die Inhalte mit den entsprechenden Cache-Control-HTTP-Headern konfiguriert sind. Dies ist zwar nicht für personalisierte Inhalte geeignet, wenn eine Fahrt bis zum Ursprung jedoch erforderlich ist, kann ein Großteil des Werts eines CDN beeinträchtigt werden.

Bei Websites, die ihre Inhalte häufig aktualisieren, kann selbst eine kurze Caching-Zeit bei stark ausgelasteten Websites zu deutlichen Leistungssteigerungen führen, da nur der erste Besucher während dieser Zeit die volle Latenz zurück zum Ursprungsserver erfährt, während alle anderen Besucher die im Cache gespeicherte Ressource vom Edge-Server wiederverwenden können. Einige CDNs ermöglichen die Cache-Entwertung bei Website-Releases. Das ermöglicht das Beste aus beiden Welten: lange Cache-Zeiten, aber bei Bedarf sofortige Aktualisierungen.

Selbst wenn das Caching richtig konfiguriert ist, kann dies durch die Verwendung eindeutiger Abfragestringparameter für Analysen ignoriert werden. Diese können trotz identischer Elemente für das CDN wie unterschiedlicher Content aussehen. Daher wird die im Cache gespeicherte Version nicht verwendet.

Auch ältere oder weniger besuchte Inhalte werden möglicherweise nicht im Cache gespeichert, was auf einigen Seiten zu höheren TTFB-Werten als auf anderen führen kann. Wenn die Caching-Zeiten verlängert werden, kann dies die Auswirkungen dieses Problems reduzieren. Beachten Sie jedoch, dass mit zunehmenden Caching-Zeiten die Wahrscheinlichkeit steigt, dass potenziell veraltete Inhalte bereitgestellt werden.

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

Mehrere Seitenweiterleitungen vermeiden

Weiterleitungen tragen häufig zu einer hohen TTFB bei. Weiterleitungen treten auf, wenn eine Navigationsanfrage für ein Dokument eine Antwort erhält, die den Browser darüber informiert, dass sich die Ressource an einem anderen Speicherort befindet. Eine Weiterleitung kann bei einer Navigationsanfrage sicherlich unerwünschte Latenz verursachen, diese kann sich jedoch noch verschlimmern, wenn diese Weiterleitung auf eine andere Ressource verweist, die zu einer anderen Weiterleitung führt usw. Dies kann sich insbesondere auf Websites auswirken, die über Anzeigen oder Newsletter hohe Besucherzahlen erhalten, da die Weiterleitung zu Analysezwecken häufig über Analysedienste erfolgt. Das Entfernen von Weiterleitungen unter deiner direkten Kontrolle kann zu einer guten TTFB beitragen.

Es gibt zwei Arten von Weiterleitungen:

• Weiterleitungen zum selben Ursprung: Die Weiterleitung erfolgt vollständig auf Ihrer Website.
• Cross-Origin-Weiterleitungen, bei denen die Weiterleitung anfänglich an einem anderen Ursprung erfolgt, z. B. über einen URL-Kürzungsdienst in sozialen Medien, bevor er auf Ihre Website gelangt.

Konzentrieren Sie sich darauf, Weiterleitungen vom selben Ursprung zu eliminieren, da Sie die direkte Kontrolle darüber haben. Dazu prüfen Sie die Links auf Ihrer Website, um festzustellen, ob sie einen 302- oder 301-Antwortcode zurückgeben. Dies liegt häufig daran, dass das https://-Schema nicht enthalten ist (Browser verwenden standardmäßig http://, woraufhin eine Weiterleitung erfolgt) oder dass abschließende Schrägstriche in der URL nicht korrekt ein- oder ausgeschlossen werden.

Ursprungsübergreifende Weiterleitungen sind schwieriger, da sie häufig außerhalb Ihrer Kontrolle liegen. Sie sollten jedoch möglichst mehrere Weiterleitungen vermeiden, indem Sie z. B. beim Teilen von Links mehrere Linkverkürzer verwenden. Achten Sie darauf, dass die für Werbetreibende oder Newsletter bereitgestellte URL die richtige finale URL ist, damit keine weiteren Weiterleitungen zu den von diesen Diensten verwendeten URLs hinzugefügt werden.

Eine weitere wichtige Quelle der Weiterleitungszeit kann von HTTP-zu-HTTPS-Weiterleitungen stammen. Eine Möglichkeit, dies zu umgehen, ist die Verwendung des Strict-Transport-Security-Headers (HSTS), der beim ersten Besuch an einem Ursprung HTTPS erzwingt und dem Browser dann anweist, bei zukünftigen Besuchen sofort über das HTTPS-Schema auf den Ursprung zuzugreifen.

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

Stream-Markup zum Browser

Browser sind für eine effiziente Verarbeitung von Markups optimiert, wenn sie gestreamt werden, d. h., die Markups werden beim Eintreffen vom Server in Blöcken verarbeitet. Dies ist bei großen Markup-Nutzlasten von entscheidender Bedeutung, da der Browser die Markup-Chunks inkrementell analysieren kann, anstatt auf das Eintreffen der gesamten Antwort zu warten, bevor das Parsen beginnen kann.

Obwohl Browser Streaming-Markup besonders gut verarbeiten, ist es wichtig, alles Mögliche zu tun, um diesen Stream am Laufen zu halten, damit die ersten Markup-Elemente so schnell wie möglich auf dem Weg sind. Wenn das Back-End Probleme aufhält, ist das ein Problem. Da es viele Backend-Stacks gibt, würde es den Rahmen dieses Leitfadens sprengen, jeden einzelnen Stack und die Probleme abzudecken, die in jedem einzelnen Stack auftreten können.

React wird beispielsweise für andere Frameworks, die Markup nach Bedarf auf dem Server rendern können, nach einem synchronen Ansatz beim serverseitigen Rendering gerendert. In neueren Versionen von React sind jedoch Servermethoden zum Streaming von Markups beim Rendern implementiert. Sie müssen also nicht darauf warten, dass eine React-Server-API-Methode die gesamte Antwort gerendert hat, bevor sie gesendet wird.

Eine andere Möglichkeit dafür zu gewährleisten, dass Markup schnell im Browser gestreamt wird, ist das statische Rendering, bei dem während der Build-Erstellung HTML-Dateien generiert werden. Da die vollständige Datei sofort verfügbar ist, können Webserver sofort mit dem Senden der Datei beginnen und die inhärente Beschaffenheit von HTTP führt zu Streaming-Markup. Dieser Ansatz eignet sich zwar nicht für jede Seite einer Website, z. B. für Seiten, die eine dynamische Antwort im Rahmen der Nutzererfahrung erfordern, aber für Seiten, für die kein Markup erforderlich ist, um auf einen bestimmten Nutzer zu zugeschnitten werden, kann es von Vorteil sein.

Service Worker verwenden

Die Service Worker API kann sowohl für die Dokumente als auch für die von ihnen geladenen Ressourcen große Auswirkungen auf die TTFB haben. Der Grund dafür ist, dass ein Service Worker als Proxy zwischen dem Browser und dem Server fungiert. Ob sich dies jedoch auf die TTFB Ihrer Website auswirkt, hängt davon ab, wie Sie Ihren Service Worker einrichten und ob diese Einrichtung Ihren Anwendungsanforderungen entspricht.

• Verwende für Assets eine Strategie vom Typ „Veraltet“, während sie noch einmal überprüft wird. Wenn sich ein Asset im Service Worker-Cache befindet – sei es ein Dokument oder eine Ressource, die für das Dokument benötigt wird –, wird diese Ressource zuerst aus dem Cache bereitgestellt. Anschließend wird das Asset im Hintergrund heruntergeladen und für zukünftige Interaktionen aus dem Cache bereitgestellt.
  • Wenn Sie Dokumentressourcen haben, die sich nicht sehr oft ändern, kann die Verwendung einer Strategie für eine überholte Neuvalidierung dazu führen, dass die TTFB einer Seite nahezu sofort angezeigt wird. Dies funktioniert jedoch nicht so gut, wenn Ihre Website dynamisch generiertes Markup sendet, z. B. Markup, das sich abhängig davon ändert, ob ein Nutzer authentifiziert ist. In solchen Fällen sollten Sie das Netzwerk immer zuerst aufrufen, damit das Dokument so aktuell wie möglich ist.
  • Wenn Ihr Dokument nicht kritische Ressourcen lädt, die sich mit einer gewissen Häufigkeit ändern, das Abrufen der veralteten Ressource jedoch die Nutzererfahrung nicht wesentlich beeinträchtigt, z. B. wenn Sie Bilder oder andere nicht kritische Ressourcen auswählen, kann die TTFB für diese Ressourcen mithilfe einer Strategie für eine veraltete Neuvalidierung stark reduziert werden.
• Verwenden Sie nach Möglichkeit eine Streaming Service Worker-Architektur. Bei dieser Service Worker-Architektur wird ein Ansatz verwendet, bei dem Teile einer Dokumentressource im Service Worker-Cache gespeichert und während der Navigationsanfrage mit Inhaltsteilen kombiniert werden. Die Verwendung dieses Service Worker-Musters führt dazu, dass die Navigation recht schnell ist, während kleinere HTML-Nutzlasten aus dem Netzwerk heruntergeladen werden. Dieses Service-Worker-Muster funktioniert zwar nicht für jede Website, aber die TTFB-Zeiten für Dokumentressourcen können für Websites, die sie verwenden können, praktisch sofort sein.
• Verwende das App-Shell-Modell für client-gerenderte Anwendungen. Dieses Modell eignet sich am besten für SPAs, bei denen die „Shell“ der Seite sofort aus dem Service Worker-Cache abgerufen werden kann und der dynamische Inhalt der Seite erst später im Seitenlebenszyklus eingefügt und gerendert wird.

103 Early Hints für Rendering-kritische Ressourcen verwenden

Unabhängig davon, wie gut Ihr Anwendungs-Back-End optimiert ist, könnte der Server dennoch eine erhebliche Menge Arbeit leisten, um eine Antwort vorzubereiten, einschließlich teurer (und dennoch notwendiger) Datenbankarbeiten, die das Eintreffen der Navigationsantwort so schnell wie möglich verzögern. Dies hat den potenziellen Effekt, dass einige nachfolgende Ressourcen, die das Rendering anregen, verzögert sein können, wie z. B. CSS- oder, in manchen Fällen, JavaScript, das das Markup auf dem Client rendert.

Der 103 Early Hints-Header ist ein Code für eine frühe Antwort, den der Server an den Browser senden kann, während das Back-End mit der Vorbereitung des Markups beschäftigt ist. Während das Markup vorbereitet wird, kann der Browser mithilfe dieses Headers darauf hingewiesen werden, dass es Ressourcen gibt, die für das Rendering der Seite wichtig sind. Bei unterstützten Browsern kann der Effekt ein schnelleres Dokument-Rendering (CSS) und eine schnellere Verfügbarkeit der Hauptseitenfunktionen (JavaScript) sein.

Fazit

Da es so viele Kombinationen von Back-End-Anwendungsstacks gibt, gibt es keinen Artikel, in dem alles zusammengefasst werden kann, was Sie tun können, um die TTFB Ihrer Website zu verringern. Dies sind jedoch einige Optionen, die Sie ausprobieren können, um die Serverleistung etwas schneller in Gang zu bringen.

Wie bei der Optimierung jeder Metrik ist der Ansatz weitgehend ähnlich: Messen Sie Ihre TTFB vor Ort, verwenden Sie Labortools, um die Ursachen aufzuschlüsseln, und wenden Sie dann nach Möglichkeit Optimierungen an. Möglicherweise ist nicht jede einzelne Technik in Ihrer Situation geeignet, aber einige werden es sein. Wie immer müssen Sie Ihre Felddaten genau im Auge behalten und bei Bedarf Anpassungen vornehmen, um die schnellstmögliche Nutzererfahrung zu gewährleisten.

Hero-Image von Taylor Vick, bezogen von Unsplash.