TTFB: Derfor er Time To First Byte afgørende for både SEO og LLM'er

TTFB: Derfor er Time To First Byte afgørende for både SEO og LLM'er

Time To First Byte (TTFB) er et af de vigtigste nøgletal for et websites hastighed – og et af de mest oversete. De fleste kigger på indlæsningstid eller visuel rendering, men TTFB er det første tegn på, hvor hurtigt dit site reagerer. 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 dit site. I denne guide kan du læse, 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:

1. DNS-opslag – Tiden det tager at oversætte domænenavn til IP-adresse
2. Forbindelsestid – Tiden det tager at oprette en TCP-forbindelse
3. SSL/TLS-handshake – Tiden det tager at etablere en sikker HTTPS-forbindelse
4. Serverens behandlingstid – Den tid serveren bruger på at generere et svar
5. Netværksforsinkelse – Tiden det tager for den første byte at rejse tilbage

Formel:

TTFB = DNS-opslag + Forbindelse + SSL-handshake + Serverbehandling + Netværksforsinkelse

TTFB og andre nøgletal

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 kommer først og er fundamentet for alle de andre nøgletal for indlæsning.

Derfor er TTFB afgørende for AI-crawlere

1. Crawler-budgetter

AI-crawlere (og søgemaskiner) har begrænset tid pr. site. Hvis din TTFB er langsom, crawler de færre sider, før deres tidsbudget er brugt op.

Eksempel:

• Site A: TTFB = 200 ms → Crawleren når at crawle 500 sider på 5 minutter
• Site B: TTFB = 2.000 ms → Crawleren når kun at crawle 150 sider på 5 minutter

Site A får altså tre gange så meget 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 pr. besøg
• Prioritere dine konkurrenters sites

3. Datakvalitet

En lang TTFB kan føre til timeouts. Så får AI-systemet ufuldstændige data eller giver helt op.

Googles retningslinjer:

• God TTFB: < 600 ms
• Acceptabel TTFB: 600–1.200 ms
• Dårlig TTFB: > 1.200 ms

Det samme gælder for AI-crawlere.

Derfor er TTFB også vigtig for SEO

TTFB er ikke selv en del af Core Web Vitals, men Google bruger det som et diagnostisk nøgletal. Og en langsom TTFB trækker din LCP ned, som er en af dem.

Effekt:

• Langsom TTFB → Langsom LCP → Ringere ranking
• Hurtig TTFB → Hurtig LCP → Bedre ranking

Mål din nuværende TTFB

Browser DevTools (Chrome)

1. Åbn Chrome DevTools (F12)
2. Gå til fanen Network
3. Genindlæs siden
4. Klik på den første anmodning (typisk dit HTML-dokument)
5. Se fanen Timing

Du vil se:

Queueing: 0.5ms
DNS-opslag: 15ms
Forbindelse oprettet: 45ms
SSL: 89ms
Anmodning sendt: 0.3ms
Waiting (TTFB): 456ms  <-- Dette er din TTFB
Download af indhold: 125ms

PageSpeed Insights

1. Gå til https://pagespeed.web.dev/
2. Indtast din URL
3. Se efter serverens svartid (”Server response time”) under diagnosticeringen

WebPageTest

1. Gå til https://www.webpagetest.org/
2. Indtast din URL, og vælg testlokation
3. Se efter ”Time to First Byte” i resultaterne

WebPageTest viser også:

• TTFB pr. anmodning (ikke kun for den første HTML)
• Opdelt i DNS, Connect, SSL og Wait

Kommandolinje-test med curl

# Mål TTFB
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nSSL: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://ditwebsite.dk/

# Output:
# DNS: 0.015s
# Connect: 0.045s
# SSL: 0.132s
# TTFB: 0.456s
# Total: 0.612s

Python-script til bulk-test

import requests
import time

def measure_ttfb(url):
    start = time.time()
    r = requests.get(url, stream=True)
    ttfb = time.time() - start
    return ttfb * 1000  # Konverter til millisekunder

urls = [
    "https://ditwebsite.dk/",
    "https://ditwebsite.dk/products/",
    "https://ditwebsite.dk/blog/"
]

for url in urls:
    ttfb = measure_ttfb(url)
    print(f"{url}: {ttfb:.2f}ms")

Find ud af, hvorfor din TTFB er langsom

TTFB består af flere elementer. Find flaskehalsene her:

