Was ist die Time To First Byte (TTFB) und wie kann man sie verbessern

Was ist die Time to First Byte

Die Time-to-First Byte (TTFB) gibt an, wie viel Zeit in Millisekunden zwischen dem Start der Anfrage und dem Empfang der ersten Antwort (Byte) von einer Webseite vergangen ist. Die TTFB wird daher auch als Wartezeit bezeichnet. Die TTFB ist eine Möglichkeit, einige Teile der Geschwindigkeit einer Webseite zu messen. Die TTFB ist eine grundlegende Metrik, das bedeutet, dass Zeit, die zur TTFB hinzugefügt wird, auch zum Largest Contentful Paint und dem First Contentful Paint hinzugefügt wird.

Warum ist die Time to First Byte wichtig

Die Time to First Byte ist kein Core Web Vital und es ist sehr gut möglich, die Core Web Vitals zu bestehen, während man bei der TTFB-Metrik durchfällt. Das bedeutet nicht, dass die TTFB nicht wichtig ist. Die TTFB ist eine extrem wichtige Metrik zum Optimieren, und das Beheben der TTFB wird die Seitengeschwindigkeit und das Seitenerlebnis erheblich verbessern!

Die Auswirkung von TTFB für Besucher

Die Time to First Byte geht allen anderen Paint-Metriken voraus. Während der Browser auf die Time to First Byte wartet, kann der Browser nichts tun und zeigt nur einen leeren Bildschirm an! Das bedeutet, dass jede Zunahme der Time to First Byte zu zusätzlicher 'Leerer Bildschirm'-Zeit führt und jede Abnahme der Time to First Byte sich in weniger 'Leerer Bildschirm'-Zeit niederschlägt.

Um dieses 'Gefühl von sofort ladenden Seiten' zu bekommen, muss die Time to First Byte so schnell wie möglich sein!

Warum ist die TTFB kein Core Web Vital? TTFB berücksichtigt das Rendern nicht: Eine niedrige TTFB bedeutet nicht unbedingt eine gute User Experience, da sie nicht berücksichtigt, wie lange der Browser benötigt, um die Webseite zu rendern. Selbst wenn alle Bytes schnell heruntergeladen werden, kann die Webseite immer noch lange brauchen, um angezeigt zu werden, wenn der Browser viel JavaScript verarbeiten oder komplexe Layouts rendern muss.

Was ist ein guter TTFB-Score?

Es wird empfohlen, dass Ihr Server schnell genug auf Navigationsanfragen antwortet, sodass das 75. Perzentil der Benutzer einen FCP innerhalb des "gut"-Schwellenwerts erlebt. Als grobe Richtlinie sollten die meisten Websites eine TTFB von 0,8 Sekunden oder weniger anstreben.

• eine TTFB unter 800 Millisekunden gilt als gut.
• eine TTFB zwischen 800 und 1800 Millisekunden ist verbesserungswürdig
  
• eine TTFB über 1800 Millisekunden gilt als schlecht und sollte sofort verbessert werden

Die TTFB vom Antrag bis zur Antwort

Vom Browser zum Server: Die Anfrage

Die Browseranfragezeit ist die Zeit, die von dem Moment an vergeht, in dem der Browser eines Benutzers eine HTTP-Anfrage sendet, bis diese Anfrage den Server erreicht, der die Website hostet. Die TTFB dieses Teils liegt weitgehend außerhalb der direkten Kontrolle der Website und hängt stark ab von

• Der Internetgeschwindigkeit des Benutzers.
• Der Qualität ihrer Netzwerkinfrastruktur.
• Der physischen Entfernung zwischen dem Benutzer und dem Server.○

Innerhalb dieser Phase nehmen DNS-Lookup, Browser-Startzeit, Browser-Cache-Lookups und das Aushandeln der Verbindung zum Server (TCP & TSL) alle ein wenig Zeit in Anspruch.

Auf dem Server: Verarbeiten und Vorbereiten der Antwort

Sobald der Server die Anfrage erhält, tickt die Uhr, während er daran arbeitet, eine Antwort zu generieren. Dies ist die Phase, auf die sich die meisten Entwickler konzentrieren und wo  Optimierungsbemühungen die größte Wirkung haben können. Zu berücksichtigende Faktoren sind:

