103 Early Hints 2026: Snabba upp LCP

Uppdaterad: 8 augusti 2026

HTTP 103 Early Hints är ett informationsstatussvar som låter servern skicka Link: rel=preload och rel=preconnect-headers till webbläsaren innan det slutgiltiga 200-svaret är klart. Det ger webbläsaren tid att hämta kritiska resurser under den tid backend annars bara skulle vänta. I praktiken flyttar tekniken 100–400 ms av tomt vänteläge och förbättrar LCP mätbart på sidor med hög serverlogik eller kall databas. I den här guiden visar jag hur du aktiverar det i Node.js, nginx, Cloudflare, Fastly och Vercel, samt hur du undviker de fallgropar som gör att det tystnar i produktion.

HTTP 103 (RFC 8297) skickas innan huvudsvaret och innehåller Link-headers för preload och preconnect.
Chrome, Edge och Opera stödjer Early Hints sedan version 103. Safari och Firefox parsar det inte som preload än (augusti 2026).
Cloudflare, Fastly, Vercel och Akamai vidarebefordrar 103-svar från origin, men bara om HTTP/2 eller HTTP/3 används mellan CDN och användare.
Rätt konfigurerat sänker Early Hints LCP med 100–400 ms på sidor där TTFB är över 300 ms.
Fel konfigurerat kan det slösa bandbredd på användare med långsamma anslutningar eller preloada resurser som senare ändras. Mät alltid först.
HTTP/2 Server Push är utfasat (borttaget från Chrome 106). Early Hints är den moderna ersättaren.

Vad är HTTP 103 Early Hints?

HTTP 103 Early Hints är en informationsstatuskod definierad i RFC 8297 som gör det möjligt för en server att skicka ett preliminärt svar med Link-headers innan det slutgiltiga svaret genereras. Klienten (webbläsaren) läser dessa Link-headers och kan börja hämta preload-resurser, som CSS, hjältebild, kritiska JavaScript-buntar eller webbfonter, parallellt med att servern fortfarande bygger HTML-svaret.

Idén föddes ur ett konkret problem. När en Server-Side-Rendered-sida tar 400 ms att generera i backend står webbläsaren och väntar med tom bilduplekt. Först när HTML anländer kan parsern hitta <link rel="preload">-taggar och starta hämtningen av kritiska resurser. Early Hints kortar den där dödtiden genom att skicka samma information i förskott. Tekniskt är det ett vanligt HTTP-svar med statuskod 103 följt av en tom rad, och sedan följer det slutgiltiga 200-svaret på samma anslutning.

Ärligt talat, för mig som jobbar full-stack är det här bland de mest eleganta prestandaverktygen på länge. Det kräver ingen ombyggnad av frontend, ingen ny bundling-strategi och ingen ändring av hur du renderar sidan. Du bygger bara en liten "vad vill jag preloada?"-tabell per rutt och skickar den tidigt.

Hur fungerar Early Hints i praktiken?

Så, sekvensen ser ut så här. När webbläsaren skickar sin GET /produkt/123-förfrågan svarar din server först med:

HTTP/2 103 Early Hints
Link: </assets/hero.avif>; rel=preload; as=image; fetchpriority=high
Link: </assets/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect; crossorigin

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Link: </assets/hero.avif>; rel=preload; as=image
<!doctype html>
<html>...

103-svaret skickas i det ögonblick request-handlern vet vilka resurser sidan kommer att behöva. Normalt direkt efter att routing och auth är klara, men innan databasfrågor, mallrendering eller GraphQL-upplösning körs. Chrome startar då parallella fetches för de resurser som Link-headern anger, och när HTML-svaret så småningom anländer är många av dessa redan cachade av webbläsaren.

Viktigt: 103-svaret får bara innehålla vissa headers, främst Link. Att skicka Set-Cookie, Content-Type eller custom-headers här bryter mot standarden och kommer att ignoreras eller kasta anslutningen på strikt implementering. Håll det till preload- och preconnect-hints. Du kan skicka flera 103-svar på samma anslutning om det behövs (t.ex. först preconnect, sedan preload när du vet vilka resurser som gäller), men i praktiken räcker ett enda 103-svar för nästan alla sidor.

