Indholdsfortegnelse
Når vi taler om hastighedsoptimering, ender samtalen ofte med billeder, komprimering, lazy loading og minificering af CSS og JavaScript. Det er alt sammen vigtigt. Men før noget af det overhovedet begynder at loade, ligger der en helt afgørende faktor, som mange overser: serverens reaktionstid. Time to First Byte (forkortet TTFB) er i praksis startskuddet for hele din hjemmeside.
TTFB måler den tid, der går fra en bruger sender en anmodning om en side, til browseren modtager det første byte data fra serveren. Det er ikke tiden til siden er færdig indlæst. Det er ikke tiden til første billede vises. Det er selve øjeblikket, hvor serveren begynder at svare.
Hvis det øjeblik trækker ud, starter hele oplevelsen langsomt.
Hvad sker der egentlig, når en side åbnes?
For at forstå betydningen af TTFB skal vi kigge på, hvad der teknisk sker, når en bruger indtaster en URL eller klikker på et link. Først skal browseren finde ud af, hvor serveren befinder sig. Det sker via et DNS-opslag, hvor domænenavnet oversættes til en IP-adresse. Hvis DNS-udbyderen er langsom eller geografisk langt væk, kan det allerede her koste værdifulde millisekunder.
Når IP-adressen er fundet, etableres der en TCP-forbindelse mellem browser og server. Det kræver flere netværksrunder, før forbindelsen er klar. Derefter følger TLS-forhandlingen, hvis forbindelsen er krypteret via HTTPS, hvilket den naturligvis bør være. Her etableres den sikre forbindelse, så data kan udveksles krypteret.
Først når disse trin er gennemført, kan selve HTTP-anmodningen sendes til serveren. Og her begynder den del, som i praksis ofte er den største flaskehals: serverens behandlingstid.
Hvis der er tale om en statisk HTML-side, kan serveren næsten øjeblikkeligt sende dokumentet retur. Men de fleste moderne hjemmesider er dynamiske. De bygger indholdet i realtid. Det betyder, at serveren skal hente data fra databasen, eksekvere backend-kode, sammensætte templates, måske kommunikere med eksterne systemer og først derefter generere det HTML-dokument, som sendes tilbage til browseren.
Hvorfor TTFB er afgørende for brugeroplevelsen
Brugere tænker ikke i millisekunder, men de reagerer på dem. Når man klikker på et link, forventer man, at noget sker med det samme. Hvis skærmen står stille i et sekund eller to, opstår der usikkerhed. Er siden i gang med at loade? Er der sket en fejl? Skal man prøve igen?
Den oplevede ventetid starter allerede før første pixel vises. En høj TTFB betyder, at browseren ikke kan begynde at vise noget indhold. HTML’en er ikke ankommet, og uden HTML kan resten af ressourcerne ikke hentes.
Selv hvis resten af siden loader hurtigt, vil en langsom start påvirke den samlede oplevelse. Det er her, den psykologiske faktor spiller ind. Hurtig respons skaber en følelse af effektivitet og kvalitet. Langsom respons skaber friktion.
For webshops og leadgenererende sites har det direkte forretningsmæssige konsekvenser. Studier har igen og igen vist, at selv små forsinkelser påvirker konverteringsraten. Ikke nødvendigvis dramatisk på den enkelte session, men over tid og i skala bliver det mærkbart.
Indeholder TTFB redirects?
Ja, og det er en detalje, mange overser. Hvis en bruger først lander på en URL, der videresender til en anden, tilføjes der ekstra netværksrunder, før det egentlige dokument begynder at loade. En klassisk konfiguration kan være, at http videresender til https, og at non-www videresender til www eller omvendt. Hver redirect kræver en ny anmodning og et nyt svar fra serveren.
Selvom den enkelte redirect måske kun koster et par hundrede millisekunder, kan flere redirects i kæde hurtigt blive mærkbare. Derfor bør redirect-strukturen være enkel og konsekvent. Ideelt set bør brugeren ramme den endelige URL i første forsøg.
Hvad betyder “Full TTFB”?
Når man taler om Full TTFB, inkluderer det hele forløbet fra browserens første netværksaktivitet til første byte er modtaget. Det betyder, at både DNS, TCP, TLS, redirects og selve serverens behandlingstid er medregnet.
Det er vigtigt at forstå denne helhed, fordi TTFB ikke altid udelukkende er et backend-problem. Geografisk afstand, netværkskvalitet og serverplacering spiller også ind. Hvis din målgruppe primært er i Danmark, men din server står i USA, vil latenstiden naturligt være højere.
Men i mange tilfælde er det stadig serverens interne behandling, der fylder mest.
TTFB og SEO
TTFB er ikke officielt en Core Web Vital, men den påvirker dem indirekte. Largest Contentful Paint, som er en af de centrale Core Web Vitals, kan først ske, når HTML-dokumentet begynder at loade. Hvis TTFB er høj, skubbes LCP tilsvarende.
Derudover påvirker serverens svartid Googles crawl-effektivitet. Søgemaskiner arbejder med et crawl budget, som bestemmer, hvor mange sider de gennemgår inden for en given tidsramme. En hurtigere server betyder, at Google kan crawle flere sider på samme tid. For større websites kan det have betydning for indeksering og synlighed.
TTFB er derfor ikke en isoleret rankingfaktor, men en del af det tekniske fundament, der understøtter god SEO.
Hvad er en god TTFB?
Der findes ikke ét universelt tal, der gælder for alle løsninger. En simpel statisk side kan levere TTFB på under 100 millisekunder. En kompleks webshop med dynamisk indhold vil naturligt ligge højere.
Som generel rettesnor bør Full TTFB ligge under 800 millisekunder. Ambitiøse og veloptimerede løsninger ligger ofte mellem 150 og 400 millisekunder. Hvis tallet overstiger ét sekund, bør man begynde at analysere årsagen. Hvis det overstiger to sekunder, er der næsten altid et strukturelt problem.
Det afgørende er dog ikke kun gennemsnittet, men stabiliteten. Hvis TTFB varierer kraftigt ved spidsbelastning, indikerer det kapacitetsproblemer.
Hvordan forbedrer man sin TTFB?
Forbedring af TTFB handler sjældent om én enkelt indstilling. Det handler om arkitektur, infrastruktur og kodekvalitet.
Serverens CPU-forbrug spiller en stor rolle. Hvis backend-koden er ineffektiv, eller hvis der kører tunge processer ved hver anmodning, stiger behandlingstiden. Profilering af applikationen kan afsløre, hvor tiden bruges.
Databasen er en anden klassisk flaskehals. Manglende indeksering, tunge JOIN-forespørgsler eller unødvendigt store datamængder kan trække responstiden op. Ofte kan målrettet databaseoptimering reducere behandlingstiden markant.
Caching er et af de mest effektive værktøjer. Full-page caching betyder, at HTML’en ikke skal genereres fra bunden ved hver forespørgsel. Object caching kan reducere belastningen på databasen. Et CDN kan bringe indholdet tættere på brugeren og reducere netværkslatenstiden. Når caching implementeres korrekt i flere lag, kan TTFB falde dramatisk.
Tredjepartsintegrationer bør også vurderes kritisk. Hvis serveren venter på svar fra et eksternt system, før HTML’en sendes, bliver brugeren afhængig af tredjepartens performance. Her kan asynkrone kald eller caching af API-responser være løsningen.
I cloudmiljøer kan såkaldte “cold starts” også påvirke TTFB. Hvis en instans skal startes fra bunden ved lav trafik, kan det give pludselige spikes i svartiden. Korrekt konfiguration og warm-up-strategier kan afhjælpe dette.
Måling og overvågning
TTFB bør måles både syntetisk og via real user data. Syntetiske tests giver kontrollerede målinger, mens real user monitoring viser, hvordan faktiske brugere oplever performance under forskellige netværksforhold.
Hastighedsoptimering er ikke en engangsopgave. Nye integrationer, kampagner eller systemopdateringer kan ændre serverens belastning. Derfor bør TTFB overvåges løbende, så afvigelser opdages tidligt.
Man kan bl.a. Måle denne i Google PageSpeed Insights