• Serverfunktionen: Leistungsstarke Hardware (CPU, RAM), effiziente Software (Webserver, Datenbank) und optimierte Konfigurationen spielen alle eine Rolle.
  
• Datenbankdauer: Wenn die Anfrage das Abrufen von Daten aus einer Datenbank erfordert, können langsame Abfragen ein großer Engpass sein.
• Code-Optimierung: Schlecht geschriebener serverseitiger Code (z. B. ineffiziente Skripte) kann zu langen Verarbeitungszeiten führen.
• Caching-Strategien: Effektives Caching (wie serverseitiges Caching oder die Verwendung eines Content Delivery Network - CDN) kann die Verarbeitungsbelastung für wiederholte Anfragen drastisch reduzieren.

Zurück zum Browser: Lieferung des Ersten Bytes

Nach der Verarbeitung sendet der Server die Antwort, beginnend mit dem ersten Byte, zurück an den Browser des Benutzers. 

• Ähnlich wie in der ersten Phase spielen hier auch Netzwerkbedingungen und Entfernung eine Rolle. 
• CDNs sind in dieser Phase besonders vorteilhaft, da sie Inhalte näher an den Benutzern zwischenspeichern und so die Reisezeit minimieren.
  
• Weiterleitungen werden an diesem Punkt bedient, wodurch sich der Prozess mit einer zusätzlichen Verzögerung wiederholt.

Technische Phasen der Time To First Byte

Ähnlich wie der 'Pfad von Anfrage zur Antwort' in Ihrem Browser kann die Time To First Byte von Navigationsanfragen mit der Navigation Timing API gemessen und in 5 Unterteile zerlegt werden.

1. Weiterleitungszeit: Wenn eine Ressource an einen neuen Ort verschoben wurde, wird die Weiterleitungszeit zur TTFB der Ressource hinzugefügt.
2. Worker- & Cache-Zeit: Bevor eine Ressource aus dem Internet abgerufen wird, versucht ein Browser zuerst, sie in seinem eigenen Cache oder über einen Worker (falls ein Worker eingerichtet wurde) nachzuschlagen
3. DNS-Lookup-Zeit: Als Nächstes muss ein Browser möglicherweise einen DNS-Lookup durchführen, um den Domainnamen (www.example.com) in eine IP-Adresse zu übersetzen
4. TCP-Verbindungszeit: Dann verbindet sich der Browser mit dem Server und führt einige Überprüfungen durch
5. SSL-Handshake: Dann verschlüsseln Browser und Server ihre Kommunikation
6. Serverantwort: Schließlich muss der Server das HTML senden. Möglicherweise muss er das HTML zuerst generieren.

Wie misst man die Time To First Byte TTFB

PageSpeed TIPP: Jede Ressource hat ihre eigene Time to First Byte. In diesem Kontext sprechen wir jedoch über die Time to First Byte der Haupt- seite!

Die Time to First Byte kann zwischen verschiedenen Benutzern mit unterschiedlichen Geräten und von verschiedenen Standorten aus stark schwanken. Deshalb ist das Selbstmessen der Time to First Byte von Ihrem Desktop-Computer aus wahrscheinlich keine gute Idee. Die Verwendung von Tools wie Pingdom oder GTMetrix ist aus demselben Grund nicht zuverlässig.

Der beste Weg, die Time To First Byte zu messen, besteht darin, Real User Metrics (RUM)-Daten von Ihren Besuchern zu sammeln. Sie können dies selbst mit diesem Code tun oder ein RUM-Tool wie CoreDash verwenden

Messen der TTFB mit synthetischen Tools

Messen der TTFB mit RUM-Tracking

Messen der TTFB mit CrUX-Daten

CrUX (Chrome User Experience Report) ist ein öffentlich zugänglicher Datensatz von Google, der reale Leistungsdaten für Websites enthält. Google verwendet den CrUX-Datensatz, um zu bestimmen, ob Sie die Core Web Vitals bestehen oder nicht.

