Erfahren Sie, wie Sie für den Messwert „Time to First Byte“ optimieren.
Time to First Byte (TTFB) ist ein grundlegender Messwert zur Leistung im Web, der jedem anderen Messwert für die Nutzererfahrung wie First Contentful Paint (FCP) und Largest Contentful Paint (LCP) vorausgeht. Das bedeutet, dass hohe TTFB-Werte die darauffolgenden Messwerte länger dauern.
Es wird empfohlen, dass Ihr Server so schnell auf Navigationsanfragen reagiert, dass beim 75. Perzentil der Nutzer ein FCP innerhalb der „guten“ Grenzwert. Als groben Anhaltspunkt 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 dies auf die Nutzer Ihrer Website auswirkt. Sie sollten sich auf Felddaten verlassen, um die TTFB aufgrund von Weiterleitungen zu beobachten. Lab-basierte Tools werden hingegen häufig anhand der finalen URL gemessen, sodass diese zusätzliche Verzögerung fehlt.
PageSpeed Insights ist eine Möglichkeit, Feld- und Lab-Informationen für öffentliche Websites abzurufen, die im Bericht zur Nutzererfahrung in Chrome verfügbar sind.
Die TTFB für echte Nutzer wird oben im Abschnitt Erfahren Sie, was Ihre echten Nutzer erleben angezeigt:
Ein Teil der TTFB wird im Audit der Serverantwortzeit angezeigt:
<ph type="x-smartling-placeholder">
Weitere Informationen zur Messung der TTFB sowohl in der Praxis als auch im Labor finden Sie auf der Seite mit den TTFB-Messwerten.
Mit Server-Timing Probleme mit hoher TTFB beheben
Der Server-Timing-Antwortheader kann in Ihrem Anwendungs-Back-End verwendet werden, um verschiedene Back-End-Prozesse zu messen, die zu einer hohen Latenz beitragen können. Die Struktur des Headerwerts ist flexibel und akzeptiert mindestens einen von Ihnen definierten Handle. Optionale Werte umfassen einen Wert für die Dauer (über dur) sowie eine optionale, für Menschen lesbare Beschreibung (über desc).
Mit Serving-Timing lassen sich viele Back-End-Prozesse von Anwendungen messen. Es gibt jedoch einige, auf die Sie möglicherweise 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 Doppelpunkte voneinander 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 Ihres Anwendungs-Back-Ends festgelegt werden. In PHP könnten Sie beispielsweise den Header so 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 - $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.
Im Feld füllt jede Seite mit einem gesetzten Server-Timing-Antwortheader die serverTiming-Eigenschaft in der Navigation Timing API aus:
// 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 Server-Timing-Antwortheader in den Chrome-Entwicklertools auf dem Tab Netzwerk im Bereich „Timings“ (Timing) angezeigt:
Antwortheader von Server-Timing, die auf dem Tab „Netzwerk“ der Chrome-Entwicklertools angezeigt werden. Hier wird mit Server-Timing gemessen, 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 du durch Analysieren der verfügbaren Daten festgestellt hast, dass es eine problematische TTFB gibt, kannst du mit der Behebung des Problems fortfahren.
Optimierungsmöglichkeiten für TTFB
Der schwierigste Aspekt bei der Optimierung der TTFB besteht darin, dass der Frontend-Stack des Webs immer HTML, CSS und JavaScript ist, der Backend-Stack jedoch erheblich variieren kann. Es gibt zahlreiche Back-End-Stacks und Datenbankprodukte, die jeweils ihre eigenen Optimierungstechniken haben. Daher konzentriert sich dieser Leitfaden auf das, was für die meisten Architekturen gilt, anstatt nur auf Stack-spezifische Anleitungen.
Plattformspezifische Anleitung
Die Plattform, die Sie für Ihre Website verwenden, kann sich erheblich auf TTFB auswirken. Die WordPress-Leistung wird beispielsweise durch die Anzahl und Qualität der Plug-ins oder die verwendeten Themes beeinflusst. Andere Plattformen sind von der Anpassung der Plattform ebenfalls betroffen. In der Dokumentation für Ihre Plattform finden Sie anbieterspezifische Hinweise als Ergänzung zu den allgemeineren Tipps zur Leistungsoptimierung in diesem Beitrag. Die Lighthouse-Prüfung zur Verkürzung der Serverantwortzeiten umfasst auch einige eingeschränkte Stack-spezifische Empfehlungen.
Hosting, Hosting, Hosting
Bevor Sie überhaupt andere Optimierungsansätze in Betracht ziehen, sollte das Hosting als Erstes in Betracht gezogen werden. An dieser Stelle können keine spezifischen Anleitungen angeboten werden, aber als Faustregel gilt: Stellen Sie als Faustregel sicher, dass der Host Ihrer Website in der Lage ist, die an sie gesendeten Zugriffe zu verarbeiten.
Gemeinsames Hosting ist in der Regel langsamer. Wenn Sie eine kleine persönliche Website betreiben, die hauptsächlich statische Dateien bereitstellt, ist das wahrscheinlich in Ordnung. Mit einigen der folgenden Optimierungstechniken können Sie die TTFB so weit wie möglich reduzieren.
Wenn Sie jedoch eine größere Anwendung mit vielen Benutzern ausführen, die Personalisierung, Datenbankabfragen und andere intensive serverseitige Vorgänge erfordert, wird Ihre Entscheidung für das Hosting entscheidend für eine niedrigere TTFB vor Ort.
Wenn Sie einen Hostanbieter auswählen, sollten Sie auf Folgendes achten:
- Wie viel Arbeitsspeicher wird Ihrer Anwendungsinstanz zugewiesen? Wenn Ihre Anwendung nicht über genügend Arbeitsspeicher verfügt, schlägt sie flüchtig und kann Seiten so schnell wie möglich bereitstellen.
- Hält Ihr Hostanbieter Ihren Backend-Stack auf dem neuesten Stand? Wenn neue Versionen der Sprachen für das Anwendungs-Back-End, 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 der wichtigen Wartung priorisiert.
- Wenn Sie sehr spezifische Anwendungsanforderungen haben und Zugriff auf der niedrigsten Ebene auf 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 selbst bei dedizierten Hostanbietern lange TTFB-Werte beobachten, kann dies ein Zeichen dafür sein, dass Sie die Fähigkeiten Ihres aktuellen Hostanbieters überdenken müssen, um die bestmögliche Nutzererfahrung bieten zu können.
Content Delivery Network (CDN) verwenden
Das Thema CDN-Nutzung ist etwas gängig, aber aus gutem Grund: Sie könnten ein sehr gut optimiertes Anwendungs-Back-End verwenden, aber Nutzer, die sich weit von Ihrem Ursprungsserver entfernt befinden, können dennoch eine hohe TTFB feststellen.
CDNs lösen das Problem der Nähe von Nutzern zu Ihrem Ursprungsserver, indem sie ein verteiltes Netzwerk von Servern verwenden, die Ressourcen auf Servern im Cache speichern, die sich physisch näher bei den Nutzern befinden. Diese Server werden als Edge-Server bezeichnet.
CDN-Anbieter können auch über Edge-Server hinaus weitere Vorteile bieten:
- CDN-Anbieter bieten normalerweise extrem schnelle DNS-Auflösungszeiten an.
- Ein CDN stellt Ihre Inhalte wahrscheinlich von Edge-Servern unter Verwendung moderner Protokolle wie HTTP/2 oder HTTP/3 bereit.
- HTTP/3 löst mithilfe des UDP-Protokolls insbesondere das Head-of-Line-Blockierungsproblem in TCP, auf das HTTP/2 angewiesen ist.
- Ein CDN stellt wahrscheinlich auch moderne Versionen von TLS bereit, was die Latenz bei der TLS-Verhandlung verringert. Besonders TLS 1.3 wurde entwickelt, um die TLS-Verhandlung so kurz wie möglich zu halten.
- Einige CDN-Anbieter bieten eine Funktion, die häufig als "Edge-Worker" bezeichnet wird. Diese Funktion verwendet eine API ähnlich der Service Worker API, um Anfragen abzufangen, Antworten in Edge-Caches programmatisch zu verwalten oder Antworten vollständig umzuschreiben.
- CDN-Anbieter sind sehr gut bei der Optimierung der Komprimierung. Die Komprimierung ist selbst schwierig und kann in bestimmten Fällen bei dynamisch generiertem Markup, das im laufenden Betrieb komprimiert werden muss, zu längeren Antwortzeiten führen.
- CDN-Anbieter speichern komprimierte Antworten für statische Ressourcen automatisch im Cache, um die beste Mischung aus Komprimierungsverhältnis und Antwortzeit zu erzielen.
Die Einführung eines CDN ist zwar mit einem unterschiedlichen Aufwand verbunden, von einfach bis beträchtlich, sollte jedoch bei der Optimierung deiner TTFB hohe Priorität haben, falls auf deiner Website noch keines verwendet wird.
Nach Möglichkeit im Cache gespeicherte Inhalte verwendet
CDNs ermöglichen es, Inhalte auf Edge-Servern im Cache zu speichern, die sich 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, aber wenn eine Reise zurück zum Ursprung erforderlich ist, kann das einen Großteil des Werts eines CDN zunichte machen.
Bei Websites, deren Inhalte häufig aktualisiert werden, kann selbst eine kurze Caching-Zeit zu einer merklichen Leistungssteigerung für ausgelastete Websites führen, da nur der erste Besucher während dieser Zeit die vollständige Latenz zum Ursprungsserver erlebt, während alle anderen Besucher die im Cache gespeicherte Ressource des Edge-Servers wiederverwenden können. Einige CDNs ermöglichen die Cache-Entwertung auf Site-Releases, wodurch das Beste aus beiden Welten erzielt wird: lange Cache-Zeiten, bei Bedarf aber sofortige Updates.
Selbst wenn das Caching richtig konfiguriert ist, kann dies ignoriert werden, da für die Analysemessung eindeutige Abfragestringparameter verwendet werden. Diese können für das CDN wie unterschiedlicher Inhalt aussehen, obwohl sie identisch sind. Daher wird die im Cache gespeicherte Version nicht verwendet.
Ältere oder weniger besuchte Inhalte werden eventuell auch nicht im Cache gespeichert, was auf einigen Seiten zu höheren TTFB-Werten als auf anderen führen kann. Eine Verlängerung der Caching-Zeiten kann die Auswirkungen verringern. Beachten Sie jedoch, dass eine längere Caching-Zeit die Chance erhöht, dass potenziell veraltete Inhalte bereitgestellt werden.
Die Auswirkungen von im Cache gespeicherten Inhalten betreffen nicht nur diejenigen, die CDNs verwenden. Die Serverinfrastruktur muss möglicherweise Inhalte aus kostspieligen Datenbanksuchen generieren, wenn zwischengespeicherte Inhalte nicht wiederverwendet werden können. Daten, auf die häufiger zugegriffen wird, oder vorab im Cache gespeicherte Seiten können eine bessere Leistung erzielen.
Mehrfache Seitenweiterleitungen vermeiden
Ein häufiger Grund 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 sich die Ressource an einem anderen Speicherort befindet. Eine Weiterleitung kann sicherlich unerwünschte Latenz bei einer Navigationsanfrage verursachen, aber sie kann sich sicher noch verstärken, wenn diese Weiterleitung auf eine andere Ressource verweist, die zu einer weiteren Weiterleitung führt – und so weiter. Dies kann insbesondere Websites betreffen, die hohe Besucherzahlen über Anzeigen oder Newsletter erhalten, da diese häufig zu Analysezwecken über Analysedienste weitergeleitet werden. Die Entfernung von Weiterleitungen unter deiner direkten Kontrolle kann zu einer guten TTFB beitragen.
Es gibt zwei Arten von Weiterleitungen:
- Weiterleitungen am selben Ursprung, bei denen die Weiterleitung vollständig auf Ihrer Website erfolgt.
- Ursprungsübergreifende Weiterleitungen, bei denen die Weiterleitung ursprünglich von einem anderen Ursprung aus erfolgt, z. B. von einem URL-Kürzungsdienst in sozialen Medien, bevor er auf Ihre Website gelangt.
Konzentrieren Sie sich darauf, Weiterleitungen am selben Ursprung zu eliminieren, da Sie darüber die direkte Kontrolle haben. Dazu müssten Sie prüfen, ob Links auf Ihrer Website zu einem 302- oder 301-Antwortcode führen. Häufig liegt dies daran, dass das Schema https:// nicht enthalten ist (Browser verwenden also standardmäßig http://, was dann weiterleitet, oder wenn nachgestellte Schrägstriche nicht korrekt in die URL aufgenommen oder ausgeschlossen wurden.
Ursprungsübergreifende Weiterleitungen sind schwieriger, da Sie oft keine Kontrolle darüber haben. Versuchen Sie aber, mehrere Weiterleitungen nach Möglichkeit zu vermeiden, z. B. durch die Verwendung mehrerer Linkverkürzer beim Teilen von Links. Achten Sie darauf, dass die URL, die Werbetreibenden oder Newslettern zur Verfügung gestellt wird, die richtige finale URL ist, damit Sie der von diesen Diensten verwendeten URL keine weitere Weiterleitung hinzufügen müssen.
Eine weitere wichtige Quelle für die Dauer der Weiterleitung können HTTP-zu-HTTPS-Weiterleitungen sein. Das lässt sich mit dem Strict-Transport-Security-Header (HSTS) umgehen. Dieser erzwingt HTTPS beim ersten Besuch eines Ursprungs und weist den Browser an, bei zukünftigen Besuchen über das HTTPS-Schema sofort auf den Ursprung zuzugreifen.
Sobald Sie eine gute HSTS-Richtlinie eingerichtet haben, können Sie den ersten Besuch eines Ursprungs beschleunigen, indem Sie Ihre Website der HSTS-Vorabladeliste hinzufügen.
<ph type="x-smartling-placeholder">Markup an den Browser streamen
Browser sind so optimiert, dass Markups beim Streamen effizient verarbeitet werden. Das bedeutet, dass Markups beim Eintreffen vom Server in Teilen verarbeitet werden. Dies ist von entscheidender Bedeutung, wenn große Markup-Nutzlasten betroffen sind, da der Browser die Markup-Blöcke inkrementell parsen kann, anstatt auf das Eintreffen der gesamten Antwort zu warten, bevor mit dem Parsing begonnen werden kann.
Obwohl Browser Streaming-Markup sehr gut verarbeiten, ist es sehr wichtig, dass ihr alles Mögliche unternehmen könnt, damit dieser Stream fließt, damit die ersten Markups so schnell wie möglich verfügbar sind. Wenn das Back-End lange dauert, ist das ein Problem. Da es zahlreiche Back-End-Stacks gibt, würde es in diesem Leitfaden sprengen, jeden einzelnen Stack und die jeweiligen Probleme zu behandeln.
React und andere Frameworks, die Markup nach Bedarf auf dem Server rendern, nutzen beispielsweise einen synchronen Ansatz für das serverseitige Rendering. In neueren Versionen von React sind jedoch Servermethoden für das Streaming von Markup während des Renderings implementiert. Sie müssen also nicht warten, bis eine React-Server-API-Methode die gesamte Antwort rendert, bevor sie gesendet wird.
<ph type="x-smartling-placeholder">Eine weitere Möglichkeit sicherzustellen, dass Markup schnell an den Browser gestreamt wird, ist das statische Rendering, das HTML-Dateien während der Build-Erstellung generiert. Wenn die vollständige Datei sofort verfügbar ist, können Webserver sofort mit dem Senden der Datei beginnen und die inhärente Natur von HTTP führt zu Streaming-Markups. Dieser Ansatz eignet sich zwar nicht für jede Seite auf jeder Website, z. B. wenn eine dynamische Antwort als Teil der Nutzererfahrung erforderlich ist, kann aber für Seiten nützlich sein, die kein Markup erfordern, die für einen bestimmten Nutzer personalisiert werden müssen.
Service Worker verwenden
Die Service Worker API kann große Auswirkungen auf die TTFB sowohl für Dokumente als auch für die von ihnen geladenen Ressourcen haben. Der Grund dafür ist, dass ein Service Worker als Proxy zwischen dem Browser und dem Server agiert. Ob sich dies jedoch auf die TTFB Ihrer Website auswirkt, hängt davon ab, wie Sie Ihren Service Worker eingerichtet haben und ob diese Einrichtung Ihren Anwendungsanforderungen entspricht.
- Verwende eine Strategie zum erneuten Validieren einer veralteten Version für Assets. Befindet sich ein Asset im Service Worker-Cache, z. B. ein Dokument oder eine Ressource, die für das Dokument erforderlich ist, wird diese Ressource zuerst von der Strategie „veraltete Neuvalidierung“ aus dem Cache bedient. Anschließend wird das Asset im Hintergrund heruntergeladen und für zukünftige Interaktionen aus dem Cache bereitgestellt.
- Wenn Sie über Dokumentressourcen verfügen, die sich nicht sehr oft ändern, kann die Verwendung einer veralteten Strategie zur Neuvalidierung während der Validierung die TTFB einer Seite nahezu sofort ermöglichen. Dies funktioniert jedoch nicht so gut, wenn Ihre Website dynamisch generiertes Markup sendet, z. B. Markups, die sich abhängig davon ändern, ob ein Nutzer authentifiziert ist. In solchen Fällen sollte das Netzwerk immer zuerst erfasst werden, 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 keine großen Auswirkungen auf die Nutzererfahrung hat – z. B. ausgewählte Bilder oder andere nicht kritische Ressourcen –, kann die TTFB für diese Ressourcen mithilfe einer veralteten Strategie stark reduziert werden.
- Verwenden Sie für vom Client gerenderte Anwendungen das App-Shell-Modell. Dieses Modell eignet sich am besten für SPAs, bei denen die „shell“ der Seite kann sofort aus dem Service Worker-Cache bereitgestellt werden und der dynamische Inhalt der Seite wird später im Lebenszyklus der Seite ausgefüllt und gerendert.
103 Early Hints für Rendering-kritische Ressourcen verwenden
Unabhängig davon, wie gut Ihr Anwendungs-Back-End optimiert ist, kann der Server noch viel Arbeit erledigen, um eine Antwort vorzubereiten. Dazu gehören auch teure (noch notwendige) Datenbankarbeiten, die das Eintreffen der Navigationsantwort so schnell wie möglich verzögern. Dies hat möglicherweise die Folge, dass einige nachfolgende Rendering-Ressourcen verzögert werden könnten, z. B. CSS- oder in einigen Fällen JavaScript-Code, der 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 Back-End mit der Vorbereitung des Markups beschäftigt ist. Dieser Header kann verwendet werden, um dem Browser einen Hinweis darauf zu geben, dass die Seite bei der Vorbereitung des Markups mit dem Herunterladen der Seite beginnen soll, dass das Rendering kritische Ressourcen enthält. Bei unterstützten Browsern kann das schnellere Dokumentrendering (CSS) und eine schnellere Verfügbarkeit der wichtigsten Seitenfunktionen (JavaScript) erreicht werden.
Fazit
Da es so viele Kombinationen von Back-End-Anwendungsstacks gibt, gibt es keinen Artikel, der alles enthalten kann, was Sie tun können, um die TTFB Ihrer Website zu senken. Mit diesen Optionen können Sie jedoch versuchen, die Serverabläufe ein wenig zu beschleunigen.
Wie bei der Optimierung aller Messwerte 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. Nicht jede Technik hier ist für Ihre Situation geeignet, einige jedoch schon. 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, bereitgestellt von Unsplash.