TTFB-optimering: Komplett guide (2026)

Varför TTFB är grunden för all webbprestanda

Time to First Byte (TTFB) mäter tiden från det att webbläsaren skickar en HTTP-förfrågan till dess att den första byten av svaret anländer. Låter kanske som ett smalt mätvärde, eller hur? Men i verkligheten sätter TTFB ett absolut golv för allt annat som händer. Inget — absolut ingenting — kan renderas, parsas eller visas förrän den första byten har anlänt. Varje millisekund av TTFB-fördröjning adderas direkt till First Contentful Paint (FCP), Largest Contentful Paint (LCP) och i slutändan till den totala sidladdningstiden.

TTFB är inte ett officiellt Core Web Vital, men det är ett diagnostiskt mätvärde som Google aktivt rekommenderar att övervaka. Och det finns goda skäl till det.

Enligt CrUX-data från 2025 har bara 88,5 procent av mobila sidladdningar ett godkänt TTFB-värde, jämfört med 96,1 procent på desktop. Mer än var tionde mobilanvändare drabbas alltså av en långsam start — och sedan kaskadeffekter nedåt genom alla efterföljande mätvärden. Det är ganska många användare.

I vår serie om Core Web Vitals har vi redan gått igenom INP, LCP och CLS i detalj. Den här guiden fokuserar helt på TTFB — det fundamentala mätvärdet som ligger till grund för dem alla. Om du har kämpat med höga LCP-värden trots bildoptimering och fetchpriority är chansen stor att problemet börjar just här, vid den allra första byten.

Vad TTFB faktiskt mäter — under huven

TTFB är inte bara "servertid". Det är summan av flera distinkta nätverks- och serveroperationer som alla måste slutföras sekventiellt. Så låt oss bryta ner det:

DNS-uppslagning: Webbläsaren måste omvandla domännamnet till en IP-adress. Med en ooptimerad DNS-leverantör kan det ta 20–120 ms.
TCP-handskakning: En tre-stegskoppling upprättas mellan webbläsare och server. Latensen är minst en round-trip time (RTT).
TLS-förhandling: För HTTPS-anslutningar tillkommer ytterligare 1–2 RTT för krypteringsförhandling (med TLS 1.2). TLS 1.3 reducerar det till en enda RTT.
Serverbearbetning: Den tid servern behöver för att köra applikationslogik, databasfrågor, rendering och generering av svaret.
Nätverkstransit: Tiden för den första byten att fysiskt färdas från server till webbläsare.

Varje steg är beroende av det föregående. En användare i Stockholm som ansluter till en server i Virginia genomgår minst 3–4 round-trips innan en enda byte av HTML-innehåll börjar anlända. Med en RTT på 80–100 ms innebär det 240–400 ms bara i nätverksoverhead — innan servern ens har börjat bearbeta förfrågan. Bara nätverket äter alltså upp en rejäl del av din tidsbudget.

TTFB-tröskelvärden

Google definierar följande tröskelvärden för TTFB:

Bra: 800 millisekunder eller mindre (p75)
Behöver förbättras: 800–1 800 millisekunder
Dåligt: Över 1 800 millisekunder

Men ärligt talat — 800 ms är egentligen bara den yttre gränsen. I praktiken bör du sikta på under 200 ms för statiska sidor och under 500 ms för dynamiskt genererade sidor. Under 100 ms? Det är utmärkt och tyder på en riktigt väloptimerad infrastruktur.

Mät TTFB innan du optimerar

Som med alla prestandamätvärden gäller principen: mät först, optimera sedan. Om du inte vet var tiden försvinner riskerar du att lägga timmar på att optimera helt fel sak. Jag har sett det hända mer än en gång — någon byter CDN-leverantör när problemet egentligen var en långsam databasfråga.

Navigation Timing API i webbläsaren

Det mest grundläggande sättet att mäta TTFB programmatiskt är med Navigation Timing API. Det ger dig tillgång till varje delfas av förfrågan:

// Mät TTFB och alla dess delfaser
const [entry] = performance.getEntriesByType("navigation");

if (entry) {
  const dns = entry.domainLookupEnd - entry.domainLookupStart;
  const tcp = entry.connectEnd - entry.connectStart;
  const tls = entry.secureConnectionStart > 0
    ? entry.connectEnd - entry.secureConnectionStart
    : 0;
  const serverTime = entry.responseStart - entry.requestStart;
  const ttfb = entry.responseStart - entry.startTime;

  console.log(`DNS-uppslagning: ${dns.toFixed(1)} ms`);
  console.log(`TCP-handskakning: ${tcp.toFixed(1)} ms`);
  console.log(`TLS-förhandling: ${tls.toFixed(1)} ms`);
  console.log(`Serverbearbetning: ${serverTime.toFixed(1)} ms`);
  console.log(`Total TTFB: ${ttfb.toFixed(1)} ms`);
}

Genom att bryta ned TTFB i dessa delfaser ser du exakt var flaskhalsen sitter. Hög DNS-tid? Byt DNS-leverantör. Hög serverbearbetningstid? Fokusera på cachning och databasoptimering. Hög nätverkslatens? Flytta närmare användarna med ett CDN. Enkel logik, men förvånansvärt ofta hoppar folk direkt till lösningen utan att göra den här analysen.

web-vitals-biblioteket

Googles web-vitals-bibliotek ger en enkel, standardiserad metod för att samla TTFB-data i produktion:

import { onTTFB } from "web-vitals/attribution";

onTTFB((metric) => {
  console.log("TTFB:", metric.value, "ms");
  console.log("DNS:", metric.attribution.dnsDuration, "ms");
  console.log("Anslutning:", metric.attribution.connectionDuration, "ms");
  console.log("Serverbearbetning:", metric.attribution.requestDuration, "ms");
  console.log("Väntande:", metric.attribution.waitingDuration, "ms");

  // Skicka till ditt analytiksystem
  if (metric.value > 800) {
    sendToAnalytics({
      metric: "TTFB",
      value: metric.value,
      dns: metric.attribution.dnsDuration,
      connection: metric.attribution.connectionDuration,
      request: metric.attribution.requestDuration
    });
  }
});

Server-Timing-headers för serversidig diagnostik

Medan Navigation Timing API mäter TTFB från klientsidan ger Server-Timing-headers dig insyn i vad som faktiskt händer på serversidan. Det är ett ovärderligt komplement — särskilt för att identifiera tunga databasfrågor, långsamma API-anrop eller ineffektiv renderingslogik:

// Express.js-middleware för Server-Timing
app.use((req, res, next) => {
  const timings = [];
  const start = process.hrtime.bigint();

  // Spåra databasfrågor
  const originalQuery = db.query.bind(db);
  db.query = async (...args) => {
    const queryStart = process.hrtime.bigint();
    const result = await originalQuery(...args);
    const queryDuration = Number(process.hrtime.bigint() - queryStart) / 1e6;
    timings.push(`db;dur=${queryDuration.toFixed(1)};desc="Databasfraga"`);
    return result;
  };

  res.on("finish", () => {
    const total = Number(process.hrtime.bigint() - start) / 1e6;
    timings.push(`total;dur=${total.toFixed(1)};desc="Total serverbearbetning"`);
  });

  const originalEnd = res.end.bind(res);
  res.end = (...args) => {
    const total = Number(process.hrtime.bigint() - start) / 1e6;
    timings.push(`total;dur=${total.toFixed(1)};desc="Total serverbearbetning"`);
    res.setHeader("Server-Timing", timings.join(", "));
    return originalEnd(...args);
  };

  next();
});

Med Server-Timing kan du se individuella timings direkt i Chrome DevTools Network-panel under fliken Timing. Du slipper gissa — du vet exakt vilken serveroperation som tar tid. Grymt smidigt för debugging.

