Core/Dash Dimension: Antal redirects

Dimension: Navigation: Antal redirects (redir)

Dimensionen redir tæller HTTP-redirects før den endelige side nås. Værdierne er 0, 1, 2 eller 3+. Hvert redirect er et fuldt netværks-round trip, der sker, før din server overhovedet begynder at generere HTML.

På en forbindelse med 100 ms RTT tilføjer ét redirect 100 ms til TTFB. På en 200 ms mobilforbindelse fordobles det. To redirects på mobil: 400 ms ren ventetid, før browseren modtager en eneste byte af din side. Denne latens er usynlig i laboratorietests, der rammer den endelige URL direkte, men virkelige brugere, der følger links, bogmærker eller søgeresultater, absorberer den ved hvert besøg.

Værdierne

0 redirects

Måltilstanden. Browseren ramte den endelige URL ved første anmodning. Al intern navigation bør producere denne værdi. Hvis dit eget websides links, sitemaps og canonical tags er korrekte, forbliver intern trafik på 0.

1 redirect

Almindeligt for ekstern trafik: HTTP til HTTPS-opgraderinger, www-normalisering eller URL'er til marketingkampagner. Acceptabelt for indgående links, du ikke kontrollerer. Ikke acceptabelt for dine egne interne links. Hvis CoreDash viser 1 redirect på interne navigationer, peger dine links på gamle eller inkonsekvente URL'er.

2+ redirects

Redirect-kæder. En forkortet URL omdirigerer til et tracking-domæne, som omdirigerer til dit HTTP-endpoint, som omdirigerer til HTTPS. Tre hop, tre round trips. Gruppér efter URL for at finde ud af, hvilke indgangsvinkler der skaber disse kæder, og fjern derefter mellemmændene.

Hvor redirects kommer fra

• HTTP til HTTPS: Forældede interne links, der stadig peger på http://. Opdater alle links, sitemaps og canonical tags til at bruge https:// direkte.
• www-normalisering: Inkonsekvens mellem www og non-www. Håndhæv én version på DNS-niveau, og opdater alle referencer.
• CMS slug-ændringer: Gamle stier, der omdirigerer til nye stier via 301. Fint for eksterne backlinks, men opdater ethvert internt link, så det peger direkte på det nye slug.
• Vanity URL'er til marketing: Vanity-stier som /spring-sale, der omdirigerer til /products/seasonal. Hver eneste besøgende betaler latensomkostningen ved hvert klik.
• URL-forkortere i e-mail og sociale medier: Links, der passerer gennem Bitly, tracking-pixels eller e-mail-tjenesteudbydere, før de når dit domæne. Hver tjeneste tilføjer et round trip, du ikke kan kontrollere, men du kan minimere dine egne redirects, så totalen forbliver lav.

Fejlfindings-workflow

1. Filtrér for redir ≥ 1: Se, hvor stor en procentdel af din samlede trafik der rammer mindst ét redirect. Alt over 15 % er værd at undersøge.
2. Gruppér efter URL: Find ud af, hvilke landingssider der er de værste syndere. Marketingsider og gamle blogindlæg med ændrede slugs har en tendens til at dominere.
3. Opdel intern vs ekstern: Filtrér efter navigation origin. Same-origin-trafik med redirects betyder, at dine egne links er forkerte. Cross-origin-redirects er sværere at rette, men mindre presserende.
4. Ret kilden, ikke omdirigeringen: Optimér ikke selve omdirigeringen (hurtigere serverrespons). Eliminér den ved at opdatere linket, der forårsagede den.

Tommelfingerregler for udviklere

• 0 redirects på al intern navigation. Intet redirect fra dit eget website er acceptabelt, når du kontrollerer kildelinket.
• Udfør audit efter hver URL-migrering. Når du ændrer slugs eller flytter sider, så kør grep i din codebase og dit CMS for at finde de gamle stier. Redirects er et sikkerhedsnet for eksterne links, ikke en erstatning for at opdatere dine egne referencer.
• Budgetmér med 150 ms pr. redirect på mobil. Hvis dit TTFB-mål er 800 ms, og brugerne rammer to redirects, har du allerede brugt 300 ms, før din server udfører noget arbejde.

Redirects er den nemmeste TTFB-gevinst at finde og fikse. Ingen kodeændringer, ingen server-tuning, ingen asset-optimering. Du skal blot opdatere den URL, der peger det forkerte sted hen.