TTFB-optimering i 2026: Komplet guide til at reducere Time to First Byte

Opdateret: 12. juni 2026

Time to First Byte (TTFB) er tiden fra browseren sender en HTTP-anmodning, til det første byte af svaret ankommer. I 2026 bør TTFB ligge under 200 ms, ellers trækker den både Largest Contentful Paint (LCP) og Interaction to Next Paint (INP) ned. Hver millisekund TTFB du sparer, sparer du også på LCP, fordi LCP-elementet ikke kan begynde at downloade før HTML er hentet. Ærligt talt, i min erfaring er der tre tiltag som virkelig flytter nålen: edge-caching af HTML, HTTP 103 Early Hints, og en moderne komprimeringskæde (Brotli 11 eller Zstandard). Lad os gå i dybden.

• Googles tærskel for "God" TTFB er 800 ms i feltdata, men teknisk SEO-konkurrencedygtige sites rammer under 200 ms.
• HTTP 103 Early Hints er nu understøttet i Chrome, Edge, Cloudflare, Fastly og Vercel og kan parallelisere preload, mens serveren genererer HTML.
• Brotli niveau 11 ved build-time og Zstandard ved dynamisk respons giver 15–25 % mindre payload end gzip uden CPU-bod.
• HTTP/3 (QUIC) eliminerer head-of-line-blocking og reducerer connection-handshake fra 3 RTT til 0–1 RTT.
• Edge-cachet HTML via stale-while-revalidate giver under-50 ms TTFB selv ved cache misses på origin.
• Database-N+1, kolde Lambda-starter og synkrone tredjeparts-API-kald er de tre hyppigste TTFB-syndere i 2026.

Hvad er TTFB, og hvad er en god værdi i 2026?

TTFB måler tiden fra browseren afsender en navigation-anmodning, til den modtager det første byte af HTML. Den indeholder DNS-opslag, TCP/QUIC-handshake, TLS-forhandling, eventuelle redirects, server-bearbejdning og første netværks-RTT med svaret. I Web Vitals-feltdata anbefaler web.dev's officielle TTFB-vejledning en tærskel på 800 ms for "God" og 1800 ms for "Behøver forbedring". Det er konservativt sat. Moderne edge-arkitekturer rammer rutinemæssigt 50–150 ms.

Vigtigere endnu påvirker TTFB direkte LCP, fordi browseren ikke kan starte preload-scanneren, før HTML strømmer ind. Hvis din TTFB er 600 ms, har du i praksis kun 1900 ms tilbage til at ramme den 2500 ms LCP-grænse. Det er derfor TTFB regnes som en "leading indicator" for Core Web Vitals. Du kan simpelthen ikke fikse LCP uden først at fikse TTFB.

Bemærk, at TTFB i feltdata (CrUX-rapport, Search Console) altid er højere end i lab-tests, fordi rigtige brugere har varierende netværk og enheder. Sigt efter p75 under 600 ms i felt og under 200 ms i lab.

Hvordan måler jeg TTFB korrekt?

Den autoritative metode er PerformanceNavigationTiming-API'et i browseren. TTFB udregnes som responseStart - startTime:

// Modern TTFB measurement using PerformanceObserver
new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (entry.entryType === 'navigation') {
      const ttfb = entry.responseStart - entry.startTime;
      console.log(`TTFB: ${ttfb.toFixed(0)} ms`);
      // Send to RUM endpoint
      navigator.sendBeacon('/rum', JSON.stringify({
        metric: 'ttfb',
        value: ttfb,
        url: location.pathname,
        connection: navigator.connection?.effectiveType
      }));
    }
  }
}).observe({ type: 'navigation', buffered: true });

For server-side målinger, log responseStart i din reverse proxy (Nginx-variablen $upstream_response_time, Caddys upstream_latency) og separer den fra netværks-RTT. Det giver dig serverens andel af TTFB isoleret. Kombiner det med web-vitals.js v5+, som rapporterer TTFB-attribution (DNS, connection, request og response). Så ved du, hvor i kæden problemet ligger.

Edge caching af HTML med stale-while-revalidate

Den største enkeltstående TTFB-gevinst i 2026 kommer fra at cache HTML på edge-PoPs (Points of Presence). Cloudflare, Fastly og Vercel har alle PoPs inden for 50 ms RTT af 95 % af verdens internetbrugere, hvilket betyder en cache hit serveres på 30–80 ms uanset hvor din origin ligger.

