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

Udgivet den

Forfatter

Jakob Langemark

Følg os

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:

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

  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:




PageSpeed Insights

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

  2. Indtast din URL

  3. Se efter "Serverens svartid" under diagnosticering

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 per anmodning (ikke kun for den første HTML)

  • Fordeling af 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
# 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
# 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")
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")
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 < 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:

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

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:

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:

  • 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):

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

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

<?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

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

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

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

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

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)

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

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

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

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

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

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

-- 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
top
# Se CPU- og hukommelsesforbrug

htop
# Mere brugervenligt alternativ
top
# Se CPU- og hukommelsesforbrug

htop
# Mere brugervenligt alternativ

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:

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

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

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

Apache-konfiguration:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/json
</IfModule>
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/json
</IfModule>
<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)
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)
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 or HTTP/3

HTTP/2 tillader multiplexing, hvilket mindsker overforbruget af forbindelser.

Aktivér HTTP/2 (Nginx):

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

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

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

Test om HTTP/2 er aktivt:

curl -I --http2 https://ditwebsite.dk/
# Hold øje med "HTTP/2 200" i svaret
curl -I --http2 https://ditwebsite.dk/
# Hold øje med "HTTP/2 200" i svaret
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

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

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

2. Identificer og optimer til crawlere

Server en cachet version direkte til crawlere:

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

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

<?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 (f.eks. lige efter 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

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

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

Overvåg din TTFB løbende

Sæt automatisk overvågning op

Pingdom:

  1. Opret en profil på pingdom.com

  2. Tilføj overvågning af dine URL'er

  3. Sæt en alarmgrænse (f.eks. "alarm hvis TTFB > 800ms")

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
#!/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
#!/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

crontab -e
# Tilføj:
0

crontab -e
# Tilføj:
0

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:

  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 — F.eks. Cloudflare, AWS CloudFront eller BunnyCDN

  8. Aktivér HTTP/2 — Reducer overforbruget af forbindelser

  9. Overvåg din TTFB — Sæt Pingdom eller egen overvågning op

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