Reducer ventetidsdelen af Time to First Byte

Reducer ventetiden af Time to First Byte

Time to First Byte (TTFB) kan opdeles i følgende underdele:

• Waiting + Redirect (eller ventetid)
  
• Worker + Cache (eller cachetid)
• DNS (eller DNS-tid)
• Connection  (eller forbindelsestid)
• Request (eller forespørgselstid)

Vil du optimere Time to First Byte? Denne artikel giver en dybdegående analyse af ventetidsdelen af Time to First Byte. Hvis du ønsker at forstå eller løse problemer med Time to First Byte og ikke ved, hvad ventetiden betyder, bedes du læse hvad er Time to First Byte og find og identificer Time to First Byte-problemer før du starter med denne artikel

Redirects kan have stor indvirkning på Time to First Byte (TTFB), fordi hver redirect lægges til den tid, det tager for en browser at modtage den første byte data fra en server. Sådan påvirker redirects TTFB:

Hvordan øger redirects Time to First Byte?

Redirects er typisk inkluderet i den fulde TTFB-måling (se blå boks). Det betyder, at den tid, der bruges på alle redirects, indregnes i den samlede TTFB-score, hvilket potentielt kan få den til at fremstå højere end forventet.

Når en side bliver redirectet, er disse de sædvanlige trin, der forekommer:

• Browseren sender en indledende forespørgsel til den oprindelige URL.
  
• Serveren behandler denne forespørgsel og svarer med en redirect-statuskode (f.eks. 301 eller 302).
  
• Browseren sender derefter en ny forespørgsel til den redirectede URL.Serveren behandler denne anden forespørgsel og begynder at sende det faktiske indhold.

Øget serverbehandlingstid

Denne ekstra behandling øger den samlede TTFB, da hvert trin kræver tid for serveren til at håndtere forespørgslen og svare.

Redirect-kæder

I nogle tilfælde kan flere redirects forekomme, før den endelige destination nås. Dette skaber en "redirect-kæde", der kan øge TTFB. Hver redirect i kæden tilføjer sin egen behandlingstid, hvilket øger forsinkelsen, før den første byte af det faktiske indhold modtages.

Netværksforsinkelse

Redirects involverer ofte yderligere netværksrundture mellem klienten og serveren. Dette introducerer ekstra netværksforsinkelse, især hvis redirects involverer forskellige domæner eller servere. Den fysiske afstand mellem klienten og serveren for hver redirect kan yderligere påvirke TTFB.

JavaScript redirects vs Server side redirects: Kun server side redirects (der fungerer med en 30x redirect-header) bliver tilføjet til Time to First Byte. JavaScript redirects bliver ikke tilføjet til Time to First Byte, fordi et komplet svar (200) er blevet sendt af serveren.

Man kunne tro, at JavaScript redirects bør foretrækkes, da de ikke lægges til Time to First Byte. Desværre er JavaScript redirects meget langsommere for rigtige brugere og vil forårsage en dårlig User Experience,

Indvirkning på User Experience (og SEO)

Selvom redirects nogle gange er nødvendige, kan deres indvirkning på TTFB have bredere konsekvenser:

• User Experience: Langsommere TTFB på grund af redirects kan forsinke den indledende rendering af siden, hvilket potentielt frustrerer brugerne.
• SEO: Selvom TTFB ikke er en direkte rankingfaktor, påvirker det andre målinger som Largest Contentful Paint (LCP), som er en Core Web Vital, der tages i betragtning af søgemaskiner.

Sådan måler du TTFB-problemer forårsaget af redirects

For at finde den indvirkning, som rigtige brugere oplever på grund af redirects, skal du bruge et RUM-værktøj som CoreDash. Real user monitoring giver dig mulighed for at spore Core Web Vitals i stor detalje.

I CoreDash skal du blot 'klikke på redirect count' for at visualisere dine data segmenteret efter antal redirects. Klik derefter for eksempel på segmentet '1 redirect' for at filtrere RUM-data efter '1 redirect' og se alle berørte URL'er.  

Sådan minimerer du redirect-indvirkningen

Som en generel regel skal du følge disse 3 simple trin for at undgå redirect-problemer:

• Minimer brugen af redirects, hvor det er muligt.
  
• Undgå redirect-kæder ved at opdatere links, så de peger direkte til den endelige destinations-URL.
• Brug server-side redirects i stedet for client-side redirects, når det er muligt, da de generelt er hurtigere.

Same origin redirects. Same-origin redirects stammer fra links på din egen hjemmeside. Du bør have fuld kontrol over disse links, og du bør prioritere at rette dem, når du arbejder på Time to First Byte. Den typiske metode til at finde disse interne redirects er ved at bruge et af de tilgængelige værktøjer derude, som lader dig kontrollere hele din hjemmeside for redirects.

Cross-origin redirects. Cross-origin redirects stammer fra links på andre hjemmesider. Du har meget lidt kontrol over disse. For links med stor indvirkning, der genererer meget trafik, kan du overveje at kontakte webmasteren af siden for at opdatere den linkede URL.

Redirect-kæder. Flere redirects eller redirect-kæder opstår, når en enkelt redirect ikke omdirigerer til ressourcens endelige placering. Disse typer redirects belaster Time to First Byte mere og bør undgås for enhver pris. Brug igen et værktøj til at finde disse typer redirects og rette dem!

HTTP-to-HTTPS redirects. En måde at omgå dette på er at bruge Strict-Transport-Security-headeren (HSTS), som vil håndhæve HTTPS ved det første besøg på en oprindelse og derefter fortælle browseren at tilgå oprindelsen direkte via HTTPS-skemaet ved fremtidige besøg.

Generelt anbefaler vi at:

1. Kontroller og opdater regelmæssigt dine interne links! Når du ændrer placeringen af en side, skal du opdatere dine interne links til den side for at sikre, at ingen referencer til den tidligere sideplacering forbliver.
   
2. Håndter redirects på serverniveau. Den foretrukne redirect-metode er en 301 redirect. En 301 redirect er en permanent redirect, mens en 302 redirect er en midlertidig redirect. Midlertidige redirects bliver for eksempel muligvis ikke opdateret i søgemaskiner.
   
3. Brug relative URL'er: Når du linker til sider på din egen hjemmeside, skal du bruge relative URL'er i stedet for absolutte URL'er. Dette hjælper med at forhindre unødvendige redirects.
   
4. Brug kanoniske URL'er: Hvis du har flere sider med lignende indhold, skal du bruge en kanonisk URL til at angive den foretrukne version af siden. Dette hjælper med at forhindre duplikeret indhold og unødvendige redirects.