Fiks og identifiser Time to First Byte (TTFB)-problemer

Finn og fiks Time to First Byte (TTFB)-problemer

Denne artikkelen er en del av vår Time to First Byte (TTFB)-guide. TTFB er en diagnostisk metrikk som måler tiden mellom at en bruker ber om en side og nettleseren mottar den første byten av svaret. Selv om TTFB ikke er en Core Web Vital i seg selv, påvirker den direkte både First Contentful Paint (FCP) og Largest Contentful Paint (LCP). En god TTFB er under 800 millisekunder ved den 75. persentilen.

I vår forrige artikkel snakket vi om Time to First Byte. Hvis du ønsker å lese om det grunnleggende, er det et godt sted å begynne.

I denne artikkelen vil vi fokusere på å identifisere de ulike Time to First Byte-problemene og deretter forklare hvordan du fikser dem.

TTFB-TIPS: mesteparten av tiden vil TTFB være mye dårligere for førstegangsbesøkende siden de ikke har en DNS-hurtigbuffer for nettstedet ditt. Når du sporer TTFB gir det mye mening å skille mellom førstegangs- og gjentakende besøkende.

Steg 1: Sjekk TTFB i Search Console

"Det første steget til bedring er å innrømme at du har et problem." Så før vi gjør noe for å fikse Time to First Byte, la oss forsikre oss om at vi virkelig har et problem med TTFB.

Dessverre rapporteres ikke Time to First Byte i Google Search Console, så vi må falle tilbake til pagespeed.web.dev for å spørre CrUX-dataene til nettstedet vårt. Heldigvis er stegene enkle: naviger til pagespeed.web.dev, skriv inn URL-en til siden din, og sørg for at "origin"-knappen er valgt (siden vi trenger data for hele nettstedet og ikke bare for forsiden). Bytt nå mellom Mobile og Desktop og sjekk Time to First Byte for begge enhetstyper.

I eksempelet nedenfor vil du se et nettsted som ikke består Core Web Vitals på grunn av høy TTFB.

Steg 1b: Bruk Server-Timing-headeren for dypere innsikt

Server-Timing HTTP-svarheaderen lar serveren din kommunisere backend-ytelsesmetrikker direkte til nettleseren. Dette gjør det mulig å finne nøyaktig hvilken del av serverprosesseringen som er treg uten å trenge tilgang til serverlogger.

En typisk Server-Timing-header ser slik ut:

Server-Timing: db;dur=53, app;dur=120, cache;desc="miss"

I dette eksempelet rapporterer serveren tre tidsverdier:

• db;dur=53: databasespørringen tok 53 millisekunder.
• app;dur=120: applikasjonslogikken (malrendering, API-kall osv.) tok 120 millisekunder.
• cache;desc="miss": serverhurtigbufferen ble ikke brukt for denne forespørselen (et hurtigbuffer-bom).

Du kan lese disse verdiene i Chrome DevTools ved å åpne Network-fanen, velge dokumentforespørselen og bla ned til "Server Timing"-seksjonen i Timing-fanen. Verdiene er også tilgjengelige gjennom PerformanceServerTiming-API-et i JavaScript:

const [navigation] = performance.getEntriesByType('navigation');
if (navigation.serverTiming) {
  navigation.serverTiming.forEach(entry => {
    console.log(`${entry.name}: ${entry.duration}ms (${entry.description})`);
  });
}

Hvis serveren din ennå ikke sender Server-Timing-headere, bør du vurdere å legge dem til. De fleste webrammeverk gjør dette enkelt. I PHP kan du legge til headeren før eventuell utdata:

header('Server-Timing: db;dur=' . $dbTime . ', app;dur=' . $appTime);

I Node.js med Express:

res.setHeader('Server-Timing', `db;dur=${dbTime}, app;dur=${appTime}`);

Server-Timing-headeren er spesielt nyttig når den kombineres med Real User Monitoring fordi den lar deg korrelere ytelse på serversiden med TTFB som ekte brukere opplever. Lær mer om hvordan 103 Early Hints kan redusere opplevd TTFB ytterligere ved å sende ressurshint før hele svaret er klart.

Steg 2: Sett opp RUM-sporing

Time to First Byte er en vanskelig metrikk. Vi kan ikke bare stole på syntetiske tester for å måle TTFB fordi andre faktorer i virkeligheten vil bidra til svingninger i TTFB. For å få svar på alle spørsmålene ovenfor må vi måle dataene i virkeligheten og logge eventuelle problemer som kan oppstå med Time to First Byte. Dette kalles Real User Monitoring, og det finnes flere måter å aktivere RUM-sporing på. Vi har utviklet CoreDash nettopp for disse brukstilfellene. CoreDash er et rimelig, raskt og effektivt RUM-verktøy som gjør jobben. Det finnes selvfølgelig mange RUM-løsninger der ute, og de vil også gjøre jobben (til en høyere pris).

