Core/Dash Dimensie: Redirect Count

Dimensie: Navigatie: Redirect Count (redir)

De dimensie redir telt HTTP-redirects voordat de uiteindelijke pagina wordt bereikt. Waarden zijn 0, 1, 2 of 3+. Elke redirect is een volledige netwerk round-trip die plaatsvindt voordat je server überhaupt begint met het genereren van HTML.

Op een verbinding met 100ms RTT voegt één redirect 100ms toe aan TTFB. Op een mobiele verbinding van 200ms verdubbelt dat. Twee redirects op mobiel: 400ms puur wachten voordat de browser een enkele byte van je pagina ontvangt. Deze latency is onzichtbaar in labtests die de uiteindelijke URL direct bezoeken, maar echte gebruikers die links, bladwijzers of zoekresultaten volgen incasseren dit bij elk bezoek.

De waarden

0 redirects

De doelsituatie. De browser bereikte de uiteindelijke URL bij de eerste request. Alle interne navigatie zou deze waarde moeten opleveren. Als je eigen sitelinks, sitemaps en canonical tags correct zijn, blijft intern verkeer op 0.

1 redirect

Gebruikelijk voor extern verkeer: HTTP naar HTTPS upgrades, www-normalisatie of URL's voor marketingcampagnes. Acceptabel voor inkomende links die je niet beheert. Niet acceptabel voor je eigen interne links. Als CoreDash 1 redirect toont bij interne navigaties, wijzen je links naar oude of inconsistente URL's.

2+ redirects

Redirect chains. Een verkorte URL redirect naar een trackingdomein, dat redirect naar je HTTP-endpoint, dat vervolgens redirect naar HTTPS. Drie hops, drie round-trips. Groepeer op URL om te ontdekken welke instappunten deze ketens creëren en elimineer vervolgens de tussenliggende stappen.

Waar redirects vandaan komen

• HTTP naar HTTPS: Verouderde interne links die nog steeds wijzen naar http://. Update alle links, sitemaps en canonical tags om direct https:// te gebruiken.
• www-normalisatie: Inconsistentie tussen www en non-www. Dwing er één af op DNS-niveau en update alle referenties.
• Wijzigingen in CMS-slugs: Oude paden die via 301 redirecten naar nieuwe paden. Prima voor externe backlinks, maar update elke interne link zodat deze direct naar de nieuwe slug wijst.
• Marketing vanity URL's: Korte, aantrekkelijke paden (vanity URL's) zoals /spring-sale die redirecten naar /products/seasonal. Elke bezoeker betaalt de latency-kosten bij elke klik.
• URL-shorteners in e-mail en social media: Links die via Bitly, trackingpixels of e-mailproviders lopen voordat ze je domein bereiken. Elke dienst voegt een round-trip toe waar je geen controle over hebt, maar je kunt je eigen redirects minimaliseren zodat het totaal laag blijft.

Debugging workflow

1. Filter op redir ≥ 1: Bekijk welk percentage van je totale verkeer minimaal één redirect raakt. Alles boven de 15% is het onderzoeken waard.
2. Groepeer op URL: Ontdek welke landingspagina's de grootste boosdoeners zijn. Marketingpagina's en oude blogposts met gewijzigde slugs domineren hier vaak.
3. Splits intern vs extern: Filter op navigation origin. Verkeer met dezelfde origin en redirects betekent dat je eigen links fout zijn. Cross-origin redirects zijn lastiger op te lossen maar minder urgent.
4. Repareer de bron, niet de redirect: Optimaliseer niet de redirect zelf (snellere serverrespons). Elimineer deze door de link die het veroorzaakte bij te werken.

Vuistregels voor engineers

• 0 redirects op alle interne navigatie. Geen enkele redirect vanaf je eigen site is acceptabel wanneer je de bronlink beheert.
• Audit na elke URL-migratie. Wanneer je slugs wijzigt of pagina's verplaatst, doorzoek (grep) je codebase en CMS op de oude paden. Redirects zijn een vangnet voor externe links, geen vervanging voor het bijwerken van je eigen referenties.
• Reken 150ms per redirect op mobiel. Als je TTFB-doel 800ms is en gebruikers twee redirects tegenkomen, heb je al 300ms verspild voordat je server enig werk verricht.

Redirects zijn de makkelijkste TTFB-winst om te vinden en op te lossen. Geen codewijzigingen, geen server-tuning, geen asset-optimalisatie. Update simpelweg de URL die naar de verkeerde plek wijst.