Hvad handler det om?
TTFB er et tidligt signal: hvis serveren svarer langsomt, starter alt andet senere.
TTFB dækker over hele “første fase” af en sidevisning:
- DNS/connection/TLS (forbindelsen etableres)
- request rammer serveren (og evt. origin)
- serveren genererer svaret (app, database, templates)
- første byte sendes tilbage
Det betyder, at TTFB både kan være et netværksproblem (afstand) og et server-/backendproblem (lang rendering).
Hvilken indflydelse har TTFB?
Når TTFB er høj, bliver alt andet automatisk skubbet:
- HTML kommer sent
- browseren kan først senere discover’e CSS/JS/billeder
- LCP bliver ofte dårligere, fordi LCP-ressourcen starter senere
På et content-site kan det især ramme:
- landingssider fra Google (kold cache, mange unikke URL’er)
- mobilbrugere på langsommere netværk
Hvornår blev TTFB “vigtigt”?
TTFB har eksisteret som begreb i lang tid, men er blevet mere synligt i takt med:
- Core Web Vitals (fordi LCP ofte bliver påvirket af TTFB)
- øget brug af CDN/edge caching
- frameworks og CMS’er der kan gøre server-rendering tung
TTFB er ikke en Core Web Vital i sig selv, men det er ofte en af de hurtigste “rodsager” at finde, når LCP er dårlig.
Hvordan måler man TTFB?
Du kan måle TTFB med:
- WebPageTest (waterfall viser tydeligt “Time to First Byte”)
- Chrome DevTools → Network (TTFB som “Waiting”/“TTFB”)
- PageSpeed Insights (indikatorer og hints)
- Server logs/APM (hvor tiden bruges på backend)
Når du måler, så prøv at skelne mellem:
- første besøg (kold cache)
- gentagne besøg (varm cache)
- forskellige geografier (edge vs origin)
Typiske årsager
- Ingen caching (eller cache miss)
- Langsom backend/DB
- Lang afstand til server (ingen CDN/edge cache)
Typiske forbedringer
- Page cache / edge cache
- Optimer DB queries og plugins
- CDN og korrekt cache-control
Konkrete optimeringer (i prioriteret rækkefølge)
1) Få HTML i cache (page cache)
Hvis dit site kan levere HTML fra cache, er TTFB ofte det sted hvor du får størst effekt.
- server-side page cache (fx LiteSpeed cache, reverse proxy cache)
- undgå cache-busting cookies på offentlige sider
- cache pr. URL og vær opmærksom på variationer (mobil/desktop, sprog, login)
2) Edge cache via CDN (hvis relevant)
Et CDN kan reducere latenstid ved at servere fra edge tæt på brugeren.
- edge caching af HTML er stærkt på content-sites
- sørg for korrekt cache-control og purge-strategi
3) Backend og database
Hvis HTML ikke kan caches (eller hvis du har mange cache misses), skal backend være hurtig.
Praktisk:
- find langsomme endpoints og queries
- fjern tunge plugins/moduler på kritiske sider
- optimer serverressourcer (CPU/RAM) hvis den er presset
4) Reducér “arbejde før output”
Hvis din applikation bygger alt dynamisk for hver request, kan TTFB vokse.
Praktisk:
- precompute hvor det giver mening
- undgå dyre API-kald under server-rendering
- minimer antal templates/partials der renderes for “above the fold”
Tjekliste
- HTML kan caches på de vigtigste landingssider
- CDN/edge er korrekt sat op (hvis brugt)
- Database og backend er profileret for flaskehalse
- Cache-control er sat for assets og HTML efter behov
FAQ
Kan TTFB være lav, men siden stadig føles langsom?
Ja. TTFB er kun den første del af kæden.
Hvis CSS/JS er render-blocking, hvis hero-billedet er tungt eller opdages sent, eller hvis der er meget CPU-arbejde før første paint, kan LCP stadig være høj – selv med lav TTFB.
Brug TTFB som “startsignal”: er den høj, starter alt sent. Er den lav, skal du typisk lede videre i rendering, billeder og JavaScript.
Skal man altid cache HTML for at forbedre TTFB?
På mange content-sites: ja, det er ofte det mest effektive greb.
Men det kræver at du kan cache sikkert: undgå cache-busting cookies på offentlige sider, hold `Vary` under kontrol, og sørg for en purge-/revalidation-strategi hvis indhold ændrer sig.
Hvis du har stærk personalisering (login, geo, A/B), kan HTML-cache stadig være muligt, men typisk med segmentering af cache keys eller bypass på bestemte sider.
Hvad er den mest almindelige årsag til høj TTFB i praksis?
Cache-miss + tung servergenerering.
Det ses tit som: første besøg (kold cache) har høj TTFB, mens gentagne besøg (varm cache) er hurtigere. Hvis begge er høje, er det ofte backend/DB, origin-latency eller et proxy-lag der bufferer/forsinker svaret.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
Forbedr TTFB med caching, edge cache og hurtigere serverrespons
Lær hvordan du reducerer TTFB med page cache, edge cache, korrekt cache strategi og bedre serverrespons på HTML.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
Sådan læser du en waterfall og finder flaskehalse i load
Lær at læse en waterfall korrekt og find problemer med TTFB, LCP, render blocking og tredjepart, så du kan prioritere den rigtige optimering.
Cache-Control forklaret: sådan bruger du caching til lavere TTFB
Lær hvordan Cache-Control påvirker HTML, CSS, JavaScript og billeder, og få en praktisk gennemgang af caching, TTFB og klassiske fejl.