Der CrUX-Datensatz kann über Tools wie PageSpeed Insights, die CrUX-API, Looker Studio oder Google BigQuery abgerufen werden. Verwenden Sie eines dieser Tools, um die TTFB für Ihre Website zu erhalten.

Messen der TTFB mit JavaScript

Um die Time to First Byte (TTFB) mit JavaScript zu messen, können Sie die Navigation Timing API verwenden.  Sie können einen PerformanceObserver erstellen, der auf einen Navigationseintrag lauscht und die Eigenschaft responseStart in der Konsole protokolliert. Die Eigenschaft responseStart repräsentiert den Zeitstempel, zu dem das erste Byte der Antwort empfangen wurde. Die web-vitals JavaScript-Bibliothek  bietet eine prägnantere Möglichkeit, die TTFB im Browser mit der Funktion onTTFB zu messen.

Der folgende Code kann verwendet werden, um die Time To First Byte (TTFB) zu messen

const formatTime = (time) => {

//round by 2 decimals, use Math.round() for integer
return Math.round(time * 100) / 100;
};

new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');

// timing start times are relative
const activationStart = pageNav.activationStart || 0;
const workerStart = Math.max(pageNav.workerStart - activationStart, activationStart);
const dnsStart = Math.max(pageNav.domainLookupStart - activationStart, workerStart);
const tcpStart = Math.max(pageNav.connectStart - activationStart, dnsStart);
const sslStart = Math.max(pageNav.secureConnectionStart - activationStart, tcpStart);
const requestStart = Math.max(pageNav.requestStart - activationStart, sslStart);
const responseStart = Math.max(pageNav.responseStart - activationStart, requestStart);

// attribution based on https://www.w3.org/TR/navigation-timing-2/#processing-model
// use associative array to log the results more readable
let attributionArray = [];
attributionArray['Redirect Time'] = { 'time in ms': formatTime(workerStart - activationStart) };
attributionArray['Worker and Cache Time'] = { 'time in ms': formatTime(dnsStart - workerStart) };
attributionArray['DNS Time'] = { 'time in ms': formatTime(tcpStart - dnsStart) };
attributionArray['TCP Time'] = { 'time in ms': formatTime(sslStart - tcpStart) };
attributionArray['SSL Time'] = { 'time in ms': formatTime(requestStart - sslStart) };
attributionArray['Request Time'] = { 'time in ms': formatTime(responseStart - requestStart) };
attributionArray['Total TTFB'] = { 'time in ms': formatTime(responseStart - activationStart) };

// log the results
console.log('%cTime to First Byte (' + formatTime(responseStart - activationStart) + 'ms)', 'color: blue; font-weight: bold;');
console.table(attributionArray);

console.log('%cOrigininal navigation entry', 'color: blue; font-weight: bold;');
console.log(pageNav);

}).observe({
type: 'navigation',
buffered: true
});

Finden Sie Engpässe mit Server Timing

Server Timings bieten eine Möglichkeit, Backend-Server-Performance-Timings an den Browser zu senden. Durch die Nutzung von Server Timings können Entwickler effektiv die serverseitigen Komponenten messen und analysieren, die zur TTFB beitragen, was hilft, Bereiche für Optimierungen zu identifizieren und die gesamte Website-Performance zu verbessern.

Der Server-Timing-Header kann Timings für mehrere Metriken enthalten, getrennt durch Kommas:

Ein kurzer Name für die Metrik (wie Datenbank und Verarbeitung)
Eine Dauer in Millisekunden (ausgedrückt als dur=123)
Eine Beschreibung (ausgedrückt als desc="Meine Beschreibung")

Server-Timing: database;dur=123, processing;dur=234

Ein Browser kann nun den Server-Timing-Header lesen. Dieser Server-Timing-Header kann an Ihr bevorzugtes RUM-Tool wie CoreDash gesendet werden

Wie beeinflusst Hosting die Time to First Byte?

Hosting beeinflusst die Time to First Byte auf mehrere Arten. Durch die Investition in besseres Hosting ist es normalerweise möglich, die Time to First Byte sofort zu verbessern, ohne etwas anderes zu ändern. Besonders beim Wechsel von Low-Budget-Shared-Hosting zu ordnungsgemäß konfigurierten und verwalteten virtuellen Servern kann sich die TTFB drastisch verbessern.