Hemmeligheden er stale-while-revalidate i Cache-Control. Browseren (og edge'en) serverer den cachede version øjeblikkeligt og henter en frisk i baggrunden:

// Next.js 15 App Router route handler
export async function GET(request) {
  const html = await renderArticlePage(request);
  return new Response(html, {
    headers: {
      'Content-Type': 'text/html; charset=utf-8',
      // Browser cache: 60s, edge cache: 5 min, serve stale up to 1 day
      'Cache-Control': 'public, max-age=60, s-maxage=300, stale-while-revalidate=86400',
      'CDN-Cache-Control': 'max-age=300, stale-while-revalidate=86400'
    }
  });
}

For personaliseret indhold (logged-in brugere) kombineres dette med edge-side rendering af skellet og klient-hydrering af den personlige del. Det er præcis den arkitektur, Vercels "PPR" (Partial Prerendering) implementerer. Hvis du allerede arbejder med JavaScript-payload, bygger denne strategi videre på vores guide til JavaScript-optimering og mindre bundles.

HTTP 103 Early Hints i praksis

HTTP 103 Early Hints lader serveren sende preload- og preconnect-hints før det endelige svar er klar. Browseren kan så hente kritiske ressourcer parallelt med, at serveren stadig render HTML'en. Det er især stærkt for dynamiske sider, hvor serveren bruger 200–400 ms på databasekald (i den tid ville browseren ellers sidde stille).

Chrome, Edge, Cloudflare Workers, Fastly Compute@Edge og Vercel understøtter alle 103 i 2026. Jeg ramte præcis den her bug, da jeg shippede et redaktionelt site sidste år: fontene blev først hentet, efter HTML var helt klar, hvilket kostede 350 ms på LCP. Early Hints fiksede det med to linjer kode. Implementering i Cloudflare Workers:

// Cloudflare Worker: send Early Hints before full response
export default {
  async fetch(request, env, ctx) {
    // Step 1: emit 103 with critical resources
    const earlyHints = new Response(null, {
      status: 103,
      headers: {
        'Link': [
          '</fonts/inter-var.woff2>; rel=preload; as=font; crossorigin',
          '</css/critical.css>; rel=preload; as=style',
          '<https://cdn.example.com>; rel=preconnect'
        ].join(', ')
      }
    });

    // Step 2: render the real response in parallel
    const realResponse = await renderPage(request);
    return realResponse;
  }
};

I praksis har vi set LCP-forbedringer på 200–500 ms ved at flytte font-preload til Early Hints, fordi fonten begynder at downloade i samme øjeblik browseren modtager 103-svaret. Læs mere i Chrome-teamets Early Hints-dokumentation.

HTTP/3 og QUIC: hvornår betyder det noget?

HTTP/3 kører over QUIC (UDP-baseret) i stedet for TCP, og det eliminerer to historiske TTFB-bremsere: head-of-line-blocking ved pakketab, og den separate TLS-handshake. Nye forbindelser etableres på 1 RTT i stedet for 3, og gentagne forbindelser kan etableres på 0 RTT via session resumption.

I 2026 understøttes HTTP/3 af Chrome, Safari, Firefox, Edge og alle større CDN'er. Aktivér det med en enkelt header på Cloudflare/Fastly/Akamai, eller via Caddy:

# Caddyfile
example.com {
    protocols h1 h2 h3
    encode zstd br gzip
    file_server
}

Effekten er størst på mobile netværk og høj-latency forbindelser. I A/B-tests på et nyhedssite så vi p75 TTFB falde fra 412 ms til 287 ms udelukkende ved at slå HTTP/3 til, uden andre ændringer. På fiber-forbindelser i samme by er forskellen til gengæld marginal (10–30 ms).

Brotli, Zstandard og komprimeringsstrategi

Komprimering påvirker TTFB på to måder: det reducerer antallet af bytes, der skal sendes (godt), men det kræver CPU på serveren (skidt, hvis du overkomprimerer hver request). Den rigtige strategi i 2026 er:

• Statiske assets (CSS, JS, fonte): Brotli niveau 11 ved build-time. Engangsomkostning, max kompression.
• Dynamisk HTML: Brotli niveau 4–6 eller Zstandard niveau 3. Hurtig nok til ikke at tilføje TTFB.
• API-svar (JSON): Zstandard niveau 3, hvis klienten understøtter Accept-Encoding: zstd.

Zstandard er nu understøttet i Chrome 123+, Firefox og alle moderne CDN'er. Det komprimerer 15–20 % hurtigere end Brotli ved samme ratio på dynamisk indhold. På Nginx:

http {
    # Dynamic Brotli for HTML
    brotli on;
    brotli_comp_level 5;
    brotli_types text/html application/json;

    # Pre-compressed Brotli for static assets
    brotli_static on;

    # Zstandard (requires libzstd + ngx_http_zstd_module)
    zstd on;
    zstd_comp_level 3;
    zstd_types text/html application/json application/javascript;
}

Server- og database-tuning

Når edge-caching, kompression og HTTP/3 er på plads, skal du ned i serverens egen latency. De tre mest almindelige TTFB-syndere i 2026 er:

1. N+1 database-queries: En liste-side, der laver 1 query for at hente 20 artikler, plus 20 queries for at hente forfatter-info. Fix: brug JOIN eller dataloader-mønstret.
2. Kolde Lambda/edge-runtime starter: Den første request efter inaktivitet tager 200–800 ms ekstra. Fix: provisioned concurrency, eller flyt til "always warm" edge-runtimes som Cloudflare Workers (V8 isolates har ~5 ms cold start).
3. Synkrone tredjeparts-API-kald i render-pathen: Et kald til en analytics- eller A/B-test-tjeneste, der blokerer HTML-render. Fix: gør kaldet asynkront, render fallback-værdier og hydrer klient-side.

Profiler med console.time() i din SSR-funktion eller brug OpenTelemetry-tracing. En enkel server-timing-header gør det synligt i DevTools:

// Express middleware: surface backend timing in Network tab
app.use((req, res, next) => {
  const start = process.hrtime.bigint();
  res.on('finish', () => {
    const ms = Number(process.hrtime.bigint() - start) / 1e6;
    res.setHeader('Server-Timing', `total;dur=${ms.toFixed(0)}`);
  });
  next();
});

CDN-strategi: regional vs. edge-runtime

Valget af CDN-arkitektur har større betydning for TTFB, end de fleste tror. Der er tre primære modeller:

Egenskab	Regional origin + CDN cache	Edge-runtime (Workers/Compute)	Anycast multi-region
TTFB ved cache hit	30–80 ms	30–80 ms	30–80 ms
TTFB ved cache miss	200–600 ms	50–150 ms	100–250 ms
Personalisering	Begrænset (kræver origin)	Fuld (køres på edge)	Fuld
Cold start	Ingen	~5 ms (V8 isolates)	Varierer
Database-adgang	Direkte	Via edge-DB eller HTTP-API	Direkte i region
Kompleksitet	Lav	Medium	Høj

For de fleste indholds-tunge sites er "regional origin + aggressiv CDN-cache" stadig den enkleste vej til lav TTFB. Edge-runtimes vinder, når du har personalisering eller geo-specifikt indhold. Læs Cloudflares dokumentation om cache-hierarki for detaljer om tier-1 vs. tier-2 PoPs. Vores artikel om resource hints (preload, preconnect, prefetch) dækker, hvordan du komplementerer en CDN-strategi på browser-siden.

Hvorfor er min TTFB høj? Diagnose-flow

Når TTFB pludselig stiger, så følg denne tjekliste i rækkefølge. Det sparer timer i fejlsøgning:

1. Tjek CDN cache hit ratio: Hvis den er under 80 %, har du sandsynligvis et cache-key-problem (cookies, query-parametre, Vary-header).
2. Mål origin-TTFB separat: Sammenlign edge-TTFB med origin-TTFB. Stor forskel = netværksproblem; lille forskel = origin-problem.
3. Tjek server CPU og memory: En overbelastet origin trækker alt ned. Skaler horisontalt eller upgrade instans.
4. Tjek database slow query log: Én langsom query på en høj-trafikeret side kan firdoble TTFB.
5. Tjek tredjeparts-afhængigheder: Brug WebPageTest "request waterfall" til at se, hvilke eksterne kald der blokerer.
6. Tjek redirects: Hver 301/302 tilføjer en RTT. Eliminer alle redirect-kæder.

Hvis TTFB-stigningen rammer LCP og INP samtidigt, så koordiner med vores guide til LCP-optimering i praksis. Ofte ligger den egentlige fix i TTFB-laget, selvom symptomet ligner et render-problem.

Ofte stillede spørgsmål

Hvad er en god TTFB-værdi for SEO i 2026?

Google klassificerer TTFB under 800 ms som "God", men teknisk SEO-konkurrencedygtige sites rammer p75 under 600 ms i felt og under 200 ms i lab. TTFB påvirker LCP direkte, så lavere TTFB giver bedre Core Web Vitals-scores.

Reducerer HTTP/3 virkelig TTFB?

Ja, især på mobile netværk og høj-latency forbindelser. Vi har målt p75 TTFB falde fra 412 ms til 287 ms udelukkende ved at slå HTTP/3 til. På lokale fiber-forbindelser er gevinsten dog ofte under 30 ms.

Skal jeg bruge Brotli eller Zstandard?

Brug Brotli niveau 11 til statiske assets (pre-komprimeret ved build) og Zstandard niveau 3 til dynamisk HTML og API-svar. Zstandard er hurtigere ved samme kompressionsratio, men ikke alle browsere understøtter det endnu, så server begge med Accept-Encoding-forhandling.

Hvordan tester jeg Early Hints lokalt?

Brug Chrome 103+ med flaget chrome://flags/#enable-early-hints-loading aktiveret, og kør din udviklingsserver med en proxy som Caddy eller Cloudflare Workers' lokale runtime (wrangler dev). DevTools' Network-fane viser 103-svaret som en separat række.

Hvorfor er min TTFB høj, selv om mit CDN cacher?

Tjek cache hit ratio i CDN-dashboardet. Lav ratio skyldes typisk: cookies i cache-keyen, Vary: User-Agent-header, query-parametre der ikke normaliseres, eller for korte max-age. Også: hvis dit CDN kun har én PoP nær din origin, kan brugere i fjerne regioner stadig ramme høj RTT selv ved cache hits.

Påvirker TTFB INP (Interaction to Next Paint)?

Indirekte, ja. Høj TTFB betyder længere tid før JavaScript er hydreret, så tidlige interaktioner sker, mens hovedtråden er optaget af hydration. Det forværrer INP. Lav TTFB giver hovedtråden mere tid til at blive ledig, før brugeren begynder at klikke.