1. DNS-opslag (bør være < 20 ms)

Problem: Langsom DNS-server.

Test:

dig ditwebsite.dk

Løsning:

• Brug en hurtig DNS-udbyder (fx Cloudflare DNS eller Google DNS)
• Aktivér DNS-prefetching:

<link rel="dns-prefetch" href="//ditwebsite.dk">

2. Forbindelsestid (bør være < 50 ms)

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 < 100 ms)

Problem: Langsom SSL-forhandling.

Test:

openssl s_time -connect ditwebsite.dk:443 -www /

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 < 200 ms)

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 (fx 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):

<?php
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

$cache_key = 'homepage_data';
$data = $redis->get($cache_key);

if (!$data) {
    // Data er ikke i cache, hent fra databasen
    $data = fetch_from_database();
    $redis->setex($cache_key, 3600, serialize($data));  // Cache i 1 time
} else {
    $data = unserialize($data);
}

echo json_encode($data);
?>

Full-page caching:

Cache hele HTML-svar.

Nginx-eksempel:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;

server {
    location / {
        proxy_cache my_cache;
        proxy_cache_valid 200 60m;
        proxy_cache_key "$scheme$request_method$host$request_uri";
        proxy_pass http://backend;
    }
}

2. Optimer database-forespørgsler

Problem: N+1-forespørgsler eller manglende indeks.

Find langsomme forespørgsler (MySQL):

-- Aktivér slow query log
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- Forespørgsler over 1 sekund

-- Vis langsomme forespørgsler
SELECT * FROM mysql.slow_log;

Løsninger:

• Tilføj indeks:

-- Før: Full table scan
SELECT * FROM products WHERE category = 'electronics';

-- Efter: Opret indeks
CREATE INDEX idx_category ON products(category);

• Brug query caching:

-- Aktivér query cache (MySQL 5.7)
SET GLOBAL query_cache_size = 67108864;  -- 64MB
SET GLOBAL query_cache_type = ON;

• Optimer JOINs:

-- Dårligt: Flere joins uden ordentlige indeks
SELECT * FROM orders
JOIN users ON orders.user_id = users.id
JOIN products ON orders.product_id = products.id
WHERE users.country = 'DK';

-- Godt: Tilføj sammensatte indeks
CREATE INDEX idx_user_country ON users(country, id);
CREATE INDEX idx_product_id ON products(id);

3. Opgrader dine serverressourcer

Tjek serverbelastningen:

top
# Se CPU- og hukommelsesforbrug

htop
# Mere brugervenligt alternativ