Servercachning: den mest effektiva TTFB-optimeringen

Cachning är utan tvekan den enskilt mest effektiva metoden för att sänka TTFB. En välkonfigurerad cachestrategi kan reducera TTFB från över 2 sekunder till under 100 ms. Det är inte en överdrift — det är verklighet för de flesta webbplatser som faktiskt implementerar det ordentligt.

Helsidescache med rätt Cache-Control-headers

Grundprincipen är enkel: servera förrenderad HTML direkt istället för att köra applikationslogik och databasfrågor för varje enskild förfrågan. Det fungerar utmärkt för sidor som inte ändras vid varje besök (vilket gäller de flesta sidor på de flesta sajter):

# Nginx-konfiguration för helsidescache med stale-while-revalidate
location / {
    proxy_cache my_cache;
    proxy_cache_valid 200 10m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503;
    proxy_cache_background_update on;
    proxy_cache_lock on;

    add_header Cache-Control "public, max-age=600, stale-while-revalidate=86400";
    add_header X-Cache-Status $upstream_cache_status;

    proxy_pass http://backend;
}

Direktivet stale-while-revalidate är nyckeln här. Det tillåter Nginx att servera det cachade svaret omedelbart medan det uppdaterar cachen i bakgrunden. Användaren får alltid ett snabbt svar, och innehållet hålls fräscht. Win-win.

Objektcachning med Redis

Även när du inte kan cacha hela sidan (tänk personaliserat innehåll, inloggade användare) kan du cacha dyra databasfrågor och API-svar. Redis fungerar som ett minneslager som eliminerar onödiga databasturer:

import Redis from "ioredis";

const redis = new Redis({ host: "127.0.0.1", port: 6379 });

async function getCachedData(key, fetchFn, ttlSeconds = 300) {
  // Försök hämta från cache
  const cached = await redis.get(key);
  if (cached) {
    return JSON.parse(cached);
  }

  // Cache miss — hämta från datakällan
  const data = await fetchFn();

  // Spara i cache med TTL
  await redis.setex(key, ttlSeconds, JSON.stringify(data));

  return data;
}

// Användning i en route-handler
app.get("/api/products", async (req, res) => {
  const products = await getCachedData(
    `products:${req.query.category}`,
    () => db.query("SELECT * FROM products WHERE category = ?", [req.query.category]),
    600 // Cache i 10 minuter
  );
  res.json(products);
});

Skillnaden är dramatisk. En databasfråga som tar 50–200 ms ersätts av en Redis-uppslagning som tar under 1 ms. Det är inte ens i samma division. Med objektcachning på plats minskar din serverbearbetningstid avsevärt, vilket direkt sänker TTFB.

CDN: flytta innehållet närmare användarna

Nätverkslatens är bunden av fysikens lagar — ljuset kan helt enkelt inte färdas snabbare. Om din server står i Frankfurt och din användare sitter i Sydney innebär det ~300 ms RTT bara för nätverkstransporten. Inget du gör på serversidan kan eliminera den fördröjningen.

Det är här ett Content Delivery Network (CDN) blir avgörande.

Inte bara för statiska filer

Traditionellt har CDN:er använts för att cacha bilder, CSS och JavaScript. Men moderna CDN-tjänster som Cloudflare, Fastly och Bunny.net kan faktiskt cacha och leverera hela HTML-sidor från kantnoder globalt. Med rätt konfiguration kan din TTFB gå från 500–2 000 ms till 50–200 ms — oavsett var i världen besökaren befinner sig.

# Cloudflare Page Rules / Cache Rules för HTML-cachning
# Cacha HTML med kort TTL och stale-while-revalidate

# HTTP-headers från din origin
Cache-Control: public, max-age=300, s-maxage=3600, stale-while-revalidate=86400
Vary: Accept-Encoding
CDN-Cache-Control: max-age=3600