Hvordan tenke om TTFB: Tenk deg at en webserver er et restaurantkjøkken, og en bruker som ber om en nettside er en sulten kunde som legger inn en bestilling. Time to First Byte (TTFB) er tidsrommet mellom at kunden legger inn bestillingen og kjøkkenet begynner å tilberede maten.
Så TTFB handler IKKE om hvor raskt hele måltidet er tilberedt (First Contentful Paint) og servert (Largest Contentful Paint), men snarere om hvor responsivt kjøkkenet er på den første forespørselen.
RUM-sporing kan sammenlignes med å undersøke kundene for å forstå spiseopplevelsen deres. Du kan oppdage at kunder som sitter lenger unna kjøkkenet får mindre oppmerksomhet fra servitøren og blir servert senere, eller at gjentakende kunder får fortrinn mens nye besøkende må vente lenger på et bord.

Steg 2b: Etabler en ytelsesbasislinje

Før du gjør noen endringer, etabler en basislinje for din TTFB. Registrer den 75. persentilen for TTFB på tvers av følgende dimensjoner, da dette vil hjelpe deg med å måle effektiviteten av optimaliseringene dine senere:

1. Samlet TTFB (mobil og desktop separat): registrer den 75. persentilen for hver enhetstype.
2. Topp 10 sider etter trafikk: registrer TTFB for sidene med høyest trafikk individuelt.
3. Nye besøkende vs. gjentakende besøkende: førstegangsbesøkende har vanligvis høyere TTFB på grunn av DNS- og tilkoblingsoverhead.
4. Topp 5 land etter trafikk: geografisk avstand til serveren din påvirker TTFB betydelig.
5. TTFB-deloppbrudd: registrer den 75. persentilen for hver deldel (ventetid, hurtigbuffer, DNS, tilkobling, forespørsel).

Dokumenter disse tallene i et regneark. Etter implementering av hver optimalisering, vent minst 7 dager for å samle inn nok RUM-data før du sammenligner resultater. En god tilnærming er å ta tak i én TTFB-deldel om gangen, måle, og deretter gå videre til neste.

Steg 3: Identifiser Time to First Byte-problemer

Mens Googles Chrome User Experience Report (CrUX) gir verdifulle feltdata, tilbyr den ikke spesifikke detaljer om årsakene til høy TTFB. For å forbedre TTFB effektivt trenger vi å vite nøyaktig hva som skjer på et mer detaljert nivå. På dette punktet er det fornuftig å skille mellom generelt feilende TTFB og TTFB som feiler under spesifikke forhold (selv om det i virkeligheten alltid vil være en blanding).

3.1 TTFB feiler generelt

1. Sjekk for generelt dårlige "forespørselstider": Dårlige forespørselstider betyr at "problemet" ligger i tiden det tar serveren å generere siden. Dette er den vanligste årsaken til dårlige TTFB-poeng.
2. Sjekk for andre dårlige TTFB-deldeler: TTFB er ikke bare én enkelt metrikk, men kan brytes ned i flere deler som hver har sitt eget optimaliseringspotensial. Hvis ventevarigheten, hurtigbuffervarigheten, DNS-oppslagsvarigheten, eller tilkoblingsvarigheten er trege, må du sannsynligvis justere serverinnstillingene dine eller begynne å se etter hosting av bedre kvalitet.

3.2 TTFB feiler under spesifikke forhold

1. Landssegmentering: Å forstå den geografiske fordelingen av høy TTFB er viktig, spesielt for nettsteder med et globalt publikum. Hvis du serverer sidene dine fra én server i bare ett land (uten CDN-kantbufring), vil den fysiske avstanden mellom brukerens plassering og serveren som hoster nettstedet forårsake alle slags forsinkelser og påvirke TTFB. Vurder å konfigurere Cloudflare eller et annet CDN for å bringe innholdet ditt nærmere brukere over hele verden.
   
2. Hurtigbuffersegmentering: Hurtigbufring kan redusere TTFB ved å hoppe over serverside-genereringen av HTML. Dessverre er det vanlig at hurtigbufring er deaktivert eller forbigått av mange grunner. For eksempel kan hurtigbufring være deaktivert for innloggede brukere, handlevognsider, sider med spørrestrenger (f.eks. fra Google Ads), søkeresultatsider og betalingssider. Hvis nettstedet ditt bruker (kant-)hurtigbufring, bruk RUM-sporing for å sjekke treffprosenten for hurtigbufferen.
   
