TTFB og hosting — Server response time og SEO
TTFB er den tid serveren bruger på at svare — og en direkte komponent i LCP. Hosting, caching og CDN er de tre primære håndtag.
TTFB (Time to First Byte) er den tid der går fra en HTTP-request sendes til serveren returnerer den første byte af svaret. Det er det fundament al web performance bygger på — og en direkte komponent i LCP. En server der er langsom til at svare forsinker hele sideindlæsningen, uanset hvor optimeret resten af koden er.
Hvad TTFB består af
TTFB er summen af fire komponenter:
For det første DNS-opslag — konvertering af domænenavn til IP-adresse. Typisk 10-100ms. Preconnect og DNS-prefetch reducerer dette.
For det andet TCP-forbindelse — etablering af forbindelsen til serveren. Afhænger af geografisk afstand.
For det tredje TLS-håndtryk — krypteringsforhandling for HTTPS. Typisk 50-150ms. HTTP/2 og HTTP/3 amortiserer dette over multiple requests.
Til sidst serverprocessering — den tid serveren bruger på at generere HTML-svaret. Dette er det vigtigste håndtag.
Serverprocessering — den primære kilde til høj TTFB
Serverprocesseringstiden er høj af tre årsager:
Langsome database-queries. Dynamiske sider der henter data fra en database er kun så hurtige som den langsomste query. Indeks på hyppigt søgte kolonner, query-optimering og database-caching reducerer dette.
Manglende server-side caching. Hvis serveren genererer HTML fra bunden ved hvert request, er TTFB lig med fuld genereringstid. Med server-side caching (f.eks. full-page cache i WordPress eller SSG i Astro) serveres en pre-genereret HTML-fil — TTFB falder til få millisekunder.
Langsom hosting. Delt hosting på overbelastede servere giver høj baseline-TTFB uanset optimering. VPS eller dedikeret hosting med tilstrækkelige ressourcer er forudsætningen for lav TTFB.
CDN — geografisk distribution
Et CDN (Content Delivery Network) er et netværk af servere spredt geografisk. Statisk indhold — billeder, CSS, JavaScript, og med edge caching: hele HTML-sider — serveres fra den server der er nærmest brugeren.
En dansksproget side hostet i Danmark serveres til en dansk bruger fra 10-30ms afstand. Samme side serveret til en bruger i Australien uden CDN kan have 200-300ms netværkslatency alene.
For sites der primært har lokalt publikum er CDN-gevinsten på TTFB moderat. For internationale sites er CDN afgørende.
Statisk site generation (SSG) som TTFB-løsning
Astro, Next.js (static export), Hugo og tilsvarende frameworks pre-bygger alle sider som statiske HTML-filer ved deployment. Der er ingen serverprocessering ved request — serveren sender en eksisterende fil.
TTFB for statisk genererede sider er typisk 20-50ms fra en moderne hosting-udbyder. Det er den mest effektive tilgang til lavt TTFB for indholdsbaserede sites.
Måling af TTFB
PageSpeed Insights viser TTFB under “Server Response Time” i diagnostics-sektionen.
WebPageTest giver detaljeret waterfall-diagram med TTFB breakdowns per request og testmuligheder fra specifikke geografier.
Google Search Console viser ikke TTFB direkte, men Core Web Vitals-rapporten indikerer LCP-problemer der ofte skyldes høj TTFB.
Sidst opdateret: marts 2026. Denne artikel er en del af Stegger.dk’s SEO-ordbog. → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.
Andre artikler i samme emne
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- Video performance — Lazy loading, formater og indlæsningsstrategi
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning
Ofte stillede spørgsmål
- Hvad er et godt TTFB-tal?
- Google anbefaler TTFB under 800ms. Under 200ms er fremragende. Field data fra CrUX viser TTFB for rigtige brugere — lab data fra Lighthouse kan give et misvisende lavt tal hvis testen køres fra en server tæt på dit origin. Mål altid TTFB fra den geografi dine brugere befinder sig i.
- Hvad er forskellen på TTFB og LCP?
- TTFB er serverens responstid — tiden fra request til første byte af HTML. LCP er hvornår det største synlige element er indlæst — det inkluderer TTFB plus download-tid for HTML, CSS, JavaScript og selve LCP-ressourcen (typisk et billede). TTFB er en komponent i LCP: forbedrer du TTFB, forbedrer du LCP direkte.
- Hjælper et CDN altid på TTFB?
- CDN hjælper markant på TTFB for statisk indhold (billeder, CSS, JS) der caches på edge-servere tæt på brugeren. For dynamisk indhold (sider der genereres per request fra en database) reducerer CDN TTFB kun hvis du bruger edge caching eller edge computing. Standard CDN-opsætning forbedrer primært statiske ressourcer.
- Hvad er edge caching og hvad er det bedre end server-side caching?
- Edge caching lagrer HTML-svar på CDN-edge-nodes tæt på brugerne frem for kun på origin-serveren. For en dansksproget side hostet i Frankfurt vil en bruger i Danmark med edge caching modtage svaret fra en dansk eller nordeuropæisk edge-node frem for fra Frankfurt. Det reducerer TTFB markant for internationale brugere. Cloudflare Pages, Vercel og Netlify anvender edge caching som standard for statisk genererede sites.
- Hvad er det hurtigste hostingsetup for lavest mulig TTFB?
- Det hurtigste setup er statisk genererede sider (SSG med Astro, Next.js eller Hugo) deployet til et globalt CDN med edge-distribution (Cloudflare Pages, Vercel, Netlify). TTFB på 20-50ms fra edge er opnåeligt. For dynamiske sites er edge computing (Cloudflare Workers, Vercel Edge Functions) næstbedst, fulgt af server-side rendering med aggressiv full-page caching på en geografisk nær server. Delt hosting uden caching er det langsomste alternativ og bør undgås for SEO-prioriterede sites.
Placering i ordbogen
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- Video performance — Lazy loading, formater og indlæsningsstrategi
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning