Hvorfor Time to First Byte er treg, og hva du kan gjøre med det

Start med hva TTFB faktisk måler

Time to First Byte, vanligvis forkortet til TTFB, er tiden mellom at nettleseren ber om en ressurs og mottar den første byten i svaret.

Det høres ut som en servermåling, men det er ikke bare en servermåling. TTFB omfatter flere trinn:

• DNS-oppslag, hvis vertsnavnet ikke allerede er løst
• TCP-oppkobling
• TLS-forhandling for HTTPS
• Tiden forespørselen bruker til serveren eller CDN-kanten
• Kø og behandling på serveren
• Tiden svaret bruker tilbake til nettleseren

Så en høy TTFB kan bety at backenden din er treg. Det kan også bety at brukeren er langt fra origin-serveren, at CDN-et er feilkonfigurert, at cachen stadig bommer, eller at serveren bruker for lang tid på å avgjøre hva den skal sende.

Dette betyr noe fordi TTFB ligger nær begynnelsen av lastingskjeden. Hvis HTML-dokumentet kommer sent, oppdager nettleseren CSS, JavaScript, fonter og bilder sent også. Du kan ha utmerket front-end-optimalisering og likevel oppleves treg hvis det første dokumentsvaret tar 1,5 sekunder.

Hva regnes som treg TTFB?

Det finnes ikke ett universelt tall som passer alle nettsteder, regioner og arkitekturer. Likevel er praktiske terskler nyttige.

Google’s web.dev-veiledning klassifiserer en god TTFB som under 800 ms, 800–1800 ms som behov for forbedring, og over 1800 ms som dårlig. For en godt cachet markedsføringsside som leveres nær brukeren, kan du ofte gjøre det langt bedre enn dette. For et komplekst autentisert dashboard som gjør dynamisk arbeid, kan det akseptable tallet være høyere, men det bør fortsatt kunne forklares.

Den viktige vanen er å segmentere tallet. En global gjennomsnittlig TTFB på 900 ms kan skjule et svar på 150 ms for brukere nær CDN-kanten og et svar på 2200 ms for brukere i en annen region. På samme måte kan forsiden din være fin, mens søk, kategorisider eller innloggede sider i det stille er smertefulle.

Mål det på mer enn ett sted

Ikke diagnostiser TTFB fra én enkelt Lighthouse-kjøring. Lighthouse er nyttig, men det er én test fra ett miljø. Hvis du er ny i å tolke den, start med en rolig gjennomgang av hvordan du leser en Lighthouse-rapport uten å få panikk — hovedpoenget er å skille laboratoriesignaler fra feltvirkelighet.

For TTFB vil du ha minst tre perspektiver:

1. Nettleserens utviklerverktøy

Åpne Network-panelet, last inn på nytt med cache deaktivert, og inspiser forespørselen for hoveddokumentet. Tidsinndelingen viser DNS, oppkobling, TLS, venting og nedlastingsfaser. «Waiting»-fasen er ofte det folk mener med backend-tid, selv om den kan omfatte oppstrøms latenstid.

2. Syntetiske tester fra flere regioner

Kjør tester fra steder som er både nær og langt fra brukerne dine. Hvis TTFB er lav i én region og høy i en annen, mistenk geografi, CDN-ruting, plassering av origin-server eller cachedekning før du omskriver applikasjonskode.

3. Real user monitoring eller serverlogger

Feltdata forteller deg hva ekte brukere opplever på tvers av enheter, nettverk og økter. Serverlogger kan fortelle deg om origin-serveren genererte et svar raskt. Forskjellen mellom klientobservert TTFB og behandlingstid på origin er ofte der CDN- og nettverksproblemer viser seg.

De vanlige årsakene til treg TTFB

HTML-en din blir ikke cachet

Dette er det vanligste problemet på innholdssider og e-handelsnettsteder. Statiske ressurser caches aggressivt, men HTML-dokumentet — det nettleseren trenger først — genereres ved hver forespørsel.

Noen ganger er det nødvendig. Ofte er det ikke det.

Hvis en offentlig side endres noen få ganger per dag, bør den sannsynligvis ikke kreve en fersk database-rendering for hver anonyme besøkende. Bruk fullsidecache, edge caching, statisk generering eller stale-while-revalidate-mønstre der det passer.

Sjekk svarheadere for signaler som Cache-Control, CDN-Cache-Status, Age, Vary og Set-Cookie. En side som sender en unik cookie til hver besøkende, kan ved et uhell gjøre seg selv umulig å cache. Hvis du trenger en praktisk måte å resonnere om dette laget på, gjelder de samme feilsøkingsvanene i vår guide til redirects og HTTP-headere i produksjon direkte for TTFB-arbeid.

CDN-et ditt cacher bare ressurser

