Core/Dash Dimensie: Aantal redirects

Dimensie: Navigatie: Aantal redirects (redir)

De redir dimensie 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 100ms RTT-verbinding voegt één redirect 100ms toe aan TTFB. Op een 200ms mobiele verbinding verdubbelt dat. Twee redirects op mobiel: 400ms aan pure wachttijd voordat de browser ook maar een enkele byte van je pagina ontvangt. Deze latentie is onzichtbaar in labtests die de uiteindelijke URL direct benaderen, maar echte gebruikers die links, bladwijzers of zoekresultaten volgen, incasseren dit bij elk bezoek.

De waarden

0 redirects

De doelstatus. De browser bereikte de uiteindelijke URL bij het eerste verzoek. Alle interne navigatie zou deze waarde moeten produceren. Als de links, sitemaps en canonical tags van je eigen site correct zijn, blijft intern verkeer op 0.

1 redirect

Gebruikelijk voor extern verkeer: HTTP naar HTTPS upgrades, www-normalisatie of URL's van 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 verwijst naar een trackingdomein, dat verwijst naar je HTTP-eindpunt, dat vervolgens verwijst naar HTTPS. Drie hops, drie round trips. Groepeer op URL om te ontdekken welke instappunten deze chains creëren, en elimineer vervolgens de tussenstappen.

Waar redirects vandaan komen

• HTTP naar HTTPS: Verouderde interne links die nog steeds naar http:// wijzen. 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 verwijzingen.
• CMS slug-wijzigingen: Oude paden die via een 301 doorverwijzen naar nieuwe paden. Prima voor externe backlinks, maar update elke interne link zodat deze direct naar de nieuwe slug wijst.
• Marketing vanity URL's: Vanity paden zoals /spring-sale die doorverwijzen naar /products/seasonal. Elke bezoeker betaalt de latentiekosten bij elke klik.
• URL-verkorters in e-mail en op socials: Links die via Bitly, trackingpixels of e-mailserviceproviders lopen voordat ze je domein bereiken. Elke service voegt een round trip toe die je niet kunt controleren, 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 op minimaal één redirect stuit. Alles boven de 15% is de moeite waard om te onderzoeken.
2. Groepeer op URL: Vind welke landingspagina's de grootste boosdoeners zijn. Marketingpagina's en oude blogposts met gewijzigde slugs voeren vaak de boventoon.
3. Splits intern vs. extern: Filter op navigatie-oorsprong. Same-origin verkeer met redirects betekent dat je eigen links onjuist zijn. Cross-origin redirects zijn lastiger op te lossen, maar minder urgent.
4. Los de bron op, niet de redirect: Optimaliseer de redirect zelf niet (snellere serverrespons). Elimineer het door de link die het veroorzaakte bij te werken.

Technische vuistregels

• 0 redirects op alle interne navigatie. Geen enkele redirect vanaf je eigen site is acceptabel wanneer je de bronlink beheert.
• Voer een audit uit na elke URL-migratie. Wanneer je slugs wijzigt of pagina's verplaatst, grep dan je codebase en CMS naar de oude paden. Redirects zijn een vangnet voor externe links, geen vervanging voor het updaten van je eigen verwijzingen.
• Reken 150ms per redirect op mobiel. Als je TTFB-doel 800ms is en gebruikers stuiten op twee redirects, ben je al 300ms kwijt voordat je server überhaupt iets doet.

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.