Hosting TIPP: Besseres Hosting beinhaltet schnellere Verarbeitung, bessere Netzwerkgeschwindigkeit und mehr und schnelleren Serverspeicher. Teures Hosting bedeutet nicht immer besseres Hosting! Viele Upgrades bei Shared-Hosting-Diensten bringen Ihnen nur mehr Speicherplatz, nicht mehr CPU-Leistung

Ich empfehle nicht, das Hosting zu wechseln, ohne die Ursachen von TTFB-Problemen zu kennen. Ich rate Ihnen, RUM-Tracking einzurichten & Server-Timing-Header hinzuzufügen.

Wenn Sie Ihr Hosting aktualisieren, sollten Sie im Allgemeinen nach mindestens 1 dieser 3 Verbesserungen suchen:

• Holen Sie sich mehr Ressourcen (CPU + RAM): Besonders wenn der Server zu lange braucht, um das dynamische HTML zu generieren.
• Schnelleres DNS: Viele Low-Budget-Hosting- Anbieter sind berüchtigt für ihre schlechte DNS-Leistung
  
• Bessere Konfiguration: Suchen Sie nach schnelleren SSL Ciphers, HTTP/3, Brotli-Komprimierung, Zugriff auf die Webserver-Konfiguration (um unnötige Module zu deaktivieren), um nur einige zu nennen.
  

Wie man die TTFB verbessert - Beschleunigen Sie die anfängliche Verbindung

Eine hohe Time to First Byte kann mehrere Ursachen haben. Jedoch beeinflussen DNS, TCP und SSL alle Time to First Bytes. Also fangen wir dort an. Auch wenn die Optimierung dieser 3 vielleicht nicht die größten Ergebnisse liefert, wird die Optimierung dieser jede einzelne TTFB optimieren!

Beschleunigen Sie DNS

PageSpeed TIPP: DNS, TCP & SSL sind normalerweise ein größeres Problem, wenn Sie einen billigen Host verwenden oder wenn Sie ein weltweites Publikum bedienen, ohne ein CDN zu verwenden. Verwenden Sie RUM- Tracking, um Ihre weltweite TTFB anzuzeigen und die TTFB in ihre Unterteile aufzuschlüsseln

Verwenden Sie einen schnellen DNS-Anbieter. Nicht alle DNS-Anbieter sind so schnell wie andere. Einige (kostenlose) DNS-Anbieter sind einfach langsamer als andere (kostenlose) DNS-Anbieter. CloudFlare zum Beispiel bietet Ihnen einen der schnellsten DNS-Anbieter der Welt kostenlos!

Erhöhen Sie die DNS-TTL. Eine weitere Möglichkeit besteht darin, den Time to Live (TTL)-Wert zu erhöhen. TTL ist eine Einstellung, die bestimmt, wie lange der Lookup zwischengespeichert werden kann. Je höher die TTL, desto unwahrscheinlicher ist es, dass der Browser einen weiteren DNS-Lookup durchführen muss. Es ist wichtig zu beachten, dass ISPs auch DNS zwischenspeichern.

Beschleunigen Sie TCP

Der 'TCP-Teil' der TTFB ist die anfängliche Verbindung zum Webserver. Beim Verbinden teilen sich Browser und Server Informationen darüber, wie Informationen ausgetauscht werden. Sie können TCP beschleunigen, indem Sie eine Verbindung zu einem Server herstellen, der geografisch nah an Ihrem Standort liegt, und indem Sie sicherstellen, dass der Server genügend freie Ressourcen hat. Manchmal kann der Wechsel zu einem leichtgewichtigen Server wie NGINX den TCP-Teil der TTFB beschleunigen. In vielen Fällen beschleunigt die Verwendung eines CDN die TCP-Verbindung!

Beschleunigen Sie SSL/TSL