Mange team legger til et CDN og antar at ytelsesjobben er gjort. Men hvis CDN-et bare leverer bilder, CSS og JavaScript, kan den første HTML-forespørselen fortsatt måtte reise hele veien til én enkelt origin-server.

Det kan være greit for et lokalt bedriftsnettsted med lokale brukere. Det er ikke greit for et internasjonalt publikum. Jo lenger brukeren er fra origin-serveren, desto mer latenstid betaler du før backend-arbeidet i det hele tatt starter.

God CDN-konfigurasjon for TTFB betyr vanligvis:

• Cache offentlig HTML der det er trygt
• Respekter tilsiktede bypass-regler for autentiserte eller personaliserte sider
• Unngå unødvendige Vary-headere som splitter cachen for fint
• Bruk cache-tømming eller revalidering i stedet for å deaktivere cache helt
• Bekreft at edge-lokasjoner faktisk leverer treff, ikke videresender hver forespørsel

Et CDN er ikke magi. Det er et cache- og rutinglag. Behandle det som det.

Serveren din gjør for mye før den svarer

En treg backend-sti kan komme av mange små forsinkelser: databasespørringer, API-kall, template-rendering, feature flag-sjekker, autentisering, personalisering, logging og cold starts.

Det verste mønsteret er serielt avhengighetsarbeid. For eksempel:

1. Hent sidedata
2. Deretter hent relaterte produkter
3. Deretter hent priser
4. Deretter kall en anbefalingstjeneste
5. Deretter render HTML

Hvis hvert trinn venter på det forrige, vokser TTFB raskt. Parallelliser uavhengig arbeid, fjern ikke-kritiske kall fra det første svaret, og cache kostbare resultater.

En nyttig regel: Hvis brukeren ikke kan se eller bruke resultatet umiddelbart, bør det sannsynligvis ikke blokkere den første byten.

Databasespørringer er trege eller uforutsigbare

Databaser forårsaker ofte TTFB-problemer fordi de oppfører seg godt i utvikling og dårlig under reell trafikk. Manglende indekser, store joins, N+1-spørringer, låskonkurranse og overdimensjonerte resultatsett viser seg alle som «serveren er treg».

Ikke gjett her. Fang spørringstider for trege forespørsler. Se på p95 og p99, ikke bare gjennomsnitt. En side som vanligvis svarer på 120 ms, men av og til blokkerer i 4 sekunder, vil fortsatt gi en dårlig brukeropplevelse.

Vanlige fikser inkluderer:

• Legge til eller korrigere indekser
• Fjerne N+1-spørringsmønstre
• Cache data med mange lesinger
• Paginere store spørringer
• Flytte rapporterings- eller analysespørringer bort fra forespørselstid
• Sette fornuftige tidsavbrudd for nedstrøms kall

Applikasjonen din har cold starts

Serverless- og containeriserte plattformer kan være utmerkede, men cold starts kan skade TTFB når trafikken kommer i rykk eller regioner er underprovisjonert.

Hvis den første forespørselen etter inaktiv tid er mye tregere enn senere forespørsler, undersøk cold starts. Du kan trenge provisioned concurrency, mindre bundles, færre oppstartsavhengigheter, varmere funksjoner eller en annen utrullingsform for ruter som er følsomme for latenstid.

Dette er ikke et argument mot serverless. Det er et argument mot å late som om runtime-modellen er usynlig.

Redirects kaster bort den første forespørselen

En redirect legger til en ny forespørsel-svar-syklus før nettleseren mottar det endelige dokumentet. Én redirect fra http:// til https:// kan være uunngåelig for gamle lenker, men kjeder er sløsing.

Vanlige kjeder inkluderer:

• http://example.com → https://example.com → https://www.example.com
• normalisering av trailing slash etter protokollnormalisering
• geo- eller språk-redirects før cacheoppslag
• gamle kampanjelenker som hopper gjennom flere URL-er

Fiks kildelenkene der det er mulig, slå sammen redirect-regler, og gjør kanoniske URL-er direkte. Redirect-tid rapporteres ikke alltid som TTFB for den endelige forespørselen, men brukeren betaler fortsatt for den.

En praktisk feilsøkingsrekkefølge

Når TTFB ser treg ut, bruk denne rekkefølgen. Den unngår den vanlige feilen med å optimalisere applikasjonskode før cache- og rutingatferd er bekreftet.

Step 1: Test hoveddokumentet, ikke bare hele siden

Finn forespørselen for HTML-dokumentet. Registrer total TTFB og tidsinndelingen. Gjenta med og uten nettlesercache. Test en offentlig side, en dynamisk side og en innlogget side hvis relevant.

Step 2: Sammenlign regioner

Kjør samme URL fra flere geografiske steder. Hvis de trege regionene korrelerer med avstand fra origin, prioriter CDN og edge caching. Hvis alle regioner er trege, se på backend-behandling og kapasitet på origin.