Direktivet s-maxage styr hur länge CDN:et cachar svaret (1 timme), medan max-age styr webbläsarens lokala cache (5 minuter). stale-while-revalidate säkerställer att besökare alltid får ett snabbt svar även när cachen håller på att uppdateras.

Cache hit ratio — sikta på 95 procent

Här är något som överraskar många: de flesta CDN-installationer kör med bara 15–30 procent cache hit ratio. Ofta på grund av ganska simpla felkonfigurationer. Vanliga bovar inkluderar unika query-strängar från analyticsskript, Set-Cookie-headers som förhindrar cachning, och alltför restriktiva Vary-headers. Med origin shielding, Brotli-komprimering och konsekvent URL-struktur kan du nå över 95 procent cache hit ratio. Det är en enorm skillnad i praktiken.

Edge computing: kod nära användaren

Edge computing tar CDN-konceptet ett steg längre. Istället för att bara cacha statiska svar kan du köra serverlogik direkt på kantnoderna — autentisering, personalisering, A/B-testning och till och med server-side rendering. Ganska kraftfullt.

Cloudflare Workers

Cloudflare Workers kör JavaScript på över 300 globala platser med sub-millisekund kalla starter. Det innebär att dynamisk logik kan exekveras med under 50 ms TTFB globalt. Ja, globalt.

// Cloudflare Worker för edge-side rendering med cachning
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const cacheKey = new Request(url.toString(), request);
    const cache = caches.default;

    // Kontrollera edge-cachen
    let response = await cache.match(cacheKey);
    if (response) {
      return new Response(response.body, {
        headers: {
          ...Object.fromEntries(response.headers),
          "X-Cache": "HIT"
        }
      });
    }

    // Cache miss: generera svar vid kanten
    const data = await env.KV_STORE.get(url.pathname, "json");

    if (data) {
      const html = renderPage(data);
      response = new Response(html, {
        headers: {
          "Content-Type": "text/html;charset=UTF-8",
          "Cache-Control": "public, max-age=300, s-maxage=3600",
          "X-Cache": "MISS"
        }
      });

      // Spara i edge-cachen
      await cache.put(cacheKey, response.clone());
      return response;
    }

    // Fallback till origin
    return fetch(request);
  }
};

Den verkliga styrkan med edge computing är att du slipper välja mellan snabbhet och dynamik. Du kan ha personaliserat innehåll med sub-50 ms TTFB genom att kombinera KV-lagring med edge-logik. Det är en kompromiss som inte längre behöver vara en kompromiss.

HTTP/3 och anslutningsoptimering

HTTP/3 med QUIC-protokollet är en av de mest underskattade TTFB-optimeringarna just nu. Till skillnad från TCP, som kräver en separat handskakning följd av TLS-förhandling, kombinerar QUIC transport och kryptering i en enda round-trip. Vid återanslutning till en känd server kan det till och med ske med noll round-trips (0-RTT). Alltså — data börjar flöda direkt.

Konkret vinst: färre round-trips

HTTP/1.1 + TLS 1.2: 3 round-trips innan data kan skickas (TCP SYN + TLS)
HTTP/2 + TLS 1.3: 2 round-trips (TCP SYN + TLS 1.3)
HTTP/3 + QUIC: 1 round-trip (QUIC handshake inkluderar kryptering)
HTTP/3 + QUIC (återanslutning): 0 round-trips (0-RTT resumption)

Med en RTT på 80 ms till en svensk server (typiskt för en mobilanvändare) sparar HTTP/3 hela 160 ms jämfört med HTTP/1.1. Det är en enorm förbättring som kräver noll ändringar i din applikationskod. Det enda du behöver göra är att aktivera HTTP/3 på din server eller CDN — ofta handlar det om att bocka i en ruta.

Preconnect och dns-prefetch för tredjepartstjänster

Om din sida ansluter till externa domäner (analyticsskript, fonter, API:er) kan du eliminera anslutningsfördröjningen med resurstips:

<!-- Preconnect: fullständig anslutning inklusive TLS -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://cdn.example.com" crossorigin>

