TTFB: Hvorfor Time To First Byte er vigtig for både SEO og LLM'er
Time To First Byte (TTFB) er en af de mest kritiske, men oversete, performance-metrics for websites. Mens de fleste fokuserer på side load time eller visual rendering, er TTFB den første indikator for, hvor responsivt dit site er – og det betyder noget både for søgemaskiner og AI-crawlere. Langsomme TTFB kan betyde, at AI-systemer crawler færre sider, prioriterer dit indhold lavere, eller helt opgiver at crawle dit site. Denne guide forklarer, hvad TTFB er, hvorfor det betyder noget, og hvordan du optimerer det.

TTFB: Derfor er Time To First Byte afgørende for både SEO og LLM'er
Time To First Byte (TTFB) er en af de mest kritiske, men ofte oversete, performance-parametre for websites. Mens de fleste fokuserer på indlæsningstid eller den visuelle rendering, er TTFB den første indikator på, hvor hurtigt dit site reagerer – og det betyder noget for både søgemaskiner og AI-crawlere. En langsom TTFB kan betyde, at AI-systemer crawler færre sider, nedprioriterer dit indhold eller helt opgiver at crawle din side. Denne guide forklarer, hvad TTFB er, hvorfor det er vigtigt, og hvordan du optimerer det.
Hvad er TTFB?
Time To First Byte (TTFB) er den tid, der går, fra en browser eller crawler sender en HTTP-anmodning, til den modtager den første byte data fra serveren.
Elementer i TTFB:
DNS-opslag — Tiden det tager at oversætte domænenavn til IP-adresse
Forbindelsestid — Tiden det tager at oprette en TCP-forbindelse
SSL/TLS-handshake — Tiden det tager at etablere en sikker HTTPS-forbindelse
Serverens behandlingstid — Den tid serveren bruger på at generere et svar
Netværksforsinkelse — Tiden det tager for den første byte at rejse tilbage
Formel:
TTFB vs. andre parametre
TTFB måler serverens svartid, før der overhovedet sendes noget indhold.
FCP (First Contentful Paint) måler, hvornår det første visuelle indhold renderes.
LCP (Largest Contentful Paint) måler, hvornår sidens primære element er indlæst.
TTFB sker altid først – det er selve fundamentet for alle andre load-parametre.
Hvorfor TTFB er afgørende for AI-crawlere
1. Crawler-budgetter
AI-crawlere (og søgemaskiner) har begrænset tid per site. Hvis din TTFB er langsom, crawler de færre sider, før deres tidsbudget er brugt op.
Eksempel:
Site A: TTFB = 200ms → Crawleren når at crawle 500 sider på 5 minutter
Site B: TTFB = 2000ms → Crawleren når kun at crawle 150 sider på 5 minutter
Site A får altså 3x mere crawl-dækning.
2. Prioritering af crawl
Crawlere prioriterer hurtige sites. Hvis din TTFB konsekvent er langsom, vil crawlere:
Komme på besøg sjældnere
Crawle færre sider per besøg
Prioritere dine konkurrenters sites
3. Datakvalitet
En lang TTFB kan føre til timeouts. Det betyder, at AI-systemet får ufuldstændig data eller helt giver op.
Googles retningslinjer:
God TTFB: < 600ms
Acceptabel TTFB: 600ms - 1200ms
Dårlig TTFB: > 1200ms
Det samme gælder for AI-crawlere.
Hvorfor TTFB også er vigtigt for SEO
Google har bekræftet, at TTFB indirekte er en ranking-faktor via Core Web Vitals (da det påvirker din LCP).
Effekt:
Langsom TTFB → Langsom LCP → Ringere ranking
Hurtig TTFB → Hurtig LCP → Bedre ranking
Mål din nuværende TTFB
Browser DevTools (Chrome)
Åbn Chrome DevTools (F12)
Gå til fanen Network
Genindlæs siden
Klik på den første anmodning (typisk dit HTML-dokument)
Se fanen Timing
Du vil se:
PageSpeed Insights
Gå til https://pagespeed.web.dev/
Indtast din URL
Se efter "Serverens svartid" under diagnosticering
WebPageTest
Gå til https://www.webpagetest.org/
Indtast din URL og vælg testlokation
Se efter "Time to First Byte" i resultaterne
WebPageTest viser også:
TTFB per anmodning (ikke kun for den første HTML)
Fordeling af DNS, Connect, SSL og Wait
Kommandolinje-test med curl
Python-script til bulk-test
Find ud af, hvorfor din TTFB er langsom
TTFB består af flere elementer. Find flaskehalsene her:
1. DNS-opslag (bør være < 20ms)
Problem: Langsom DNS-server.
Test:
Løsning:
Brug en hurtig DNS-udbyder (som f.eks. Cloudflare DNS eller Google DNS)
Aktivér DNS-prefetching:
2. Forbindelsestid (bør være < 50ms)
Problem: Geografisk afstand til serveren eller langsomt netværk.
Løsning:
Brug et Content Delivery Network (CDN) for at komme tættere på brugere og crawlere
Reducer antallet af forbindelser (HTTP/2 afhjælper dette)
3. SSL/TLS-handshake (bør være < 100ms)
Problem: Langsom SSL-forhandling.
Test:
Løsning:
Aktivér TLS 1.3 (giver hurtigere handshake)
Brug OCSP-stapling
Aktivér HTTP/2 eller HTTP/3
4. Serverens behandlingstid (bør være < 200ms)
Problem: Langsom backend eller tunge database-forespørgsler.
Dette er typisk den største flaskehals.
Sådan finder du fejlen:
Tjek serverlogs for langsomme anmodninger
Brug APM-værktøjer (f.eks. New Relic eller Datadog)
Analyser og optimer dine database-forespørgsler
Optimer serverens behandlingstid
Her kan du hente den absolut største forbedring.
1. Implementer caching
Server-side caching:
Brug Redis eller Memcached til at gemme database-resultater midlertidigt.
Eksempel (PHP med Redis):
Full-page caching:
Cache hele HTML-svar.
Nginx-eksempel:
2. Optimer database-forespørgsler
Problem: N+1 forespørgsler eller manglende indeks.
Find langsomme forespørgsler (MySQL):
Løsninger:
Tilføj indeks:
Brug query caching:
Optimer JOINs:
3. Opgrader dine serverressourcer
Tjek serverbelastningen:
Hvis belastningen konsekvent er høj (>80% CPU):
Opgrader din CPU
Tilføj mere RAM
Brug load balancing
4. Brug et CDN
Content Delivery Networks gemmer dit indhold på servere, der er geografisk tæt på dine brugere og crawlere.
Populære CDN-udbydere:
Cloudflare — Har en stærk gratis version, perfekt til små og mellemstore sites
AWS CloudFront — Ekstremt skalerbart
Fastly — Lynhurtigt, men mere teknisk krævende
BunnyCDN — Meget budgetvenligt
Sådan forbedrer et CDN din TTFB:
Uden CDN:
En bruger i USA besøger et site, der hostes i Europa
TTFB = 500ms (200ms netværksforsinkelse + 300ms serverbehandling)
Med CDN:
Brugeren i USA rammer en lokal CDN-kantserver i USA
TTFB = 150ms (20ms netværksforsinkelse + 130ms cache hit)
5. Aktivér Gzip- eller Brotli-komprimering
Komprimering gør svarstørrelsen mindre, hvilket forkorter overførselstiden.
Nginx-konfiguration:
Apache-konfiguration:
6. Begræns server-side processer
Minimer følgende:
Tunge beregninger ved hver anmodning
Eksterne API-kald
Fil-I/O-operationer
Eksempel (Python Flask):
7. Brug HTTP/2 or HTTP/3
HTTP/2 tillader multiplexing, hvilket mindsker overforbruget af forbindelser.
Aktivér HTTP/2 (Nginx):
Test om HTTP/2 er aktivt:
Optimer specifikt til AI-crawlere
1. Prioriter dine vigtigste sider
Sørg for, at dine absolut vigtigste sider (forside, nøgleprodukter, populære artikler) har den hurtigste TTFB.
Nginx: Separat cache til vigtige sider:
2. Identificer og optimer til crawlere
Server en cachet version direkte til crawlere:
3. Varm cachen op, før crawleren kommer
Hvis du ved, hvornår crawlere besøger dit site (f.eks. lige efter du har indsendt et sitemap), kan du varme din cache op på forhånd:
Overvåg din TTFB løbende
Sæt automatisk overvågning op
Pingdom:
Opret en profil på pingdom.com
Tilføj overvågning af dine URL'er
Sæt en alarmgrænse (f.eks. "alarm hvis TTFB > 800ms")
UptimeRobot:
Få gratis overvågning hvert 5. minut
Få besked direkte i din indbakke
Eget script (via cron-job):
Kør testen en gang i timen:
Målsætninger for TTFB
Googles anbefalinger
Godt: < 600ms
Kan forbedres: 600ms - 1200ms
Dårligt: > 1200ms
Anbefalinger til AI-crawlere
Fremragende: < 300ms (giver absolut højeste crawl-prioritet)
Godt: 300ms - 600ms (normal crawl-hastighed)
Acceptabelt: 600ms - 1000ms (lavere crawl-hastighed)
Dårligt: > 1000ms (risiko for ufuldstændig crawling)
Typiske TTFB-problemer og løsninger
Problem | Symptom | Løsning |
|---|---|---|
Manglende caching | TTFB > 1000ms på alle anmodninger | Implementer Redis/Memcached |
Langsom database | Høj TTFB på dynamiske sider | Tilføj indeks, optimer forespørgsler |
Intet CDN | Høj TTFB for international trafik | Aktivér Cloudflare eller AWS CloudFront |
Overbelastet server | TTFB stiger voldsomt under spidsbelastning | Opgrader serveren eller opsæt load balancing |
Uoptimeret kode | Ustabil og svingende TTFB | Analyser koden, fjern flaskehalse |
Eksterne API-kald | Høj og meget svingende TTFB | Cache API-svar, brug asynkrone kald |
Tjekliste til implementering
Brug denne tjekliste til at banke din TTFB i bund:
Mål din nuværende TTFB — Brug PageSpeed Insights eller WebPageTest
Find flaskehalsen — Skyldes det DNS, forbindelse, SSL eller serverbehandling?
Implementer server-side caching — Brug Redis/Memcached til databaseresultater
Aktivér full-page caching — Gælder statiske eller semi-statiske sider
Optimer database-forespørgsler — Tilføj indeks, fjern N+1-problemer
Aktivér Gzip/Brotli — Komprimer dine svar
Brug CDN — F.eks. Cloudflare, AWS CloudFront eller BunnyCDN
Aktivér HTTP/2 — Reducer overforbruget af forbindelser
Overvåg din TTFB — Sæt Pingdom eller egen overvågning op
Test med curl — Verificer at dine optimeringer virker
Konklusion
TTFB er en kritisk parameter for både din SEO og din synlighed i AI-søgninger. En langsom TTFB betyder færre crawled sider, lavere prioritering og i værste fald ufuldstændig data for AI-systemerne. De fleste sites kan løfte deres TTFB markant med caching (både server-side og full-page), database-optimering og et godt CDN.
Start med at måle din nuværende status, find den største flaskehals (ofte serverens behandlingstid), og få styr på din caching. For de fleste er det fuldt ud muligt at komme under 600ms med helt basal optimering, og helt under 300ms med et CDN og aggressiv caching.
Husk: TTFB er fundamentet – alle andre performance-parametre hviler på det. Optimer din TTFB først, så følger FCP og LCP naturligt med.