Step 3: Inspiser svarheadere

Se etter cache-headere, cookies, Age, CDN-status og Vary. En manglende Age-header eller gjentatte cache-miss er ledetråder. En bred Vary: Cookie-header på offentlig HTML er ofte en cache-dreper.

Step 4: Sjekk origin-timing

Legg til server-timing-instrumentering. Server-Timing-headeren kan synliggjøre backend-faser som databasetid, render-tid og oppstrøms API-tid. Selv enkle etiketter er nyttige:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

Nå kan nettlesertimingene dine vise om serveren brukte 300 ms på reelt arbeid, eller om forsinkelsen oppsto før forespørselen nådde applikasjonen din.

Step 5: Fiks den største bekreftede forsinkelsen

Dette høres åpenbart ut, men team fikser ofte det som er kjent, heller enn det som er målt. Hvis cache-miss dominerer, fiks caching. Hvis databasen dominerer, fiks spørringer. Hvis TLS og oppkobling dominerer for globale brukere, fiks ruting, CDN-dekning eller origin-geografi.

Front-end-arbeid betyr fortsatt noe. Fonter, bilder og JavaScript påvirker det som skjer etter at HTML-en kommer. Men de er ikke erstatninger for et raskt første svar. Hvis du også arbeider med render-ytelse, er web fonts fortsatt en av de enkleste gevinstene på mange nettsteder fordi de påvirker hvor raskt tekst blir brukbar etter at dokumentet kommer.

Fikser som vanligvis fungerer

Cache offentlig HTML ved kanten

For markedsføringssider, dokumentasjon, blogger, landingssider og kategorisider er edge caching ofte den største TTFB-forbedringen. Bruk korte TTL-er hvis innhold endres ofte. Bruk stale-while-revalidate hvis litt utdatert innhold er akseptabelt mens cachen oppdateres i bakgrunnen.

Vær forsiktig med personalisering. Hvis en side varierer etter valuta, språk, innloggingsstatus eller eksperimentgruppe, definer disse variantene eksplisitt. Utilsiktet per-bruker-variasjon ødelegger cache-effektiviteten.

Flytt ikke-kritisk arbeid ut av forespørselsstien

E-postutsending, analyseberikelse, generering av anbefalinger, webhook-kall og tung logging bør sjelden blokkere den første byten. Legg dem i køer eller kjør dem etter at svaret er startet.

Reduser backend-avhengighetskjeder

Parallelliser uavhengige kall. Cache svar fra trege API-er. Sett tidsavbrudd. Design reserveinnhold for tjenester som er nyttige, men ikke essensielle.

En treg anbefalingswidget bør ikke forsinke hele produktsiden.

Plasser beregning nærmere brukerne

Hvis brukerne dine er globale og origin-serveren er i én region, er latenstid strukturell. CDN-caching kan skjule mye av dette for offentlig innhold. For dynamisk innhold bør du vurdere regionale utrullinger, edge rendering for egnede ruter, eller å flytte API-er nærmere publikum.

Hold redirects kjedelige

Kanoniser URL-er i ett hopp. Oppdater interne lenker slik at brukere og crawlere går direkte til den endelige destinasjonen. Revider gamle kampanje-URL-er og plattformmigreringer. Redirects er lette å ignorere fordi de er usynlige når de fungerer, men de koster fortsatt tid.

Hva du ikke bør gjøre

Ikke jakt på et perfekt TTFB-tall for hver rute. En autentisert rapport som utfører reell beregning, vil ikke oppføre seg som et cachet blogginnlegg.

Ikke bruk gjennomsnittlig TTFB som eneste måleparameter. Persentiler betyr noe. Geografi betyr noe. Sidetype betyr noe.

Ikke anta at et CDN betyr at HTML-en din er cachet. Verifiser det.

Og ikke behandle TTFB som adskilt fra produktbeslutninger. Personalisering, eksperimentering, sanntidslager og tredjepartstjenester har alle latenstidskostnader. Noen er verdt det. Noen er bare vane.

<!-- tool-cta:start -->

💡 Prøv dette: Når du diagnostiserer TTFB, avslører Get Headers cache-status, servertiminger og omdirigeringer som ofte forklarer hvor forsinkelsen kommer fra.

<!-- tool-cta:end -->

Den rolige versjonen av planen

En treg TTFB er vanligvis mulig å fikse når du slutter å behandle den som et vagt «serverproblem». Mål dokumentforespørselen. Segmenter etter region og sidetype. Inspiser headere. Sammenlign klienttiming med origin-timing. Fiks deretter den største bekreftede flaskehalsen.

De fleste nettsteder trenger ikke eksotisk arkitektur. De trenger færre unngåelige cache-miss, mindre blokkerende backend-arbeid, ryddigere redirects og en klarere idé om hva som må skje før den første byten sendes.