Sobald die TCP-Verbindung hergestellt wurde, müssen Browser und Server Ihre Verbindung durch Verschlüsselung sichern. Sie können dies beschleunigen, indem Sie schnellere, neuere und leichtgewichtigere Protokolle (SSL Ciphers) verwenden und geografisch näher an Ihrem Webserver sind (da die TSL-Aushandlung einige Hin- und Her- Round-Trips in Anspruch nimmt). Die Verwendung eines CDN verbessert oft die SSL-Verbindungszeit, da sie oft sehr gut konfiguriert sind und mehrere Server auf der ganzen Welt haben. Insbesondere TLS 1.3 wurde entwickelt, um die TLS-Aushandlung so kurz wie möglich zu halten.

Wie man die TTFB verbessert - Beschleunigen Sie die Serverseite

Seiten-Caching

Die mit Abstand effizienteste Methode, um die Time to First Byte zu beschleunigen, ist die Bereitstellung des HTML aus dem Server-Cache. Es gibt mehrere Möglichkeiten, vollständiges Seiten-Caching zu implementieren. Der effektivste Weg ist dies direkt auf der Webserver-Ebene, zum Beispiel mit dem NGINX-Caching-Modul oder durch die Verwendung von Varnish als Reverse-Caching-Proxy.

Es gibt auch viele Plugins für verschiedene CMS-Systeme, die vollständige Seiten zwischenspeichern, und viele SPA-Frameworks wie NextJS haben ihre eigene Implementierung von vollständigem Seiten-Caching zusammen mit verschiedenen Invalidierungsstrategien.

Wenn Sie Ihr eigenes Caching implementieren möchten, ist die Grundidee super einfach. Wenn ein Client eine Seite anfordert, prüfen Sie, ob sie im Cache-Ordner existiert. Wenn sie nicht existiert, erstellen Sie die Seite, schreiben Sie sie in den Cache und zeigen Sie die Seite wie gewohnt an. Bei jeder nächsten Anfrage an die Seite wird die Cache-Datei existieren und Sie können die Seite direkt aus dem Cache bereitstellen.

Partielles Caching

Beim partiellen Caching besteht die Idee darin, häufig verwendete, langsame oder teure Teile der Seite oder Ressourcen (wie API-Aufrufe, Datenbankergebnisse) für einen schnellen Abruf zwischenzuspeichern. Dies beseitigt Engpässe beim Generieren einer Seite. Wenn Sie an dieser Art von Optimierungen interessiert sind (Sie sollten interessiert sein!!), suchen Sie nach diesen Konzepten: Memory Cache, Object Cache, Database Cache, Object-Relational Mapping (ORM) Cache, Content Fragment Cache und Opcode Cache.

Optimieren Sie den Anwendungscode

Manchmal kann die Seite nicht aus dem (partiellen) Cache bereitgestellt werden, weil die Cache-Datei nicht existiert, große Teile der Seiten dynamisch sind oder weil Sie auf andere Probleme stoßen. Deshalb müssen wir den Anwendungscode optimieren. Wie dies geschieht, hängt ganz von Ihrer Anwendung ab. Es basiert auf dem Umschreiben und Optimieren langsamer Teile Ihres Codes.

Optimieren Sie Datenbankabfragen

Meistens sind ineffektive Datenbankabfragen die Ursache für eine langsame Time to First Byte. Beginnen Sie mit dem Protokollieren von 'langsamen Abfragen' und 'Abfragen, die keine Indizes verwenden' auf der Festplatte. Analysieren Sie sie, fügen Sie Indizes hinzu oder bitten Sie einen Experten, ein Datenbank-Tuning durchzuführen, um diese Probleme zu beheben. Siehe https://www.mongodb.com/docs/atlas/performance-advisor/ und https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html

Reduzieren Sie interne Netzwerklatenz

Eine schlechte Praxis, auf die ich öfter stoße, als mir lieb ist, ist eine Verzögerung der Time to First Byte, verursacht durch Langsamkeit durch die Kommunikation zwischen der Webanwendung und dem Datenspeicher. Dies geschieht normalerweise nur bei großen Websites, die ihren Datenspeicher an Cloud-APIs ausgelagert haben.

Wie man die TTFB verbessert - Beschleunigen Sie die Clientseite

Clientseitiges Caching

