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:

1. DNS lookup – Tid til at oversætte domænenavn til IP-adresse

2. Connection time – Tid til at etablere TCP-forbindelse

3. SSL/TLS handshake – Tid til at etablere HTTPS-forbindelse (hvis applicable)

4. Server processing time – Tid serveren bruger på at generere response

5. 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)

1. Åbn Chrome DevTools (F12)

2. Gå til Network tab

3. Refresh siden

4. Klik på den første request (typisk dit HTML-dokument)

5. Se Timing tab

Du vil se:

PageSpeed Insights

1. Gå til https://pagespeed.web.dev/

2. Indtast din URL

3. Se "Server response time" under diagnostics

WebPageTest

1. Gå til https://www.webpagetest.org/

2. Indtast din URL og vælg test location

3. Se "Time to First Byte" i results

WebPageTest viser også:

• TTFB per request (ikke kun første HTML)

• Breakdown af DNS, Connect, SSL, Wait

Command-line test med curl

# Measure 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 testing

import requests
import time

def measure_ttfb(url):
    start = time.time()
    r = requests.get(url, stream=True)
    ttfb = time.time() - start
    return ttfb * 1000  # Convert to milliseconds

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")

Identificér hvad der gør din TTFB langsom

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:

<link rel="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

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);
}

echo json_encode($data);

Full-page caching:

Cache hele HTML-responses.

Nginx example:

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

2. Optimér database queries

Problem: N+1 queries eller unindexed queries.

Identificér slow queries (MySQL):

-- Enable slow query log
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- Queries over 1 second

-- View slow queries
SELECT * FROM

Løsninger:

• Add indexes:

-- Before: Full table scan
SELECT * FROM products WHERE category = 'electronics';

-- After: Create index
CREATE INDEX idx_category ON products(category)

• Use query caching:

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

• Optimize JOINs:

-- Bad: Multiple joins without proper indexes
SELECT * 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 indexes
CREATE 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

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)

With CDN:

• User in US requests → CDN edge server in US

• TTFB = 150ms (20ms network latency + 130ms cache hit)

5. Enable Gzip/Brotli compression

Compression reduces response size, speeding up transfer time.

Nginx config:

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;

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

Apache config:

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

6. Reduce server-side processing

Minimize:

• Heavy computations on each request

• External API calls

• File I/O operations

Example (Python Flask):

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

app = Flask(__name__)

# Bad: External API call on every request
@app.route('/weather')
def weather_bad():
    response = requests.get('https://api.weather.com/data')
    return render_template('weather.html', data=response.json())

# Good: Cache external API call
@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. Use HTTP/2 eller HTTP/3

HTTP/2 allows multiplexing, reducing connection overhead.

Enable HTTP/2 (Nginx):

server {
    listen 443 ssl http2;
    server_name ditwebsite.dk;
    # ... rest of config

Test if HTTP/2 is enabled:

curl -I --http2 https://ditwebsite.dk/
# Look for "HTTP/2 200" in response

Optimér for AI-crawlere specifikt

1. Prioriter vigtige sider

Ensure your most important pages (homepage, key products, top articles) have the fastest TTFB.

Nginx: Separate cache for key pages:

location = / {
    proxy_cache_valid 200 120m;  # Cache homepage for 2 hours
    proxy_pass http://backend;
}

location /products/ {
    proxy_cache_valid 200 60m;  # Cache products for 1 hour
    proxy_pass http

2. Detect og optimér for crawlers

Serve cached version to crawlers:

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

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

if ($is_crawler) {
    // Serve static cached HTML
    echo file_get_contents('/cache/static_page.html');
} else {
    // Serve dynamic content
    include('dynamic_page.php');
}

3. Pre-warm cache før crawler visits

Hvis du ved hvornår crawlers besøger (fx efter sitemap submission), pre-warm cachen:

#!/bin/bash
# Warm cache by requesting all URLs
while read url; do
  curl -s "$url" > /dev/null
done

Monitér TTFB løbende

Setup automated monitoring

Pingdom:

1. Opret konto på pingdom.com

2. Add URL checks

3. Set alert threshold (fx "alert if TTFB > 800ms")

UptimeRobot:

1. Free monitoring hver 5 minut

2. Email alerts

Custom script (cron job):

#!/bin/bash
# Check TTFB and alert if > 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 too high: ${TTFB_MS}ms" | mail -s "TTFB Alert" admin@ditwebsite.dk
fi

Run every hour:

crontab -e
# Add:
0

TTFB targets

Google's recommendations

• Good: < 600ms

• Needs improvement: 600ms - 1200ms

• Poor: > 1200ms

For AI-crawlers (anbefalinger)

• Excellent: < 300ms (får highest crawl priority)

• Good: 300ms - 600ms (normal crawl rate)

• Acceptable: 600ms - 1000ms (lower crawl rate)

• Poor: > 1000ms (risk of incomplete crawls)

Common TTFB issues og fixes

Implementation Checklist

Brug denne tjekliste til at forbedre TTFB:

1. Mål baseline TTFB – Brug PageSpeed Insights eller WebPageTest

2. Identificér bottleneck – DNS, connection, SSL, eller server processing?

3. Implementer server-side caching – Redis/Memcached for database results

4. Enable full-page caching – For static eller semi-static pages

5. Optimér database queries – Add indexes, remove N+1 queries

6. Enable Gzip/Brotli – Compress responses

7. Use CDN – Cloudflare, AWS CloudFront, eller BunnyCDN

8. Enable HTTP/2 – Reduce connection overhead

9. Monitor TTFB – Setup Pingdom eller custom monitoring

10. 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.