3. Side(klynge)-segmentering: Forskjellen i Time to First Byte-ytelse (eller mangelen på forskjell) mellom sider eller sidetyper er noe annet vi må fastslå. Å vite hvilke sider som feiler TTFB-metrikken vil gi verdifull innsikt i hvordan man kan forbedre Time to First Byte.
   
4. Viderekoblingssegmentering: Viderekoblingstid legges direkte til TTFB. Hver viderekoblling legger til ekstra tid før webserveren kan begynne å laste siden. Å måle og eliminere unødvendige viderekoblinger kan bidra til å forbedre TTFB. For en dypere titt på viderekoblingsoptimalisering, se vår guide til ventedelen av TTFB.
   
5. Annen segmentering: Selv om segmentering etter variablene ovenfor dekker de vanlige mistenkte, er hvert nettsted unikt og har sine egne utfordringer. Heldigvis er RUM-sporing designet for å tillate segmentering etter mange flere variabler som enhets-RAM, nettverkshastighet, enhetstype, operativsystem, egendefinerte variabler og mye mer.

Steg 4: Zoom inn på problemer og fiks

Deldelene av Time to First Byte (TTFB) er:

• Venting + viderekoblinger (eller ventevarighet)
• Worker + hurtigbuffer (eller hurtigbuffervarighet)
• DNS (eller DNS-varighet)
• Tilkobling (eller tilkoblingsvarighet)
• Forespørsel (eller forespørselsvarighet)

Steg 5: Hurtigfiksliste for vanlige TTFB-problemer

Basert på deldelen som bidrar mest til din TTFB, her er en hurtigreferanse for de vanligste fiksene:

Måle TTFB med JavaScript

Du kan måle hele TTFB og dens deldeler direkte i nettleseren ved hjelp av Navigation Timing API. Følgende kodesnutt beregner TTFB og logger hver deldel:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const activationStart = nav.activationStart || 0;

  const ttfb = nav.responseStart - activationStart;
  const waitingDuration = (nav.workerStart || nav.fetchStart) - activationStart;
  const cacheDuration = nav.domainLookupStart - (nav.workerStart || nav.fetchStart);
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;
  const connectionDuration = nav.connectEnd - nav.connectStart;
  const requestDuration = nav.responseStart - nav.requestStart;

  console.log('TTFB:', ttfb.toFixed(0), 'ms');
  console.log('  Waiting:', waitingDuration.toFixed(0), 'ms');
  console.log('  Cache:', cacheDuration.toFixed(0), 'ms');
  console.log('  DNS:', dnsDuration.toFixed(0), 'ms');
  console.log('  Connection:', connectionDuration.toFixed(0), 'ms');
  console.log('  Request:', requestDuration.toFixed(0), 'ms');
}).observe({
  type: 'navigation',
  buffered: true
});

Denne koden gir den samme oppdelingen som verktøy som CoreDash viser i TTFB-attribusjonspanelet. Å kjøre denne kodesnutten i nettleserkonsollen gir deg en umiddelbar avlesning for en enkelt sideinnlasting, mens RUM-verktøy samler inn disse dataene fra tusenvis av ekte brukere for å produsere pålitelige 75. persentilverdier.

Videre lesning: Optimaliseringsguider

For spesifikke optimaliseringsteknikker som forbedrer TTFB, utforsk disse relaterte guidene:

• 103 Early Hints: send ressurshint før hele svaret er klart, slik at nettleseren kan begynne å laste kritiske ressurser mens serveren fortsatt prosesserer.
• Konfigurer Cloudflare for ytelse: sett opp Cloudflares CDN, hurtigbufring og kantfunksjoner for å redusere TTFB for globale publikum.

TTFB-deldeler: Dybdeartikler

Hver deldel av Time to First Byte har unike optimaliseringsstrategier. Utforsk det spesifikke området som RUM-dataene dine identifiserer som flaskehalsen:

• Ventevarighet: viderekoblinger, nettleserkøer og HSTS-optimalisering.
• Hurtigbuffervarighet: service worker-ytelse, nettleserhurtigbuffer og bfcache.
• DNS-varighet: valg av DNS-leverandør, TTL-konfigurasjon og dns-prefetch.
• Tilkoblingsvarighet: TCP-håndtrykk, TLS-optimalisering, HTTP/3 og preconnect.