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: 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.
Hvad er TTFB?
Time To First Byte (TTFB) er tiden fra en browser/crawler sender en HTTP-request, til den modtager den første byte af data fra serveren.
Komponenter af TTFB:
DNS lookup – Tid til at oversætte domænenavn til IP-adresse
Connection time – Tid til at etablere TCP-forbindelse
SSL/TLS handshake – Tid til at etablere HTTPS-forbindelse (hvis applicable)
Server processing time – Tid serveren bruger på at generere response
Network latency – Tid det tager første byte at rejse tilbage
Formel:
TTFB vs. andre metrics
TTFB måler server-responsivitet før noget indhold er sendt.
FCP (First Contentful Paint) måler hvornår første visuelt indhold renders.
LCP (Largest Contentful Paint) måler hvornår hovedelementet er loaded.
TTFB sker først – det er fundamentet for alle andre load metrics.
Hvorfor TTFB betyder noget for AI-crawlere
1. Crawler-budgets
AI-crawlere (og søgemaskiner) har begrænset tid per site. Hvis din TTFB er langsom, crawler de færre sider inden deres tidsbudget er brugt op.
Eksempel:
Site A: TTFB = 200ms → Crawler får crawled 500 sider på 5 minutter
Site B: TTFB = 2000ms → Crawler får kun crawled 150 sider på 5 minutter
Site A får 3x mere crawl-coverage.
2. Crawl-prioritering
Crawlere prioriterer hurtige sites. Hvis dit TTFB er konsekvent langsomt, vil crawlere:
Returnere sjældnere
Crawl færre sider per besøg
Prioritere konkurrenters sites
3. Data quality
Lang TTFB kan resultere i timeouts. AI får incomplete data eller opgiver helt.
Google's guidance:
God TTFB: < 600ms
Okay TTFB: 600ms - 1200ms
Dårlig TTFB: > 1200ms
For AI-crawlere gælder det samme.
Hvorfor TTFB også betyder noget for SEO
Google har bekræftet, at TTFB er en ranking-faktor via Core Web Vitals indirekte (det påvirker LCP).
Impact:
Langsom TTFB → Langsom LCP → Dårligere ranking
Hurtig TTFB → Hurtig LCP → Bedre ranking
Mål dit nuværende TTFB
Browser DevTools (Chrome)
Åbn Chrome DevTools (F12)
Gå til Network tab
Refresh siden
Klik på den første request (typisk dit HTML-dokument)
TTFB opdeles i flere komponenter. Identificér bottlenecks:
1. DNS Lookup (bør være < 20ms)
Problem: Langsom DNS resolver.
Test:
Løsning:
Brug hurtig DNS provider (Cloudflare DNS, Google DNS)
Enable DNS prefetching:
<linkrel="dns-prefetch"href="//ditwebsite.dk">
<linkrel="dns-prefetch"href="//ditwebsite.dk">
<linkrel="dns-prefetch"href="//ditwebsite.dk">
2. Connection time (bør være < 50ms)
Problem: Geografisk distance til server eller langsom netværk.
Løsning:
Brug Content Delivery Network (CDN) for at være tættere på users/crawlers
Reduce number of connections (HTTP/2 helps)
3. SSL/TLS handshake (bør være < 100ms)
Problem: Langsom SSL negotiation.
Test:
openssl s_time -connect ditwebsite.dk:443 -www
openssl s_time -connect ditwebsite.dk:443 -www
openssl s_time -connect ditwebsite.dk:443 -www
Løsning:
Enable TLS 1.3 (faster handshake)
Use OCSP stapling
Enable HTTP/2 eller HTTP/3
4. Server processing time (bør være < 200ms)
Problem: Langsom backend eller database queries.
Dette er typisk den største bottleneck.
Identificér:
Tjek server logs for slow requests
Brug APM tools (New Relic, Datadog)
Profile database queries
Optimér server processing time
Dette er hvor du får størst impact.
1. Implementer caching
Server-side caching:
Brug Redis eller Memcached til at cache database-results.
Eksempel (PHP med Redis):
<?php
$redis = new Redis();$redis->connect('127.0.0.1',6379);$cache_key = 'homepage_data';$data = $redis->get($cache_key);if(!$data){// Data not in cache, fetch from database$data = fetch_from_database();$redis->setex($cache_key,3600,serialize($data));// Cache for 1 hour}else{$data = unserialize($data);}echojson_encode($data);
<?php
$redis = new Redis();$redis->connect('127.0.0.1',6379);$cache_key = 'homepage_data';$data = $redis->get($cache_key);if(!$data){// Data not in cache, fetch from database$data = fetch_from_database();$redis->setex($cache_key,3600,serialize($data));// Cache for 1 hour}else{$data = unserialize($data);}echojson_encode($data);
<?php
$redis = new Redis();$redis->connect('127.0.0.1',6379);$cache_key = 'homepage_data';$data = $redis->get($cache_key);if(!$data){// Data not in cache, fetch from database$data = fetch_from_database();$redis->setex($cache_key,3600,serialize($data));// Cache for 1 hour}else{$data = unserialize($data);}echojson_encode($data);
-- Bad: Multiple joins without proper indexesSELECT * FROM orders
JOIN users ON orders.user_id = users.id
JOIN products ON orders.product_id = products.id
WHERE users.country = 'DK';
-- Good: Add composite indexesCREATE INDEX idx_user_country ON users(country, id);
CREATE INDEX idx_product_id ON products(id)
-- Bad: Multiple joins without proper indexesSELECT * FROM orders
JOIN users ON orders.user_id = users.id
JOIN products ON orders.product_id = products.id
WHERE users.country = 'DK';
-- Good: Add composite indexesCREATE INDEX idx_user_country ON users(country, id);
CREATE INDEX idx_product_id ON products(id)
-- Bad: Multiple joins without proper indexesSELECT * FROM orders
JOIN users ON orders.user_id = users.id
JOIN products ON orders.product_id = products.id
WHERE users.country = 'DK';
-- Good: Add composite indexesCREATE INDEX idx_user_country ON users(country, id);
CREATE INDEX idx_product_id ON products(id)
3. Upgrade server resources
Check server load:
top# Se CPU usage og memory usage
htop
# More user-friendly alternative
top# Se CPU usage og memory usage
htop
# More user-friendly alternative
top# Se CPU usage og memory usage
htop
# More user-friendly alternative
If consistently high (>80% CPU):
Upgrade CPU
Add more RAM
Use load balancing
4. Use a CDN
Content Delivery Networks cache content geographically close to users/crawlers.
Popular CDNs:
Cloudflare – Free tier available, excellent for small-medium sites
AWS CloudFront – Highly scalable
Fastly – Great performance, more technical
BunnyCDN – Budget-friendly
How CDN improves TTFB:
Without CDN:
User in US requests site hosted in Europe
TTFB = 500ms (200ms network latency + 300ms server processing)
Use CDN – Cloudflare, AWS CloudFront, eller BunnyCDN
Enable HTTP/2 – Reduce connection overhead
Monitor TTFB – Setup Pingdom eller custom monitoring
Test med curl – Verificér forbedringer
Konklusion
TTFB er en kritisk metric både for SEO og AI-synlighed. Langsom TTFB betyder færre sider crawled, lavere prioritering, og potentielt incomplete data til AI-systemer. De fleste sites kan forbedre TTFB med caching (server-side og full-page), database-optimering, og brug af CDN.
Start med at måle dit nuværende TTFB, identificér den største bottleneck (typisk server processing), og implementer caching. For de fleste sites er det muligt at komme under 600ms med basic optimering, og under 300ms med CDN og aggressive caching.
Husk: TTFB er fundamentet – alle andre performance metrics afhænger af det. Optimer TTFB først, derefter FCP og LCP.