Artikel

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.

Sidst opdateret:

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.

Del af: Server og HTTP-responser — Statuskoder, redirects og caching →

Andre artikler i samme emne

Relaterede begreber

Emne Web Performance — Core Web Vitals og teknisk hastighed Web performance er en direkte SEO-rankingfaktor — Core Web Vitals, hastighed og responsivt design påvirker din placering. Artikel Core Web Vitals — LCP, INP og CLS forklaret Core Web Vitals er Googles tre performance-signaler: LCP (hastighed), INP (interaktivitet) og CLS (layout-stabilitet) — alle er rankingfaktorer. Artikel LCP-optimering — Sådan forbedrer du Largest Contentful Paint LCP-optimering handler om at identificere LCP-elementet og fjerne det der forsinker dets indlæsning — billeder, TTFB og render-blocking ressourcer er de hyppigste syndere. Emne Server og HTTP-responser — Statuskoder, redirects og caching HTTP-statuskoder, redirects og caching er serverresponser der direkte påvirker Googlebots crawling og brugernes oplevelse. Artikel Caching — Browser-caching og server-caching til SEO Caching gemmer ressourcer lokalt så de ikke hentes igen — korrekt cache-opsætning reducerer load-tider og forbedrer Core Web Vitals. Artikel Komprimering — Gzip, Brotli og hurtigere sideindlæsning Komprimering reducerer filstørrelser med 60-80% under overførsel — Gzip og Brotli er server-side komprimering der forbedrer TTFB. Artikel CDN — Content Delivery Network og SEO Et CDN sætter kopier af dit indhold på servere globalt tæt på brugerne. Det reducerer TTFB, forbedrer LCP og aflaster din origin-server.

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

Kode — Webkode og teknisk SEO
Server og HTTP-responser — Statuskoder, redirects og caching
TTFB og hosting — Server response time og SEO