Den Unterbereich Waiting Duration des Time to First Byte reduzieren

Die Waiting Duration des Time to First Byte reduzieren

Dieser Artikel ist Teil unseres Leitfadens zum [url=\/core-web-vitals\/time-to-first-byte]Time to First Byte (TTFB)[\/url]. Die Waiting Duration ist der erste Unterbereich des TTFB und besteht hauptsächlich aus der Redirect-Zeit und dem Browser-Queuing. Eine hohe Waiting Duration wird fast immer durch unnötige Redirects verursacht, die zusätzliche Roundtrips hinzufügen, bevor der Server mit der Verarbeitung der eigentlichen Anfrage beginnen kann.

Der Time to First Byte (TTFB) kann in die folgenden Unterbereiche unterteilt werden:

• Waiting + Redirect (oder Waiting Duration)
• [url=\/core-web-vitals\/time-to-first-byte\/cacheduration]Worker + Cache (oder Cache Duration)[\/url]
• [url=\/core-web-vitals\/time-to-first-byte\/dnsduration]DNS (oder DNS Duration)[\/url]
• [url=\/core-web-vitals\/time-to-first-byte\/connectionduration]Connection (oder Connection Duration)[\/url]
• [url=\/core-web-vitals\/time-to-first-byte\/requestduration]Request (oder Request Duration)[\/url]

  Möchten Sie den Time to First Byte optimieren? Dieser Artikel behandelt den Teil "Waiting Duration" des Time to First Byte. Wenn Sie den Time to First Byte verstehen oder beheben möchten und nicht wissen, was Waiting Duration bedeutet, lesen Sie bitte [url=\/core-web-vitals\/time-to-first-byte]Was ist der Time to First Byte?[\/url] und [url=\/core-web-vitals\/time-to-first-byte\/fix-and-identify]Time to First Byte Probleme identifizieren und beheben[\/url], bevor Sie mit diesem Artikel beginnen.

  Der waitingDuration-Teil des Time to First Byte besteht aus der Zeit, in der der Browser möglicherweise andere Aufgaben ausführt, bevor er eine Verbindung zu einem Webserver aufbaut, plus etwaiger Redirect-Zeit. Wenn Real User Monitoring (RUM) Daten eine hohe waitingDuration zeigen, können Sie ziemlich sicher sein, dass die Ursache die Redirect-Zeit ist.

  
  

  Redirects können einen großen Einfluss auf den Time to First Byte (TTFB) haben, da jeder Redirect zu der Zeit addiert wird, die ein Browser benötigt, um das erste Byte an Daten von einem Server zu empfangen. Hier erfahren Sie, wie Redirects den TTFB beeinflussen:

  [include]toc.html[\/include]

  Wie erhöhen Redirects den Time to First Byte?

  Redirects sind normalerweise in der vollständigen TTFB-Messung enthalten (siehe blaues Feld). Das bedeutet, dass die Zeit, die für alle Redirects benötigt wird, in den gesamten TTFB-Score einfließt, was ihn potenziell höher erscheinen lässt als erwartet.

  Wenn eine Seite weitergeleitet wird, sind dies die üblichen Schritte:

  • Der Browser sendet eine erste Anfrage an die ursprüngliche URL.
  • Der Server verarbeitet diese Anfrage und antwortet mit einem Redirect-Statuscode (z. B. 301 oder 302).
  • Der Browser sendet dann eine neue Anfrage an die weitergeleitete URL.
  • Der Server verarbeitet diese zweite Anfrage und beginnt mit dem Senden des eigentlichen Inhalts.

    Arten von Redirects und ihre Auswirkungen

    Nicht alle Redirects sind gleich. Das Verständnis der verschiedenen Typen hilft Ihnen dabei, zu priorisieren, welche Redirects zuerst eliminiert werden sollten:

    Redirect-Typ	HTTP-Status	Anwendungsfall	TTFB-Auswirkung
    Permanenter Redirect	301	Die Seite ist dauerhaft auf eine neue URL umgezogen	Browser können dies zwischenspeichern, was die wiederholte Auswirkung reduziert
    Temporärer Redirect	302	Die Seite befindet sich vorübergehend unter einer anderen URL	Wird nicht von Browsern zwischengespeichert; jedes Mal ein vollständiger Roundtrip
    Temporärer Redirect (explizit)	307	Entspricht 302, behält aber die HTTP-Methode bei	Nicht zwischengespeichert; gleiche Auswirkung wie 302
    Permanenter Redirect (explizit)	308	Entspricht 301, behält aber die HTTP-Methode bei	Browser können dies zwischenspeichern, ähnlich wie 301 Ein einzelner Redirect fügt dem TTFB in der Regel 50 bis 300 Millisekunden hinzu, abhängig von den Netzwerkbedingungen und der Server-Antwortzeit. Wenn zwei oder drei Redirects hintereinander geschaltet sind (Chains), summieren sich diese Zeiten und können den TTFB weit über den "guten" Schwellenwert von 800 ms treiben. Erhöhte Server-Verarbeitungszeit Diese zusätzliche Verarbeitung erhöht den gesamten TTFB, da jeder Schritt Zeit benötigt, damit der Server die Anfrage bearbeiten und antworten kann. Redirect-Ketten In einigen Fällen können mehrere Redirects auftreten, bevor das endgültige Ziel erreicht wird. Dies erzeugt eine "Redirect-Kette", die den TTFB erhöht. Jeder Redirect in der Kette fügt seine eigene Verarbeitungszeit hinzu und vergrößert die Verzögerung, bevor das erste Byte des eigentlichen Inhalts empfangen wird. Ein häufiges Beispiel für eine Redirect-Kette: http:\/\/example.com -> 301 -> https:\/\/example.com -> 301 -> https:\/\/www.example.com -> 301 -> https:\/\/www.example.com\/en\/ In diesem Beispiel treten drei Redirects auf, bevor der Browser Inhalte empfängt. Der erste Redirect (HTTP zu HTTPS) kann mit HSTS eliminiert werden. Der zweite und dritte Redirect können eliminiert werden, indem interne Links so aktualisiert werden, dass sie direkt auf die endgültige URL verweisen. Netzwerklatenz Redirects sind oft mit zusätzlichen Netzwerk-Roundtrips zwischen Client und Server verbunden. Dies führt zu zusätzlicher Netzwerklatenz, insbesondere wenn die Redirects verschiedene Domains oder Server betreffen. Die physische Distanz zwischen Client und Server für jeden Redirect kann den TTFB weiter beeinflussen. JavaScript-Redirects vs. serverseitige Redirects: Nur serverseitige Redirects (die mit einem 30x-Redirect-Header arbeiten) werden zum Time to First Byte addiert. JavaScript-Redirects werden nicht zum Time to First Byte addiert, da der Server bereits eine vollständige Antwort (200) gesendet hat. Man könnte meinen, dass JavaScript-Redirects vorzuziehen sind, da sie den Time to First Byte nicht erhöhen. Leider sind JavaScript-Redirects für echte Benutzer viel langsamer und führen zu einer schlechten User Experience. Auswirkungen auf die User Experience (und SEO) Obwohl Redirects manchmal notwendig sind, kann ihre Auswirkung auf den TTFB weitreichendere Folgen haben: User Experience: Ein langsamerer TTFB aufgrund von Redirects kann das erste Rendern der Seite verzögern und Benutzer potenziell frustrieren. SEO: Obwohl der TTFB kein direkter Rankingfaktor ist, beeinflusst er andere Metriken wie den [url=\/core-web-vitals\/largest-contentful-paint]Largest Contentful Paint (LCP)[\/url], bei dem es sich um einen von Suchmaschinen berücksichtigten Core Web Vital handelt. Crawl-Budget: Suchmaschinen-Crawler folgen Redirects, was bedeutet, dass jeder Redirect zusätzliches Crawl-Budget verbraucht. Bei großen Websites kann dies die Entdeckung neuer oder aktualisierter Inhalte verlangsamen. So messen Sie durch Redirects verursachte TTFB-Probleme Um die Auswirkungen zu finden, die echte Benutzer durch Redirects erfahren, müssen Sie ein RUM-Tool wie CoreDash verwenden. Mit Real User Monitoring können Sie die Core Web Vitals sehr detailliert verfolgen. Klicken Sie in CoreDash einfach auf "Redirect Count", um Ihre Daten segmentiert nach der Anzahl der Redirects zu visualisieren. Klicken Sie dann zum Beispiel auf das Segment "1 Redirect", um die RUM-Daten nach "1 Redirect" zu filtern und alle betroffenen URLs anzuzeigen. So prüfen Sie Ihre Website auf Redirects Ein systematischer Redirect-Audit umfasst drei Schritte: Schritt 1: Crawlen Sie Ihre Website Verwenden Sie ein Crawling-Tool (wie MarketingTracer, Screaming Frog oder Sitebulb), um Ihre gesamte Website zu crawlen. Der Crawler meldet alle internen URLs, die mit einem 3xx-Statuscode antworten. Exportieren Sie die Liste und sortieren Sie sie nach der Anzahl der eingehenden internen Links, die auf jede weitergeleitete URL verweisen. Schritt 2: Redirect-Ketten identifizieren Filtern Sie die Crawl-Ergebnisse nach URLs, die zu einer anderen URL weiterleiten, die ihrerseits wiederum weiterleitet. Diese Ketten sollten zuerst behoben werden, da sie den TTFB-Malus multiplizieren. Schritt 3: Beheben und Verifizieren Aktualisieren Sie Ihre internen Links so, dass sie direkt auf die endgültige Ziel-URL verweisen. Crawlen Sie nach der Aktualisierung der Links erneut, um sicherzustellen, dass die Redirects bei der internen Navigation nicht mehr ausgelöst werden. Verwenden Sie das folgende JavaScript-Snippet, um Redirects über den Browser zu erkennen: new PerformanceObserver((entryList) => { const [nav] = entryList.getEntriesByType('navigation'); if (nav.redirectCount > 0) { console.warn('Redirect detected!', { redirectCount: nav.redirectCount, redirectTime: nav.redirectEnd - nav.redirectStart, finalUrl: nav.name }); } }).observe({ type: 'navigation', buffered: true }); So minimieren Sie die Auswirkungen von Redirects Befolgen Sie als allgemeine Regel diese 3 einfachen Schritte, um Redirect-Probleme zu vermeiden: Minimieren Sie die Verwendung von Redirects, wo immer dies möglich ist. Vermeiden Sie Redirect-Ketten, indem Sie Links so aktualisieren, dass sie direkt auf die endgültige Ziel-URL verweisen. Verwenden Sie nach Möglichkeit serverseitige Redirects anstelle von clientseitigen Redirects, da diese im Allgemeinen schneller sind. Same-Origin-Redirects. Same-Origin-Redirects stammen von Links auf Ihrer eigenen Website. Sie sollten die volle Kontrolle über diese Links haben und die Behebung dieser Links priorisieren, wenn Sie am Time to First Byte arbeiten. Die typische Methode, diese internen Redirects zu finden, besteht darin, eines der verfügbaren Tools zu verwenden, mit denen Sie Ihre gesamte Website auf Redirects prüfen können. Cross-Origin-Redirects. Cross-Origin-Redirects stammen von Links auf anderen Websites. Sie haben hierauf nur sehr wenig Kontrolle. Bei einflussreichen Links, die viel Traffic generieren, sollten Sie in Erwägung ziehen, den Webmaster der Seite zu kontaktieren, um die verlinkte URL zu aktualisieren. Redirect-Ketten. Mehrfache Redirects oder Redirect-Ketten treten auf, wenn ein einzelner Redirect nicht zum endgültigen Speicherort der Ressource führt. Diese Arten von Redirects belasten den Time to First Byte stärker und sollten um jeden Preis vermieden werden. Verwenden Sie auch hier ein Tool, um diese Arten von Redirects zu finden und zu beheben. HTTP-zu-HTTPS-Redirects und HSTS HTTP-zu-HTTPS-Redirects sind eine der häufigsten Redirect-Arten. Jeder Besucher, der Ihre Domain ohne "https:\/\/" eingibt oder einem alten HTTP-Link folgt, erlebt einen 301-Redirect. Der Strict-Transport-Security-Header (HSTS) eliminiert diesen Redirect für wiederkehrende Besucher, indem er dem Browser mitteilt, immer HTTPS zu verwenden. Um HSTS zu aktivieren, fügen Sie Ihrer Server-Antwort den folgenden Header hinzu: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Hier ist die Bedeutung der einzelnen Direktiven: max-age=31536000: Der Browser merkt sich für ein Jahr (31.536.000 Sekunden), HTTPS für diese Domain zu verwenden. includeSubDomains: Wendet die HTTPS-Anforderung auch auf alle Subdomains an. preload: Ermöglicht die Aufnahme Ihrer Domain in die im Browser integrierte HSTS-Preload-Liste, was bedeutet, dass bereits der allererste Besuch HTTPS ohne Redirect verwendet. Um Ihre Domain für die HSTS-Preload-Liste einzureichen, besuchen Sie hstspreload.org. Sobald sich Ihre Domain auf der Preload-Liste befindet, werden Browser niemals eine HTTP-Anfrage an Ihre Domain stellen, wodurch der HTTP-zu-HTTPS-Redirect für alle Besucher vollständig eliminiert wird. In Apache können Sie HSTS hinzufügen mit: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" In Nginx: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; Generell empfehlen wir: Prüfen und aktualisieren Sie regelmäßig 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 Speicherort der Seite verbleiben. Verarbeiten Sie Redirects auf Server-Ebene. Die bevorzugte Redirect-Methode ist ein 301-Redirect. Ein 301-Redirect ist ein permanenter Redirect, während ein 302-Redirect ein temporärer Redirect ist. Temporäre Redirects werden zum Beispiel in Suchmaschinen möglicherweise nicht aktualisiert. Verwenden Sie relative URLs: Wenn Sie auf Seiten Ihrer eigenen Website verlinken, verwenden Sie relative URLs anstelle von absoluten URLs. Dies hilft, unnötige Redirects zu vermeiden. 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, Duplicate Content und unnötige Redirects zu vermeiden. Weiterführende Literatur: Optimierungsleitfäden Verwandte Leitfäden: [url=\/pagespeed\/103-early-hints]103 Early Hints[\/url]: Reduzieren Sie den wahrgenommenen TTFB, indem Sie Ressourcenhinweise senden, während der Server die vollständige Antwort verarbeitet. [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]Cloudflare für Performance konfigurieren[\/url]: Optimieren Sie Ihre CDN-Konfiguration, um Redirect-Ketten zu reduzieren und den globalen TTFB zu verbessern. TTFB-Unterbereiche: Vollständige Leitfäden Die Waiting Duration ist einer von fünf Unterbereichen des TTFB. Erkunden Sie die anderen Unterbereiche, um das Gesamtbild zu verstehen: [url=\/core-web-vitals\/time-to-first-byte\/fix-and-identify]TTFB-Probleme identifizieren und beheben[\/url]: Der diagnostische Ausgangspunkt für jede TTFB-Optimierung. [url=\/core-web-vitals\/time-to-first-byte\/cacheduration]Cache Duration[\/url]: Service-Worker-Performance, Browser-Cache-Lookups und bfcache. [url=\/core-web-vitals\/time-to-first-byte\/dnsduration]DNS Duration[\/url]: Auswahl des DNS-Anbieters, TTL-Konfiguration und dns-prefetch. [url=\/core-web-vitals\/time-to-first-byte\/connectionduration]Connection Duration[\/url]: TCP-Handshake, TLS-Optimierung, HTTP\/3 und Preconnect. [url=\/core-web-vitals\/time-to-first-byte\/requestduration]Request Duration[\/url]: Server-Verarbeitungszeit, Datenbankabfragen und Backend-Optimierung. [include]sidebarcwv.html[\/include] [include]blogfooter.html[\/include]