<!-- dns-prefetch: bara DNS-uppslagning (lägre kostnad, bredare stöd) -->
<link rel="dns-prefetch" href="https://analytics.example.com">

Använd preconnect för de 2–3 viktigaste tredjepartsdomänerna och dns-prefetch för övriga. En liten varning dock: fler än 4–5 preconnects kan faktiskt försämra prestanda genom att konkurrera om nätverksresurser. Mer är inte alltid bättre.

103 Early Hints: gör TTFB-väntetiden produktiv

HTTP 103 Early Hints är en relativt ny mekanism som låter servern skicka preliminära svarsheaders till webbläsaren medan det fullständiga svaret fortfarande genereras. I praktiken innebär det att webbläsaren kan börja ladda kritisk CSS och LCP-bilder under den tid den annars bara sitter och väntar. Smart, eller hur?

Hur det fungerar

HTTP/1.1 103 Early Hints
Link: </css/critical.css>; rel=preload; as=style
Link: </images/hero.avif>; rel=preload; as=image

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Server-Timing: db;dur=45.2, render;dur=12.8
...

Servern skickar 103-svaret omedelbart efter att ha tagit emot förfrågan, innan den ens börjar bearbeta den. Webbläsaren agerar på länkarna och börjar ladda resurserna. När det fullständiga 200-svaret anländer har resurserna redan börjat — eller kanske redan slutfört — laddningen.

Viktiga begränsningar att känna till

Det här är viktigt: data från Shopify visar att 103 Early Hints ger bäst resultat på desktop med 1–3 förladdade resurser. På mobila enheter kan overheaden faktiskt försämra prestanda från den 40:e percentilen och uppåt. Så var selektiv — förladda bara resurser som verkligen är kritiska för above-the-fold-innehåll, och verifiera alltid effekten med Real User Monitoring.

Nginx-konfiguration för 103 Early Hints

# Nginx 1.27+ med stöd för 103 Early Hints
server {
    listen 443 ssl;
    http2 on;
    http3 on;

    location / {
        # Skicka Early Hints för kritiska resurser
        add_header Link "; rel=preload; as=style" early;
        add_header Link "; rel=preload; as=font; crossorigin" early;

        proxy_pass http://backend;
    }
}

Speculation Rules API: nästintill noll TTFB vid navigering

Okej, det här är nog den mest spännande delen. Speculation Rules API är en av de mest intressanta webbprestandainnovationerna 2026. Genom att förrendera sidor i bakgrunden innan användaren klickar kan du uppnå LCP-värden på under 50 ms — och ett TTFB som i praktiken är noll millisekunder. Noll. Det låter nästan för bra för att vara sant, men det fungerar.

Grundläggande Speculation Rules

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

Eagerness-inställningar 2026

Sedan januari 2026 har Chrome uppdaterat beteendet för eager på mobila enheter. Istället för att matcha desktop-beteendet baseras nu spekulationer på vyportsheuristik — 50 ms efter att en länk scrollas in i vyn triggas speculeringen. Det innebär att mobila användare får samma snabba upplevelse som desktop-användare, men med smartare resurshantering.

De fyra eagerness-nivåerna i korthet:

immediate: Spekulerar direkt när reglerna upptäcks — bäst för kända nästa-sidkandidater.
eager: På desktop: 10 ms hover. På mobil (2026): vyportsheuristik med 50 ms fördröjning efter scroll-stopp.
moderate: På desktop: 200 ms hover. På mobil: mer restriktiva heuristik med 500 ms scroll-fördröjning och avståndsbegränsningar.
conservative: Spekulerar vid pointerdown/touchstart — lägst resursförbrukning men fortfarande märkbar vinst.

Kombinera med View Transitions för SPA-känsla

Här blir det riktigt kul. Genom att kombinera Speculation Rules med View Transitions API kan du skapa mjuka, animerade sidövergångar i en flersidig applikation (MPA) — helt utan JavaScript-ramverk:

/* Aktivera View Transitions */
@view-transition {
  navigation: auto;
}

/* Animera sidövergången */
::view-transition-old(root) {
  animation: fade-out 150ms ease-out;
}
::view-transition-new(root) {
  animation: fade-in 150ms ease-in;
}

@keyframes fade-out {
  from { opacity: 1; }
  to { opacity: 0; }
}
@keyframes fade-in {
  from { opacity: 0; }
  to { opacity: 1; }
}

Resultatet? Omedelbar navigering med snygg animation — snabbare än de flesta SPA-ramverk, med en bråkdel av JavaScript-kostnaden. Det är nästan lite ironiskt att MPA:er nu kan slå SPA:er på deras egen hemmaplan.

Databas- och serveroptimering

Om din serverbearbetningstid är hög (synlig via Server-Timing-headers eller Navigation Timing) ligger problemet ofta i databaslagret eller applikationslogiken. Det här är det mindre glamorösa jobbet, men det är ofta här de stora vinsterna gömmer sig.

Databasoptimering

Indexering: Säkerställ att alla kolumner som används i WHERE-, JOIN- och ORDER BY-klausuler har korrekta index. En saknad index kan innebära skillnaden mellan 2 ms och 2 000 ms för samma fråga. Tusen gånger långsammare, alltså.
Undvik N+1-problem: Om din sida laddar en lista med produkter och sedan gör en separat fråga per produkt för att hämta detaljer — ersätt det med en enda JOIN-fråga. Det är en av de vanligaste prestandabovarna jag stöter på.
Prepared statements: Använd förberedda satser för att eliminera parsningskostnaden vid upprepade frågor.
Connection pooling: Upprätta en pool av databasanslutningar istället för att skapa nya för varje förfrågan. Verktyg som PgBouncer (PostgreSQL) eller ProxySQL (MySQL) hanterar detta effektivt.

Komprimering: Brotli framför Gzip

Brotli ger 15–25 procent bättre komprimering än Gzip för HTML, CSS och JavaScript, vilket innebär mindre data att överföra och snabbare TTFB. Alla moderna webbläsare stöder Brotli, och aktivering på serversidan är ganska okomplicerat:

# Nginx Brotli-konfiguration
brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/javascript application/json
             text/xml application/xml image/svg+xml;

# Fallback till gzip för äldre klienter
gzip on;
gzip_comp_level 5;
gzip_types text/html text/css application/javascript application/json;

Notera att komprimeringsnivå 6 ger en bra balans mellan komprimering och CPU-kostnad. Nivå 11 ger marginellt bättre komprimering men tar betydligt längre tid — använd det bara för förkomprimerade statiska filer där du kan göra komprimeringen i förväg.

Minimera omdirigeringar

Varje HTTP-omdirigering adderar en fullständig round-trip till din TTFB. En kedja av omdirigeringar — exempelvis http:// → https:// → https://www. → https://www.example.com/se/ — kan enkelt addera 300–600 ms. Det är tre omdirigeringar som inte bidrar med något värde alls.

Konfigurera HSTS (HTTP Strict Transport Security) för att eliminera HTTP-till-HTTPS-omdirigeringar för återbesökare.
Välj en kanonisk domän (med eller utan www) och håll dig till den.
Undvik interna omdirigeringar i din applikation — länka direkt till den slutgiltiga URL:en.

Övervakning och kontinuerlig förbättring

TTFB-optimering är inte ett engångsprojekt. Nya funktioner, pluginuppdateringar, ökad trafik och förändrade användarmönster kan alla påverka TTFB över tid. Jag rekommenderar att sätta upp automatiserade varningar så att du fångar regressioner tidigt — innan dina användare märker det.

Sätt upp RUM-övervakning

import { onTTFB } from "web-vitals/attribution";

