CoreDash-dimensjon: Antall redirects

Dimensjon: Navigasjon: Antall redirects (redir)

Dimensjonen redir teller HTTP-redirects før man når den endelige siden. Verdiene er 0, 1, 2 eller 3+. Hver redirect er en full nettverksrundtur som skjer før serveren din i det hele tatt begynner å generere HTML.

På en 100ms RTT-tilkobling legger én redirect til 100ms i TTFB. På en 200ms mobiltilkobling dobles dette. To redirects på mobil: 400ms med ren venting før nettleseren mottar en eneste byte av siden din. Denne forsinkelsen er usynlig i lab-tester som treffer den endelige URL-en direkte, men ekte brukere som følger lenker, bokmerker eller søkeresultater, absorberer dette ved hvert besøk.

Verdiene

0 redirects

Måltilstanden. Nettleseren traff den endelige URL-en på første forespørsel. All intern navigasjon bør produsere denne verdien. Hvis nettstedets egne lenker, sitemaps og canonical-tags er korrekte, forblir intern trafikk på 0.

1 redirect

Vanlig for ekstern trafikk: oppgraderinger fra HTTP til HTTPS, www-normalisering, eller URL-er for markedsføringskampanjer. Akseptabelt for inngående lenker du ikke kontrollerer. Ikke akseptabelt for dine egne interne lenker. Hvis CoreDash viser 1 redirect på intern navigasjon, peker lenkene dine til gamle eller inkonsekvente URL-er.

2+ redirects

Redirect-kjeder. En forkortet URL viderekobler til et sporingsdomene, som viderekobler til ditt HTTP-endepunkt, som viderekobler til HTTPS. Tre hopp, tre rundturer. Grupper etter URL for å finne ut hvilke inngangspunkter som skaper disse kjedene, og eliminer deretter mellomleddene.

Hvor redirects kommer fra

• HTTP til HTTPS: Utdaterte interne lenker som fortsatt peker til http://. Oppdater alle lenker, sitemaps og canonical-tags for å bruke https:// direkte.
• www-normalisering: Inkonsekvens mellom www og non-www. Håndhev ett alternativ på DNS-nivå og oppdater alle referanser.
• Endringer i CMS-slug: Gamle stier som viderekobler til nye stier via 301. Greit for eksterne tilbakekoblinger, men oppdater alle interne lenker til å peke direkte på den nye slug-en.
• Forfengelige URL-er i markedsføring: Tilpassede stier som /spring-sale som viderekobler til /products/seasonal. Hver besøkende betaler forsinkelseskostnaden ved hvert klikk.
• URL-forkortere i e-post og sosiale medier: Lenker som passerer gjennom Bitly, sporingspiksler eller e-posttjenester før de når domenet ditt. Hver tjeneste legger til en rundtur du ikke kan kontrollere, men du kan minimere dine egne redirects slik at totalen forblir lav.

Arbeidsflyt for feilsøking

1. Filtrer etter redir ≥ 1: Se hvor stor prosentandel av den totale trafikken din som treffer minst én redirect. Alt over 15 % er verdt å undersøke.
2. Grupper etter URL: Finn hvilke landingssider som er de verste synderne. Markedsføringssider og gamle blogginnlegg med endrede slugs har en tendens til å dominere.
3. Splitt intern vs ekstern: Filtrer etter navigasjonsopprinnelse (navigation origin). Trafikk fra samme opprinnelse med redirects betyr at dine egne lenker er feil. Cross-origin redirects er vanskeligere å fikse, men mindre presserende.
4. Fiks kilden, ikke redirecten: Ikke optimer selve redirecten (raskere serverrespons). Eliminer den ved å oppdatere lenken som forårsaket den.

Tommelfingerregler for utviklere

• 0 redirects på all intern navigasjon. Ingen redirect fra ditt eget nettsted er akseptabel når du kontrollerer kildelenken.
• Gjennomfør revisjon etter hver URL-migrering. Når du endrer slugs eller flytter sider, bruk grep på kodebasen din og CMS-et for å finne de gamle stiene. Redirects er et sikkerhetsnett for eksterne lenker, ikke en erstatning for å oppdatere dine egne referanser.
• Budsjetter 150ms per redirect på mobil. Hvis TTFB-målet ditt er 800ms og brukerne treffer to redirects, har du allerede brukt 300ms før serveren din gjør noe som helst arbeid.

Redirects er den enkleste TTFB-gevinsten å finne og fikse. Ingen kodeendringer, ingen servertilpasning, ingen optimalisering av ressurser. Bare oppdater URL-en som peker til feil sted.