Clientseitiges Caching bedeutet, dass der Browser des Benutzers Ressourcen speichert, auf die er bereits zugegriffen hat, wie Bilder und Skripte. Wenn der Benutzer also auf Ihre Website zurückkehrt, kann sein Browser die zwischengespeicherten Ressourcen schnell abrufen, anstatt sie erneut herunterladen zu müssen. Dies kann die Anzahl der Anfragen an den Server erheblich reduzieren, was wiederum die TTFB verringern kann.

Um clientseitiges Caching zu implementieren, können Sie den HTTP Cache-Control-Header verwenden. Dieser Header ermöglicht es Ihnen, anzugeben, wie lange der Browser eine bestimmte Ressource zwischenspeichern soll.

Sie könnten in Erwägung ziehen, das HTML der Seite vollständig auf der Clientseite zwischenzuspeichern. Dies wird die TTFB drastisch reduzieren, da wir keine Anfrage mehr benötigen. Der Nachteil ist, dass sobald sich die Seite im Cache des Browsers befindet, Updates auf der Live-Version der Seite vom Benutzer nicht gesehen werden, bis der Seiten-Cache abläuft.

Service Workers

Service Workers sind Skripte, die im Hintergrund des Browsers eines Benutzers ausgeführt werden und Netzwerkanfragen abfangen können, die vom Browser gestellt werden. Das bedeutet, dass Service Workers Ressourcen wie HTML, Bilder, Skripte und Stylesheets zwischenspeichern können, sodass, wenn der Benutzer auf Ihre Website zurückkehrt, sein Browser die zwischengespeicherten Ressourcen schnell abrufen kann, anstatt sie erneut herunterladen zu müssen.

Speculation Rules API

Die Speculation Rules API wurde entwickelt, um die Leistung für zukünftige Navigationen zu verbessern. Sobald ein Besucher auf Ihrer Seite gelandet ist, können Sie die Speculation Rules verwenden, um einen Browser anzuweisen, Seiten abzurufen (mit der Prefetch-Direktive) oder sogar zu rendern (mit der Prerender-Direktive), die der Besucher höchstwahrscheinlich besuchen wird. Die Speculation Rules API ist flexibler und konfigurierbarer als die Link-Prefetch-Methode.

Schauen Sie sich dieses Beispiel an, wo der Browser angewiesen wird, die URL in der Menüleiste für eine zukünftige Navigation vorzuladen und im Speicher zu halten, damit sie verwendet werden kann, um die nächste Navigation zu beschleunigen.