// Samla TTFB-data i produktion
onTTFB((metric) => {
  const data = {
    value: metric.value,
    rating: metric.rating,
    dns: metric.attribution.dnsDuration,
    connection: metric.attribution.connectionDuration,
    request: metric.attribution.requestDuration,
    page: window.location.pathname,
    country: navigator.language,
    connection_type: navigator.connection?.effectiveType || "unknown"
  };

  // Skicka via Beacon API (icke-blockerande)
  navigator.sendBeacon("/api/vitals", JSON.stringify(data));
});

Segmentera data per sida, land och anslutningstyp. En global genomsnittlig TTFB kan dölja att mobilanvändare i Asien har en helt annan upplevelse än desktop-användare i Sverige. Aggregerad data ljuger inte, men den kan dölja sanningen.

Prioriteringsordning för TTFB-optimering

Forskning visar att sajter som fixar TTFB först — innan LCP, INP och CLS — når godkända Core Web Vitals-värden på 4–6 veckor. De som hoppar över TTFB och går direkt på JavaScript-optimering tar 2–3 gånger längre tid. Så här ser den rekommenderade prioriteringsordningen ut:

Aktivera servercachning (helsidescache och objektcache) — störst omedelbar effekt.
Implementera CDN med HTML-cachning — eliminerar nätverkslatens.
Aktivera HTTP/3 och Brotli-komprimering — enkel konfigurationsändring, mätbar vinst.
Optimera databasfrågor — indexering, N+1-eliminering, connection pooling.
Implementera 103 Early Hints — gör väntetiden produktiv (framför allt på desktop).
Aktivera Speculation Rules — nästintill noll TTFB vid navigering.

Vanliga frågor om TTFB-optimering

Är TTFB ett Core Web Vital?

Nej, TTFB är inte ett officiellt Core Web Vital. De tre Core Web Vitals är LCP, INP och CLS. Däremot är TTFB ett kritiskt diagnostiskt mätvärde som Google rekommenderar att övervaka, eftersom det direkt påverkar både LCP och FCP. En hög TTFB sätter ett absolut golv för hur snabbt din sida kan renderas — oavsett hur optimerad resten av sidan är.

Vad är ett bra TTFB-värde?

Google definierar 800 ms eller mindre som "bra" vid den 75:e percentilen. I praktiken bör du sikta på under 200 ms för statiska sidor och under 500 ms för dynamiska sidor. Under 100 ms indikerar en utmärkt infrastruktur. Värden över 1 800 ms klassas som dåliga och bör åtgärdas så snart som möjligt.

Varför är min TTFB högre på mobilen?

Mobilnätverk har generellt högre latens (round-trip time) än fasta uppkopplingar — ofta 50–150 ms extra per round-trip. Dessutom är TCP- och TLS-handskakar proportionellt dyrare på mobilen. Det är därför HTTP/3, CDN-cachning och Speculation Rules ger störst effekt just för mobilanvändare. Enligt CrUX-data från 2025 har bara 88,5 procent av mobila sidladdningar godkänt TTFB, jämfört med 96,1 procent på desktop.

Hur påverkar TTFB min SEO-ranking?

TTFB påverkar SEO indirekt genom dess inverkan på LCP, som är ett officiellt Core Web Vital och en rankingfaktor. Snabbare TTFB innebär snabbare LCP, vilket innebär en bättre sidupplevelse-signal till Google. Dessutom kan Googles crawler indexera fler sidor per tidsenhet om din server svarar snabbare, vilket förbättrar crawl-effektiviteten — särskilt viktigt för stora sajter med tusentals sidor.

Kan Speculation Rules API användas i alla webbläsare?

Inte ännu. Speculation Rules API stöds för närvarande i Chromium-baserade webbläsare — Chrome, Edge och Opera. Safari och Firefox har ännu inte implementerat stöd, men det finns tecken på att cross-browser-adoption är på gång. Den goda nyheten är att webbläsare som inte stöder API:et ignorerar <script type="speculationrules"> helt, så det finns ingen risk med att implementera det som en progressiv förbättring redan idag.