Hvad er TTFB? Tallet, alt andet venter på

Kort svar: TTFB (Time To First Byte) er tiden fra browseren beder om en side, til den første byte af svaret ankommer – summen af DNS-opslag, forbindelse, TLS-håndtryk og frem for alt serverens behandlingstid. Den er gulvet under alle andre hastighedstal, fordi intet kan vises, før første byte er fremme. Google kalder en TTFB på højst 0,8 sekunder god, men en cachet WordPress-side bør ligge et godt stykke under. For WordPress er høj TTFB oftest manglende servercache eller en overbelastet server – sjældnere temaet.

Fagligt gennemgået: 2. oktober 2026

Når en side føles langsom, er TTFB det første tal, du bør kende. Er serveren lang tid om at svare, hjælper billedoptimering og JavaScript-tricks kun lidt, fordi browseren står og venter, før den overhovedet kan begynde.

Her får du, hvad tallet består af, hvordan du måler det rigtigt, hvordan du læser målingen, og i hvilken rækkefølge du sænker det.

Hvad tæller med i TTFB?

Fire poster lægges sammen:

• DNS-opslag: hvilken IP-adresse har domænet?
• TCP-forbindelse: browseren og serveren etablerer kontakt.
• TLS-håndtryk: krypteringen forhandles på plads.
• Serverens behandlingstid: for WordPress betyder det PHP og database – medmindre en cache svarer i stedet.

De tre første er typisk få titusinder til lidt over hundrede millisekunder tilsammen og afhænger især af afstanden til serveren. Den fjerde kan svinge fra få millisekunder ved et cache-hit til flere sekunder for en tung, ucachet side på en presset server. Derfor er TTFB-optimering i praksis næsten altid server- og cachearbejde.

Redirects tæller også med. Sender http:// videre til https:// og derefter til www, betaler den besøgende for flere runder, før den rigtige side overhovedet bliver bedt om. Se guiden om www eller uden www, hvis du har en redirectkæde.

Hvad er en god TTFB?

TTFB	Vurdering	Hvad det typisk betyder
Højst 0,8 sekunder	God efter Googles vejledning på web.dev	Acceptabelt udgangspunkt for LCP
0,8–1,8 sekunder	Bør forbedres	Siden bygges ofte af PHP uden cache, eller serveren er presset
Over 1,8 sekunder	Dårlig	Næsten altid et server-, cache- eller databaseproblem

Grænserne er bevidst rummelige, fordi de skal dække alle typer sites og forbindelser. Ligger dine cachede sider tæt på 0,8 sekunder, er der stadig meget at hente: tiden lægges direkte oven i LCP.

Sådan måler du

Mål altid flere sider, ikke kun forsiden. Forsiden ligger stort set altid varm i cachen, mens den dybe produktside, en kunde lander på fra Google, kan være kold. Mål også både første og andet kald på samme URL: falder tiden markant på kald nummer to, virker cachen, men for få sider ligger i den.

curl -o /dev/null -s -w "dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n" https://ditdomæne.dk/en-side/

I browseren finder du samme tal i PageSpeed Insights under serverens svartid og i udviklerværktøjernes Netværk-fane, hvor dokumentets timing viser ventetiden. Feltdata i Search Console og CrUX viser, hvad rigtige besøgende oplever over tid.

Sådan læser du tallene fra curl

Kommandoen beder curl om at skrive fem tidsstempler, og forskellen mellem dem er diagnosen. Tallene er kumulative, så du trækker dem fra hinanden:

• time_namelookup er DNS. Er den høj, kan navneserverne være langsomme – eller TTL’en er sat så lavt, at opslag sjældent kan genbruges.
• time_connect minus namelookup er afstanden til serveren. En server i Europa svarer typisk danske besøgende hurtigt; en server på et andet kontinent lægger mærkbart mere oveni.
• time_appconnect minus connect er TLS-håndtrykket, som TLS 1.3 og HTTP/3 gør kortere.
• time_starttransfer minus appconnect er serverens behandlingstid – det tal, cachen og hostingen styrer.

Er det sidste tal lavt på forsiden og højt på en produktside, ved du præcis, hvor problemet er: den ene side er cachet, den anden bygges af PHP hver gang. Tjek cache-headeren (fx x-litespeed-cache) i samme svar for at bekræfte det.

Mål fra det sted, dine kunder er. En måling fra serveren selv eller fra samme datacenter udelader afstanden og ser altid flot ud. Et værktøj med målepunkter i flere lande – eller blot din mobil på mobilnettet – giver det ærlige tal.