Hvis belastningen konsekvent er høj (over 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 = 500 ms (200 ms netværksforsinkelse + 300 ms serverbehandling)

Med CDN:

• Brugeren i USA rammer en lokal CDN-kantserver i USA
• TTFB = 150 ms (20 ms netværksforsinkelse + 130 ms cache hit)

5. Aktivér Gzip- eller Brotli-komprimering

Komprimering gør svarene mindre, så overførslen går hurtigere.

Nginx-konfiguration:

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
gzip_min_length 256;
gzip_comp_level 6;

# Endnu bedre: Brotli
brotli on;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Apache-konfiguration:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/json
</IfModule>

6. Begræns server-side processer

Minimer følgende:

• Tunge beregninger ved hver anmodning
• Eksterne API-kald
• Fil-I/O-operationer

Eksempel (Python Flask):

from flask import Flask, render_template
from functools import lru_cache
import requests

app = Flask(__name__)

# Dårligt: Eksternt API-kald ved hver eneste anmodning
@app.route('/weather')
def weather_bad():
    response = requests.get('https://api.weather.com/data')
    return render_template('weather.html', data=response.json())

# Godt: Cache det eksterne API-kald
@lru_cache(maxsize=128)
def fetch_weather_cached():
    response = requests.get('https://api.weather.com/data')
    return response.json()

@app.route('/weather')
def weather_good():
    data = fetch_weather_cached()
    return render_template('weather.html', data=data)

7. Brug HTTP/2 eller HTTP/3

HTTP/2 understøtter multiplexing og mindsker dermed overhead fra forbindelserne.

Aktivér HTTP/2 (Nginx):

server {
    listen 443 ssl http2;
    server_name ditwebsite.dk;
    # ... resten af konfigurationen
}

Test, om HTTP/2 er slået til:

curl -I --http2 https://ditwebsite.dk/
# Hold øje med "HTTP/2 200" i svaret

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:

location = / {
    proxy_cache_valid 200 120m;  # Cache forsiden i 2 timer
    proxy_pass http://backend;
}

location /products/ {
    proxy_cache_valid 200 60m;  # Cache produkter i 1 time
    proxy_pass http://backend;
}

2. Identificer og optimer til crawlere

Giv crawlere en cachet version:

<?php
$user_agent = $_SERVER['HTTP_USER_AGENT'];

$is_crawler = preg_match('/GPTBot|ClaudeBot|CCBot|Googlebot|bingbot/i', $user_agent);

if ($is_crawler) {
    // Server statisk cachet HTML
    echo file_get_contents('/cache/static_page.html');
} else {
    // Server dynamisk indhold
    include('dynamic_page.php');
}
?>

3. Varm cachen op, før crawleren kommer

Hvis du ved, hvornår crawlere besøger dit site (fx lige efter, at du har indsendt et sitemap), kan du varme din cache op på forhånd:

#!/bin/bash
# Varm cachen op ved at anmode om alle URL'er
while read url; do
  curl -s "$url" > /dev/null
done < urls.txt

Overvåg din TTFB løbende

Sæt automatisk overvågning op

Pingdom:

1. Opret en konto på pingdom.com
2. Tilføj overvågning af dine URL'er
3. Sæt en alarmgrænse (fx ”alarm, hvis TTFB > 800 ms”)

UptimeRobot:

1. Få gratis overvågning hvert 5. minut
2. Få besked direkte i din indbakke

Eget script (via cron-job):

#!/bin/bash
# Tjek TTFB og send alarm hvis > 1000ms
TTFB=$(curl -o /dev/null -s -w '%{time_starttransfer}' https://ditwebsite.dk/)
TTFB_MS=$(echo "$TTFB * 1000" | bc)

if (( $(echo "$TTFB_MS > 1000" | bc -l) )); then
  echo "TTFB for høj: ${TTFB_MS}ms" | mail -s "TTFB-alarm" admin@ditwebsite.dk
fi

Kør testen en gang i timen:

crontab -e
# Tilføj:
0 * * * * /path/to/ttfb_check.sh

Målsætninger for TTFB

Googles anbefalinger

• Godt: < 600 ms
• Kan forbedres: 600–1.200 ms
• Dårligt: > 1.200 ms

Anbefalinger til AI-crawlere

• Fremragende: < 300 ms (giver den højeste crawl-prioritet)
• Godt: 300–600 ms (normal crawl-hastighed)
• Acceptabelt: 600–1.000 ms (lavere crawl-hastighed)
• Dårligt: > 1.000 ms (risiko for ufuldstændig crawling)

Typiske TTFB-problemer og løsninger

Tjekliste til implementering

Brug denne tjekliste til at banke din TTFB i bund:

1. Mål din nuværende TTFB – Brug PageSpeed Insights eller WebPageTest
2. Find flaskehalsen – Skyldes det DNS, forbindelse, SSL eller serverbehandling?
3. Implementer server-side caching – Brug Redis/Memcached til databaseresultater
4. Aktivér full-page caching – Gælder statiske eller semi-statiske sider
5. Optimer database-forespørgsler – Tilføj indeks, fjern N+1-problemer
6. Aktivér Gzip/Brotli – Komprimer dine svar
7. Brug CDN – Fx Cloudflare, AWS CloudFront eller BunnyCDN
8. Aktivér HTTP/2 – Mindsk overhead fra forbindelserne
9. Overvåg din TTFB – Sæt Pingdom eller egen overvågning op
10. Test med curl – Tjek, at dine optimeringer virker

Konklusion

TTFB er et vigtigt nøgletal for både din SEO og din synlighed i AI. En langsom TTFB betyder færre crawlede sider, lavere prioritering og i værste fald ufuldstændige data til AI-systemerne. De fleste sites kan forbedre deres TTFB med caching (både server-side og full-page), database-optimering og et godt CDN.

Start med at måle din nuværende TTFB, find den største flaskehals (typisk serverens behandlingstid), og kom i gang med caching. De fleste sites kan komme under 600 ms med basal optimering og under 300 ms med et CDN og aggressiv caching.

Husk, at TTFB er fundamentet, som alle de andre nøgletal for performance hviler på. Optimer derfor TTFB først, og tag så fat på FCP og LCP.

Jakob Langemark

Co-founder