<script type="speculationrules">
{"prerender":
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

Seiten-Prefetching

Wenn Sie die Speculation Rules API wegen ihrer schlechten Browserunterstützung nicht verwenden möchten, oder Sie könnten ein kleines Skript namens quicklink verwenden. Dies wird alle Links im sichtbaren Viewport vorladen und die Time To First Byte für diese Links so gut wie eliminieren!

Der Nachteil von Quicklinks ist, dass es mehr Browserressourcen erfordert, aber im Moment wird es die Speculation Rules API übertreffen.

Wie man die TTFB verbessert - nutzen Sie ein CDN

Ein Content Delivery Network oder CDN nutzt ein verteiltes Netzwerk von Servern, um Ressourcen an Benutzer zu liefern. Diese Server befinden sich normalerweise geografisch näher an den Endbenutzern und sind super-optimiert für Geschwindigkeit.

T
TTFB mit einem CDN und Edge Caching

T
TTFB ohne ein CDN gehostet in Deutschland

Ein CDN kann helfen, 5 von 6 Teilen der Time to First Byte zu verbessern:

• Weiterleitungszeit: Die meisten CDNs können Weiterleitungen am Edge cachen oder Edge Workers verwenden, um Weiterleitungen zu handhaben, ohne sich mit dem Ursprungsserver verbinden zu müssen.
• DNS-Lookup-Zeit: Die meisten CDNs bieten extrem schnelle DNS-Server, die wahrscheinlich Ihre aktuellen DNS-Server übertreffen
  
• TCP-Verbindung & SSL-Handshake-Zeit. Die meisten CDNs sind extrem gut konfiguriert und diese Konfigurationen, zusammen mit der größeren Nähe zu den Endbenutzern, werden die Verbindungs- + Handshake- Zeit beschleunigen
  
• Serverantwort: CDNs können die Serverantwortzeit auf verschiedene Weisen beschleunigen. Die erste ist durch das Cachen der Serverantwort am Edge (Full Page Edge Caching), aber auch durch das Angebot hervorragender Komprimierung (Brotli) und der neuesten (HTTP/3) Protokolle

Wie man die TTFB verbessert - Vermeiden Sie Weiterleitungen

Weiterleitungszeit wird zur Time To First Byte hinzugefügt. Vermeiden Sie daher als Faustregel Weiterleitungen so weit wie möglich. Weiterleitungen können auftreten, wenn eine Ressource an einem Ort nicht mehr verfügbar ist, sondern an einen anderen Ort verschoben wurde. Der Server antwortet mit einem Weiterleitungs-Antwort-Header und der Browser wird diesen neuen Ort versuchen.

Same-Origin-Weiterleitungen. Same-Origin-Weiterleitungen stammen von Links auf Ihrer eigenen Website. Sie sollten die volle Kontrolle über diese Links haben und Sie sollten das Beheben dieser Links priorisieren, wenn Sie an der Time to First Byte arbeiten. Es gibt viele Tools da draußen, die Sie Ihre gesamte Website auf Weiterleitungen überprüfen lassen

Cross-Origin-Weiterleitungen. Cross-Origin-Weiterleitungen stammen von Links auf anderen Websites. Sie haben sehr wenig Kontrolle über diese.

Mehrfache Weiterleitungen. Mehrfache Weiterleitungen oder Weiterleitungsketten treten auf, wenn eine einzelne Weiterleitung nicht zum endgültigen Ort der Ressource weiterleitet. Diese Arten von Weiterleitungen belasten die Time to First Byte stärker und sollten um jeden Preis vermieden werden. Verwenden Sie erneut ein Tool , um diese Arten von Weiterleitungen zu finden und sie zu beheben!

HTTP-zu-HTTPS-Weiterleitungen. Ein Weg, dies zu umgehen, ist die Verwendung des Strict-Transport-Security Headers (HSTS), der HTTPS beim ersten Besuch eines Ursprungs erzwingt und dann dem Browser mitteilt, den Ursprung bei zukünftigen Besuchen sofort über das HTTPS-Schema aufzurufen.

Wenn ein Benutzer eine Webseite anfordert, kann der Server mit einer Weiterleitung zu einer anderen Seite antworten. Diese Weiterleitung kann zusätzliche Zeit zur TTFB hinzufügen, da der Browser eine zusätzliche Anfrage an die neue Seite stellen muss.

Es gibt mehrere Möglichkeiten, Weiterleitungen zu vermeiden oder die Auswirkung von Weiterleitungen zu minimieren:

1. Aktualisieren Sie Ihre internen Links! Wann immer Sie den Ort einer Seite ändern, aktualisieren Sie Ihre internen Links zu dieser Seite, um sicherzustellen, dass keine Verweise auf den früheren Seitenort verbleiben.
   
2. Behandeln Sie Weiterleitungen auf Serverebene.
   
3. Verwenden Sie relative URLs: Wenn Sie auf Seiten auf Ihrer eigenen Website verlinken, verwenden Sie relative URLs anstelle von absoluten URLs. Dies hilft, unnötige Weiterleitungen zu vermeiden.
   
4. Verwenden Sie kanonische URLs: Wenn Sie mehrere Seiten mit ähnlichem Inhalt haben, verwenden Sie eine kanonische URL, um die bevorzugte Version der Seite anzugeben. Dies hilft, doppelten Inhalt und unnötige Weiterleitungen zu vermeiden.
   
5. Verwenden Sie 301-Weiterleitungen: Wenn Sie eine Weiterleitung verwenden müssen, verwenden Sie eine 301-Weiterleitung anstelle einer 302-Weiterleitung. Eine 301- Weiterleitung ist eine permanente Weiterleitung, während eine 302-Weiterleitung eine temporäre Weiterleitung ist. Die Verwendung einer 301-Weiterleitung hilft, unnötige Weiterleitungen zu vermeiden.