Core/Dash Dimension: Redirect Count
Messen Sie, auf wie viele HTTP-Redirects Nutzer stoßen, bevor sie Ihre Seite erreichen, und deren direkten Einfluss auf die TTFB.
Dimension: Navigation: Redirect Count (redir)
Die redir-Dimension zählt HTTP-Redirects vor Erreichen der finalen Seite. Die Werte sind 0, 1, 2 oder 3+. Jeder Redirect ist ein voller Netzwerk-Roundtrip, der stattfindet, bevor Ihr Server überhaupt mit der HTML-Generierung beginnt.
Bei einer Verbindung mit 100ms RTT fügt ein Redirect der TTFB 100ms hinzu. Bei einer mobilen Verbindung mit 200ms verdoppelt sich das. Zwei Redirects auf Mobilgeräten bedeuten 400ms reine Wartezeit, bevor der Browser ein einziges Byte Ihrer Seite empfängt. Diese Latenz ist in Lab-Tests unsichtbar, die die finale URL direkt aufrufen, aber echte Nutzer, die Links, Lesezeichen oder Suchergebnissen folgen, spüren sie bei jedem Besuch.

Die Werte
0 Redirects
Der Zielzustand. Der Browser hat die finale URL direkt mit dem ersten Request erreicht. Jede interne Navigation sollte diesen Wert erzeugen. Wenn Ihre eigenen Seitenlinks, Sitemaps und Canonical-Tags korrekt sind, bleibt der interne Traffic bei 0.
1 Redirect
Typisch für externen Traffic: HTTP zu HTTPS-Upgrades, www-Normalisierung oder URLs von Marketingkampagnen. Akzeptabel für eingehende Links, die Sie nicht kontrollieren. Inakzeptabel für Ihre eigenen internen Links. Wenn CoreDash bei internen Navigationen 1 Redirect anzeigt, verweisen Ihre Links auf alte oder inkonsistente URLs.
2+ Redirects
Redirect-Ketten. Eine gekürzte URL leitet auf eine Tracking-Domain weiter, welche auf Ihren HTTP-Endpunkt weiterleitet, welcher auf HTTPS weiterleitet. Drei Sprünge, drei Roundtrips. Gruppieren Sie nach URL, um herauszufinden, welche Einstiegspunkte diese Ketten erzeugen, und eliminieren Sie dann die Zwischenstationen.
Woher Redirects kommen
- HTTP zu HTTPS: Veraltete interne Links, die noch auf
http://verweisen. Aktualisieren Sie alle Links, Sitemaps und Canonical-Tags, um direkthttps://zu verwenden. - www-Normalisierung: Inkonsistenz zwischen www und non-www. Erzwingen Sie eine Variante auf DNS-Ebene und aktualisieren Sie alle Referenzen.
- CMS-Slug-Änderungen: Alte Pfade, die per 301 auf neue Pfade weiterleiten. In Ordnung für externe Backlinks, aber aktualisieren Sie jeden internen Link so, dass er direkt auf den neuen Slug zeigt.
- Marketing-Vanity-URLs: Vanity-Pfade wie
/spring-sale, die auf/products/seasonalweiterleiten. Jeder Besucher zahlt die Latenzkosten bei jedem Klick. - URL-Shortener in E-Mails und Social Media: Links, die durch Bitly, Tracking-Pixel oder E-Mail-Dienstleister geleitet werden, bevor sie Ihre Domain erreichen. Jeder Dienst fügt einen Roundtrip hinzu, den Sie nicht kontrollieren können. Sie können jedoch Ihre eigenen Redirects minimieren, damit die Gesamtzahl niedrig bleibt.
Debugging-Workflow
- Nach redir ≥ 1 filtern: Prüfen Sie, wie viel Prozent Ihres gesamten Traffics auf mindestens einen Redirect stoßen. Alles über 15% sollte untersucht werden.
- Nach URL gruppieren: Finden Sie heraus, welche Landingpages die schlimmsten Übeltäter sind. Marketingseiten und alte Blog-Posts mit geänderten Slugs dominieren hier meist.
- Intern vs. extern aufteilen: Filtern Sie nach Navigation Origin. Same-Origin-Traffic mit Redirects bedeutet, dass Ihre eigenen Links falsch sind. Cross-Origin-Redirects sind schwerer zu beheben, aber weniger dringend.
- Die Quelle beheben, nicht den Redirect: Optimieren Sie nicht den Redirect selbst (schnellere Serverantwort). Eliminieren Sie ihn, indem Sie den Link aktualisieren, der ihn verursacht hat.
Faustregeln für das Engineering
- 0 Redirects bei der gesamten internen Navigation. Kein Redirect von Ihrer eigenen Website ist akzeptabel, wenn Sie den Quelllink kontrollieren.
- Audit nach jeder URL-Migration. Wenn Sie Slugs ändern oder Seiten verschieben, durchsuchen (grep) Sie Ihre Codebase und Ihr CMS nach den alten Pfaden. Redirects sind ein Sicherheitsnetz für externe Links, kein Ersatz für die Aktualisierung Ihrer eigenen Referenzen.
- Budgetieren Sie 150ms pro Redirect auf Mobilgeräten. Wenn Ihr TTFB-Ziel bei 800ms liegt und Nutzer auf zwei Redirects stoßen, haben Sie bereits 300ms verbraucht, bevor Ihr Server überhaupt anfängt zu arbeiten.
Redirects sind der am einfachsten zu findende und zu behebende TTFB-Gewinn. Keine Codeänderungen, kein Server-Tuning, keine Asset-Optimierung. Aktualisieren Sie einfach die URL, die an den falschen Ort verweist.