TTFB står for Time To First Byte, som på dansk betyder tid til første byte. Det er en måling af, hvor lang tid der går, fra en browser eller anden klient sender en forespørgsel, til den første byte i serverens svar bliver modtaget.
Målingen siger altså ikke noget om, hvornår hele siden er hentet færdig. Den viser kun den første del af svartiden. TTFB bruges til at vurdere, hvor hurtigt en server, et website eller en webapplikation begynder at svare på forespørgsler.
En høj TTFB kan pege på langsom serverbehandling, netværksforsinkelser eller tunge processer bag siden. En lav TTFB betyder derimod, at svaret starter hurtigt, hvilket ofte er et godt tegn for både brugeroplevelse og teknisk performance.
TTFB viser, hvor lang tid der går fra browseren sender en anmodning, til den modtager den allerførste byte fra serveren. Tallet dækker altså ikke kun selve serverens svartid. Det omfatter hele den tidlige del af indlæsningen, hvor forbindelsen først skal etableres, før data kan begynde at komme frem.
I praksis indgår flere led i målingen. Browseren kan først skulle lave et DNS-opslag for at finde den rigtige server. Derefter oprettes forbindelsen, og hvis siden bruger sikker forbindelse, indgår også et TLS-handshake. Oven i det kommer netværksforsinkelse, altså den tid det tager for signaler at rejse mellem bruger og server. Jo længere afstand, flere mellemled eller mere belastning, desto højere kan tallet blive.
Når anmodningen er nået frem, skal serveren stadig behandle den. Det kan være opslag i databaser, kørsel af kode, hentning fra cache eller samling af HTML, før første byte sendes tilbage. Forenklet kan man derfor sige, at TTFB er summen af forbindelsesoprettelse + netværksforsinkelse + serverbehandling. Målingen fortæller dermed, hvad der sker frem til første respons, men ikke hvor lang tid hele siden bruger på at blive vist færdig.
Når den første byte lader vente på sig, skyldes det ofte, at serveren eller den bagvedliggende applikation bruger for lang tid på at gøre svaret klar. Et klassisk problem er cache-miss: Hvis siden ikke kan leveres fra cache, skal systemet generere indholdet fra bunden. Det kræver typisk ekstra behandling i CMS, plugins eller backend-logik og kan øge TTFB mærkbart.
En anden hyppig årsag er en langsom database. Tunge forespørgsler, manglende indekser, mange samtidige opslag eller store datamængder kan forsinke hele svartiden. Det samme gælder en overbelastet server, hvor CPU, RAM eller disk-I/O er presset. I sådanne tilfælde står forespørgsler ofte i kø, før de overhovedet bliver behandlet. Delte hostingmiljøer er særligt følsomme, fordi andre kunders trafik også kan påvirke ydeevnen.
Netværk og placering spiller også ind. Hvis der er lang afstand til datacenteret, tager det længere tid for anmodning og svar at rejse mellem bruger og server. Problemet bliver tydeligere for besøgende i andre lande eller verdensdele. Manglende CDN kan derfor være en vigtig forklaring, især på websites med international trafik, fordi statiske filer og nogle gange hele sider ikke bliver leveret fra en node tæt på brugeren. Endelig kan fejlkonfigureret hosting, langsom TLS-forhandling eller ustabile upstream-tjenester i backend trække første byte yderligere ud.
Den mest praktiske måde at komme i gang på er at måle direkte i browseren. I udviklerværktøjer som Chrome DevTools eller Firefox’ netværkspanel kan du indlæse siden, vælge det første HTML-dokument og se tidsopdelingen for anmodningen. Her fremgår ventetiden, før den første byte modtages fra serveren. Det er den del, der i praksis svarer til TTFB.
Eksterne hastighedstests er nyttige, når du vil se, hvordan siden reagerer uden for din egen computer og forbindelse. Værktøjer som PageSpeed Insights eller WebPageTest kan vise svartider fra forskellige lokationer og under forskellige netværksforhold. Det giver et mere realistisk billede af, hvad rigtige brugere oplever, især hvis dit publikum er geografisk spredt.
Hvis du vil arbejde mere teknisk, kan serverlogs, overvågning og analyseværktøjer hjælpe med at skille netværksforsinkelse fra selve serverbehandlingen. Mål flere gange, på forskellige tidspunkter og for både forsiden og tunge undersider. En enkelt test er sjældent nok. Sammenlign resultaterne, og hold især øje med store udsving, fordi de ofte peger på kapacitetsproblemer, langsomme databaser eller ineffektiv cache.
Når serveren er længe om at sende den første byte, føles siden ofte langsom allerede fra start. Brugeren ser ikke nødvendigvis indhold med det samme, og den første respons virker træg, selv før resten af siden er hentet. Det påvirker den oplevede hastighed, fordi ventetiden opstår i begyndelsen af indlæsningen, hvor forventningen om et hurtigt svar er størst.
TTFB er ikke en Core Web Vital, og en høj værdi giver derfor ikke i sig selv en direkte vurdering i de officielle brugercentrerede målinger. Metrikken har alligevel betydning, fordi den kan forsinke andre hastighedsmål, for eksempel hvornår indhold begynder at blive vist, og hvor hurtigt siden bliver brugbar. Hvis serverresponsen er langsom, skubbes flere efterfølgende trin i indlæsningen typisk tilsvarende længere ud.
Fra et teknisk SEO-perspektiv er TTFB også relevant for crawloplevelsen. Søgemaskiners crawlere skal kunne hente mange sider effektivt, og langsomme serversvar kan gøre det mindre smidigt at gennemgå større websites. Det betyder ikke, at høj TTFB alene forklarer svag synlighed, men den kan være et tegn på serverproblemer, tunge backend-processer eller ineffektiv caching. Derfor bruges målingen ofte som en teknisk indikator, der bør vurderes sammen med sidehastighed, logfiler og den samlede performance.
Når man vurderer en sides hastighed, måler tallene ikke det samme. TTFB (Time To First Byte) handler om, hvor hurtigt serveren sender den første byte tilbage til browseren. Det er altså et mål for serverrespons og netværksvej, ikke for hvornår indholdet faktisk bliver synligt for brugeren.
Her adskiller målingen sig tydeligt fra LCP, som viser, hvornår det største synlige element er indlæst. En lav TTFB kan hjælpe LCP, men den garanterer ikke en hurtig visuel indlæsning. Tunge billeder, langsom gengivelse og meget JavaScript kan stadig forsinke det, brugeren ser.
INP måler noget andet igen: hvor hurtigt siden reagerer på brugerens handlinger. CLS handler om visuel stabilitet, altså om elementer flytter sig uventet. Generel sidehastighed bruges ofte som en bred samlebetegnelse for flere forhold, mens TTFB er en afgrænset teknisk måling. Derfor bør begreberne ikke blandes sammen, selv om de alle påvirker oplevelsen af en hurtig side.
Vil du sænke TTFB, bør du først fjerne de største flaskehalse i serverens svarvej. Det mest effektive er ofte cache. Når hele sider eller dele af indholdet kan leveres fra cache i stedet for at blive genereret for hvert besøg, falder svartiden markant. Brug gerne flere lag, for eksempel sidecache, objektcache og opcode-cache. Dernæst er et CDN ofte en hurtig gevinst, fordi statiske filer og i nogle tilfælde cachede HTML-svar kan leveres tættere på brugeren og aflaste den oprindelige server.
Hvis svartiden stadig er høj, er næste skridt at se på hosting og infrastruktur. En langsom eller overbelastet server giver næsten altid et dårligere tal. Hurtigere hosting, bedre CPU-ressourcer, mere RAM og moderne webservere kan forkorte tiden, før det første byte sendes. Det gælder især ved spidsbelastning, hvor mange samtidige forespørgsler ellers kan skabe kø.
Herefter bør du optimere backend og applikationslogik. Tunge databasekald, mange eksterne opslag og ineffektiv kode øger ventetiden, før serveren kan begynde at svare. Gennemgå derfor langsomme forespørgsler, tilføj relevante indekser, og reducer antallet af databasekald pr. sidevisning. Saml logik, der i dag kører flere gange unødigt, og flyt opgaver væk fra den kritiske svarvej, hvis de ikke behøver blive behandlet med det samme. Jo mindre arbejde applikationen skal udføre pr. request, desto lavere bliver TTFB typisk.
En god TTFB er som udgangspunkt så lav som muligt. For mange websites betragtes under cirka 800 ms som fornuftigt, mens lavere værdier ofte er bedre, især på vigtige landingssider.
Det rigtige niveau afhænger dog af sidetypen, serveropsætningen, cache og hvor langt brugeren er fra serveren. En dynamisk side uden cache vil typisk have højere TTFB end en cachet side.
TTFB måles fra det øjeblik, browseren sender en HTTP-anmodning, til den første byte i svaret modtages. Målingen dækker derfor både forbindelsesoprettelse, netværksforsinkelse og den tid serveren bruger på at begynde svaret.
Du kan se tallet i browserens udviklerværktøjer, i hastighedsværktøjer som PageSpeed Insights og WebPageTest eller i mere tekniske overvågningsværktøjer.
Ja, indirekte. TTFB er ikke i sig selv en Core Web Vital, men en langsom første respons kan forsinke andre hastighedsmål og gøre siden langsommere at indlæse for både brugere og søgemaskiner.
På større websites kan høj TTFB også gøre crawling mindre effektiv. Derfor er metrikken relevant i teknisk SEO, selv om den ikke alene afgør placeringer.
TTFB måler, hvor hurtigt serveren begynder at svare. LCP måler derimod, hvornår det største synlige element på siden er vist for brugeren.
En side kan derfor have lav TTFB og stadig dårlig LCP, hvis for eksempel billeder, CSS eller JavaScript er tunge. TTFB handler om starten på indlæsningen, mens LCP handler om den synlige oplevelse.
Høj TTFB skyldes ofte langsom serverbehandling, manglende cache, tunge databaseforespørgsler eller presset hosting. Hvis serveren først skal generere siden fra bunden, stiger ventetiden hurtigt.
Netværket kan også være en del af forklaringen. Lang afstand til serveren, langsom TLS-forhandling eller fravær af CDN kan øge tiden, før første byte når frem.
Det kan være begge dele. TTFB omfatter både tiden til at etablere forbindelsen og den tid, serveren bruger på at begynde svaret.
Hvis problemet varierer meget efter geografi, peger det ofte på netværk eller serverplacering. Hvis tallet især stiger på tunge sider eller under belastning, ligger forklaringen ofte i backend, database eller hostingmiljø.
Du kan måle TTFB i browserens udviklerværktøjer, for eksempel i Chrome DevTools eller Firefox’ netværkspanel. Her kan du se tidsforløbet for den første HTML-anmodning.
Derudover bruges værktøjer som PageSpeed Insights, WebPageTest, DebugBear og forskellige overvågningsplatforme. De er nyttige, hvis du vil teste fra flere lokationer og sammenligne resultater over tid.
Ja, ofte meget. Cache reducerer den mængde arbejde, serveren skal udføre, før den kan sende et svar. Det gælder især sidecache og andre lag, der mindsker tunge opslag i backend.
Et CDN kan også sænke TTFB ved at levere indhold fra en server tættere på brugeren. Det er især nyttigt, hvis besøgende kommer fra flere regioner eller lande.