Early Hints vs preload, preconnect och HTTP/2 Server Push

Här är den snabba jämförelsen jag brukar dra upp när team ska välja strategi:

Egenskap	103 Early Hints	<link rel="preload">	HTTP/2 Server Push
Skickas innan HTML	Ja	Nej (i HTML-head)	Ja
Webbläsarstöd 2026	Chrome, Edge, Opera	Alla moderna	Borttaget ur Chrome
Kräver CDN-stöd	Ja	Nej	Ja
Bandbreddsslöseri	Lågt (klienten hämtar)	Lågt	Högt (pushas alltid)
Interagerar med cache	Ja (respekterar cache)	Ja	Nej (push ignorerar cache)
Bra för LCP-bild	Ja	Ja	Delvis
Bra för TTFB-tunga sidor	Ja	Nej	Ja

Den viktiga poängen: preload i HTML fungerar utmärkt när TTFB redan är låg. Om din server svarar på 80 ms har Early Hints ingen effekt att prata om, eftersom HTML kommer så snabbt att preload-taggen i huvudet triggar hämtningen nästan lika tidigt. Men om TTFB är 300–800 ms (databaskomplexitet, kall Lambda, tung mall) är Early Hints skillnaden mellan en LCP under 2,5 s och en över 3 s. Det är därför jag alltid parar Early Hints med insikter från min TTFB-optimeringsguide. Det är två sidor av samma mynt. Samma sak gäller när du redan kämpar med bildstorlekar, då hjälper det att först ha ordning på din AVIF- och WebP-bildoptimering så att preload-hinten faktiskt hämtar rätt asset.

Vilka webbläsare stödjer Early Hints 2026?

Läget i augusti 2026:

Chrome och Chromium-baserade (Edge, Opera, Brave, Samsung Internet): fullt stöd sedan Chrome 103 (juni 2022). Det är cirka 72 % av trafiken globalt.
Safari: parsar 103-svaret utan att krascha men startar inte preload av innehållet ännu. En WebKit-bugg (tracked som #235920) diskuterar implementation för Safari 18.4/19, men i produktion räknar jag inte med det förrän 2027.
Firefox: ignorerar 103-svaret helt. Ingen bug open för aktiv implementation just nu.

Även utan Safari- och Firefox-stöd är det värt att aktivera. Icke-stödjande webbläsare ignorerar helt enkelt 103-svaret utan att skada, det är en progressive enhancement. Om 72 % av dina besökare får 200 ms LCP-vinst är det bättre än att vänta på 100 %. Notera dock att om du använder fetchpriority-attributet i Link-headern måste du verifiera att din server och CDN inte strippar det. Vissa reverse proxies filtrerar bort okända Link-parametrar (jag har sett det hända med en gammal Envoy-version så sent som förra året).

Aktivera Early Hints i Node.js och Express

Node.js har inbyggt stöd för Early Hints via response.writeEarlyHints() sedan version 18.11. Så här ser en minimal Express-middleware ut som skickar 103 för alla produktsidor:

// early-hints.middleware.js
export function earlyHints(req, res, next) {
  // Skicka Early Hints så snart vi vet ruttens kritiska resurser.
  if (req.path.startsWith('/produkt/')) {
    res.writeEarlyHints({
      link: [
        '</assets/product-hero.avif>; rel=preload; as=image; fetchpriority=high',
        '</assets/product.css>; rel=preload; as=style',
        '</assets/product.js>; rel=preload; as=script',
        '<https://cdn.example.com>; rel=preconnect; crossorigin',
      ],
    });
  }
  next();
}

// app.js
import express from 'express';
import { earlyHints } from './early-hints.middleware.js';

const app = express();
app.use(earlyHints);

app.get('/produkt/:id', async (req, res) => {
  // Här körs långsam databaslogik, men webbläsaren har redan börjat hämta hero.avif
  const product = await db.getProduct(req.params.id);
  res.render('product', { product });
});

app.listen(3000);

Nyckeln är att writeEarlyHints() kallas innan den tunga logiken, inte efter. Om du kallar den efter databasfrågan har du inte sparat något; det slutgiltiga svaret är redan på väg. I mina projekt har jag flyttat detta till en dedikerad middleware som kör före auth-lookup, eftersom auth ofta går mot en långsam session-store som är den verkliga TTFB-boven. Jag råkade själv ut för exakt det här på ett tidigare uppdrag: hela vinsten försvann tills vi flyttade Early Hints-anropet uppåt i middleware-kedjan.

För Fastify använder du reply.raw.writeEarlyHints() direkt, och för Next.js kan du använda next.config.js-optionen experimental.earlyHints som blev stabil i Next 15.3.

Konfigurera Early Hints i nginx och H2O

nginx fick officiellt Early Hints-stöd i version 1.25.4 via direktivet http2_early_hints och http3_early_hints. Här är en minimal konfiguration för en statiskt renderad sida:

http {
    http2_early_hints on;
    http3_early_hints on;

    server {
        listen 443 ssl http2;
        listen 443 quic reuseport;
        server_name example.com;

        location / {
            # Skicka 103 med preload-hints innan proxy_pass når backend
            add_header Link "</assets/app.css>; rel=preload; as=style" always;
            add_header Link "</assets/logo.avif>; rel=preload; as=image; fetchpriority=high" always;

            early_hints_link "/assets/app.css" style;
            early_hints_link "/assets/logo.avif" image;

            proxy_pass http://backend;
        }
    }
}

Direktivet early_hints_link är en syntetisk hjälpare i nginx 1.27+ som formatterar Link-headern korrekt. Om du använder H2O-servern (populär bland performance-teamet) har den haft Early Hints som förstklassig feature sedan 2019 via send-informational: all. H2O var faktiskt en av de första att implementera RFC 8297.

Ett gotcha: om du kör nginx framför en Node.js-backend måste både nginx och Node ha Early Hints påslagna, samt proxy_http_version 1.1 och proxy_pass_request_headers on. Annars buffras 103-svaret av nginx och når aldrig klienten. Testa alltid från riktig produktionstopologi, inte lokal utveckling.

Early Hints på Cloudflare, Fastly och Vercel

CDN-lagret är där de flesta implementationer misslyckas. Inte för att CDN:et saknar stöd, utan för att förvaltarna glömmer att aktivera det.

Cloudflare

Cloudflare stödjer Early Hints på alla planer sedan 2021. Aktivering: gå till Speed → Optimization → Early Hints och slå på. Cloudflare kan antingen vidarebefordra 103 från din origin eller generera egna Early Hints baserat på Link-headers och <link rel="preload">-taggar från tidigare cachade svar. En riktigt smart lösning för statiska sajter.

Fastly

Fastly stödjer 103 via VCL sedan 2023. I VCL lägger du till ett vcl_deliver-block med set resp.http.Link = "..." plus set resp.status = 103 som skickas ut som ett interimt svar innan huvudsvaret. Fastlys Compute@Edge (Rust/JS/Go-runtime) har numera en dedikerad fastly:early-hints-API som är enklare att använda.

Vercel

Vercel aktiverar Early Hints automatiskt på Pro- och Enterprise-planer när din backend skickar 103, inget att konfigurera i UI. För Next.js-appar på Vercel bör du kombinera det med Speculation Rules API för att få både snabbare första sidladdning och omedelbara navigeringar mellan sidor.

Varning: om du kör bakom en gammal reverse proxy (HAProxy <2.4, äldre Envoy-versioner) buffras 103-svaret och når aldrig till klienten. Verifiera med curl -v --http2 https://din-sajt.se/. Du ska se raden < HTTP/2 103 följt av < HTTP/2 200.

Så mäter du Early Hints effekt på LCP och TTFB

Mätning är där skillnaden mellan "vi implementerade Early Hints" och "vi förbättrade LCP" avgörs. Så här mäter jag i produktion:

Fältdata via web-vitals-biblioteket: Skicka LCP-värden till din analytics med ett attribut som säger om Early Hints användes ("early-hints-enabled" som en URL-query eller cookie under A/B-test). Jämför p75 LCP mellan de två grupperna.
Chrome DevTools Network-flik: Med "Show early hints" aktiverat i DevTools syns 103-svaret som en separat rad. Kolla att preload-resurserna startar i det ögonblick 103 mottas, inte när 200 kommer.
WebPageTest: Använd waterfall-vyn och notera "Time to First Byte" separerat från "Start Render". Early Hints minskar avståndet mellan dessa två genom att låta resurshämtning börja tidigare.
Chrome UX Report (CrUX): Om du har en high-traffic-sida, jämför 28-dagars p75 LCP före och efter deploy. På sajter där jag har rullat ut det såg jag typiskt 8–15 % förbättring på p75 LCP.

För INP-tuning parat med Early Hints, se min Long Animation Frames-guide. Early Hints påverkar inte INP direkt, men snabbare kritisk resurshämtning innebär att huvudtråden är ledigare för användarinput tidigare i sidans livscykel.

Vanliga fallgropar och när Early Hints inte hjälper

Efter att ha rullat ut Early Hints på tio+ produktionssajter är det här vad som brukar gå snett:

De vanligaste anti-mönstren:

Preloada för mycket: Fem eller tio resurser i 103-svaret innebär att webbläsaren splittar bandbredd mellan alla. Begränsa till 2–4 verkligt kritiska resurser (hjältebild, kritisk CSS, kritisk JS).
Skicka Early Hints för dynamiska svar som cachas kort tid: Om svaret ändå bara tar 50 ms har du lagt till komplexitet utan vinst.
Blanda fetchpriority=high på flera resurser: Det höjer prioriteten på ingenting. Ha bara en high-priority hint per sida, normalt LCP-bilden.
Glömma cross-origin-attribut: Preload av font-filer eller cross-origin-scripts kräver crossorigin i Link-headern. Utan detta hämtas resursen igen när HTML:en refererar till den.
Testa bara lokalt: Många reverse proxies och load balancers strippar 103. Verifiera alltid från produktionstopologi.

Vanliga frågor

Vad är skillnaden mellan HTTP 103 Early Hints och <link rel="preload">?

Preload i HTML kan bara triggas när webbläsaren har mottagit och börjat parsa HTML-svaret. Early Hints skickar samma information redan innan HTML är genererad. På sidor med hög TTFB (300+ ms) kan Early Hints spara 100–400 ms av väntetid genom att låta preload-hämtningen börja parallellt med backend-arbetet.

Stödjer Cloudflare Early Hints utan att jag behöver skicka 103 från min origin?

Ja. Cloudflare kan automatiskt generera Early Hints baserat på Link-headers och <link rel="preload">-taggar i tidigare cachade svar från din origin. Aktivera "Early Hints" under Speed → Optimization så börjar Cloudflare skicka 103 utan att du behöver ändra backend-koden.

Fungerar Early Hints med HTTP/1.1?

Tekniskt tillåter RFC 8297 103 på HTTP/1.1, men i praktiken kräver alla webbläsarimplementationer HTTP/2 eller HTTP/3 eftersom HTTP/1.1 inte kan multiplexa 103 och 200 rent. Kör du fortfarande HTTP/1.1 till klienter är uppgradering till HTTP/2 en förutsättning.

Ersätter Early Hints HTTP/2 Server Push?

Ja. Chrome tog bort Server Push i version 106 (september 2022) på grund av dåliga prestandaresultat i praktiken. Push ignorerade cachen och skickade ofta resurser klienten redan hade. Early Hints är den moderna ersättaren och respekterar webbläsarcachen, vilket gör tekniken både säkrare och snabbare.

Kan Early Hints skada prestandan?

Ja, om det används fel. Att preloada för många resurser splittrar bandbredd; att preloada resurser som senare visar sig felaktiga slösar användarens data; och att skicka 103 för sidor med redan låg TTFB lägger till komplexitet utan vinst. Mät alltid p75 LCP före och efter aktivering och rulla tillbaka om du inte ser förbättring.