Hvad betyder det for dit site?

TTFB sætter gulvet for Core Web Vitals, påvirker, hvor mange sider Google crawler, og er blevet ekstra vigtig, fordi AI-søgetjenesters hentere opgiver langsomme sider. Når tallet er for højt, er rækkefølgen:

1. Få servercache til at dække de offentlige sider – og undersøg, hvorfor en side eventuelt ikke caches.
2. Fjern unødige redirects før den rigtige side.
3. Tjek om serveren har luft: CPU, RAM og ledige PHP-processer – eller om sitet er vokset ud af planen.
4. Jagt langsomme databasekald med Query Monitor, og ryd op i autoload-data.
5. Overvej objektcache (Redis) til sider, der ikke kan sidecaches.

Hosting med LiteSpeed og NVMe-lagring – som hos Hostious – hæver grundniveauet for de første trin, men et plugin, der laver hundredvis af databasekald pr. sidevisning, skal stadig findes og rettes.

TTFB for indloggede brugere og i kassen

Sidecachen hjælper kun anonyme besøgende. Så snart nogen er logget ind, har varer i kurven eller står i kassen, bygges siden af PHP hver gang – og det er her, en langsom server afsløres. En webshop kan have lav TTFB på produktsiderne og flere gange højere i kassen, og det er kassen, der koster ordrer.

Tre ting hjælper:

• en objektcache (Redis), så databasens opslag ikke gentages – på Hostious understøttes Redis fra WP StartUp og aktiveres pr. site
• nok PHP-processer, så kunder ikke står i kø efter en ledig proces
• færre kald til eksterne tjenester i kassen (fragtberegning, valutakurser, anbefalinger), som hver lægger deres egen ventetid oveni

Mål derfor altid TTFB på kurv og kasse særskilt – med en vare i kurven – når du vurderer en webshop. Guiden om langsom checkout i WooCommerce går i dybden.

Hvad Google og AI-hentere gør med tallet

Google bruger ikke TTFB som selvstændig rangeringsfaktor, men Core Web Vitals indgår i Googles vurdering af sideoplevelsen – og LCP kan aldrig blive hurtigere end TTFB plus rendering. En TTFB på over et sekund gør det meget svært at bestå LCP-grænsen på 2,5 sekunder på mobil, uanset hvor optimeret temaet er.

Search Console viser under Indstillinger → Crawlstatistik den gennemsnitlige svartid, Googlebot oplever. Stiger den, kan Google vælge at crawle færre sider om dagen. AI-tjenesternes hentere har også korte tidsgrænser, så en side, der er flere sekunder om at svare, risikerer ikke at blive citeret. Et lavt, stabilt TTFB er med andre ord en forudsætning for at blive fundet begge steder.

Læs også

• Ordbog: Hosting-ordbogen
• Hvad er cache? Lagene bag et hurtigt WordPress-site
• Høj TTFB i WordPress: cache, PHP, database eller origin?
• Core Web Vitals-rapporten i Search Console
• Hub: WordPress performance og cache
• WordPress hosting hos Hostious – LiteSpeed og NVMe, Redis fra WP StartUp og servere i Europa

Ofte stillede spørgsmål om TTFB

Er TTFB det samme som sidens hastighed?

Nej, det er starttiden. Derefter kommer download, rendering, billeder og scripts. Men fordi alt andet venter på første byte, mærkes høj TTFB på alt – og lav TTFB gør resten af optimeringen synlig.

Hvorfor er min TTFB fin i test men dårlig i Search Console?

Fordi test ofte rammer varme, cachede sider, mens rigtige besøgende også rammer kolde. Feltdata dækker begge dele. Løsningen er højere cachedækning og længere levetider, ikke flere tests af forsiden.

Hjælper et CDN på TTFB?

På statiske filer og kant-cachet HTML, ja – især for fjerne besøgende. På dynamiske sider, der stadig skal bygges på origin, flytter det lidt eller intet. Dér er servercache og serverkraft svaret.

Hvorfor er TTFB høj i kassen, men lav på produktsiderne?

Fordi kassen aldrig sidecaches. Den bygges af PHP ved hvert besøg og kalder ofte eksterne tjenester. Objektcache, nok PHP-processer og færre eksterne kald i kassen er det, der sænker tallet.

Er TTFB en rangeringsfaktor hos Google?

Ikke direkte, men Core Web Vitals indgår i vurderingen af sideoplevelsen, og LCP kan aldrig blive bedre end TTFB plus rendering. En høj TTFB kan også sænke Googles crawltempo og få AI-hentere til at opgive siden.