Kort fortalt: Med Early Hints kan serveren svare med status 103 og Link:-headers, mens den stadig arbejder på det endelige 200-svar med HTML. Browseren får dermed et “forvarsel” om fx preload eller preconnect til kritiske domæner, før HTML-body er færdiggenereret og sendt.
Hvad er Early Hints i HTTP-terminologi?
Normalt forventer du et enkelt svar: klienten beder om /side, serveren svarer 200 OK med HTML. Med Early Hints indsættes et intermediært svar: først 103 Early Hints med Link:-relationer (typisk rel=preload eller rel=preconnect), derefter - når backend er færdig - det fulde 200 med dokumentet. Det er ikke en erstatning for HTML; det er et ekstra hop i protokollen, som browseren kan bruge til at parallelisere arbejde.
Hvorfor det kan hjælpe performance
Uden Early Hints starter browseren ofte først med at opdage kritiske ressourcer, når den har nok af HTML til at parse den og finde <link> og <img>. Hvis din TTFB er høj fordi PHP, database eller edge-logik bruger tid, “ligger” klienten og venter uden at kunne gøre noget konstruktivt. Early Hints udnytter den ventetid: mens du stadig bygger HTML, kan hints fortælle browseren at den allerede må åbne forbindelse til font-CDN, eller begynde at hente et kendt hero-billede.
Det har størst effekt når:
- du allerede ved hvilke 1–3 ressourcer der er kritiske (fx LCP-billede, webfont, kritisk CSS-fil);
- og din flaskehals er tid til HTML, ikke tid til at hente de store assets (så du flytter arbejde ud over den tid HTML ventes).
Hvad Early Hints ikke løser
- Dårlig prioritering i selve siden - hvis du loader ti tunge scripts i
<head>før indhold, er problemet stadig strukturen. - Forkerte eller skiftende URL’er - hints skal pege på de rigtige endelige URL’er; ellers spilder du båndbredde og kan skade LCP.
- Manglende understøttelse - hvis CDN eller browser ignorerer 103, sker der ingenting; du skal ikke bygge strategien kun på hints.
- Erstatning for caching - Cache-Control og edge caching på HTML og assets er stadig fundamentet.
Krav og faldgruber i praksis
- Server og CDN skal kunne sende 103 korrekt (nogle proxies stripper intermediære svar).
- Hints skal være konsistente med det HTML der til sidst kommer: preload af en URL der ikke bruges, er ren overhead.
- For mange hints kan konkurrere med det første kritiske download - samme princip som ved at spamme preload i HTML.
- Personlige/sessions-afhængige sider gør hints sværere: du kan ikke altid forudsige samme kritiske ressource for alle brugere.
Eksempel (konceptuelt)
Tænk en side hvor HTML først er klar efter 400 ms server-side, men du ved at LCP altid er /assets/hero.avif på et bestemt CDN. Uden hints venter browseren 400 ms før den opdager hero. Med Early Hints kan 103 bede om preload af hero og preconnect til CDN, så download og evt. TLS kan starte parallelt med HTML-generering - ikke bagefter.
Relaterede begreber og næste skridt
- Resource hints - overblik over
dns-prefetch,preconnect,preload,prefetch - preconnect, dns-prefetch, HTTP/2
- Critical request chain - se hvor kæden knækker uden Early Hints
- CDN - ofte der Early Hints konfigureres i produktion
Typiske misforståelser
- “Vi har Early Hints, så vi behøver ikke optimere billeder.” - Forkert. Hints flytter tidspunkter; de fjerner ikke tunge filer.
- “103 er altid hurtigere.” - Hvis HTML er billig at generere, er gevinsten lille; overhead kan endda være mærkbart i edge cases.
FAQ
Er Early Hints det samme som at sende link-tags i HTML?
Nej. Early Hints kommer som et tidligt HTTP-svar (103) med Link-headers, før det endelige dokument er klar. Effekten ligner nogle gange preload/preconnect i HTML, men timing og transport er anderledes - og det kræver server/CDN-understøttelse.
Fikser Early Hints en høj TTFB?
Ikke i sig selv. Det hjælper browseren med at udnytte tiden *mens* serveren stadig regner på HTML, ved at starte parallelle forbindelser eller downloads. Den tid der går før første byte af dokumentet, er stadig et TTFB-problem du bør adskille.
Eksterne kilder
Specifikation (RFC) og MDNs reference til HTTP 103 Early Hints.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
Forbedr TTFB med caching, edge cache og hurtigere serverrespons
Lær hvordan du reducerer TTFB med page cache, edge cache, korrekt cache strategi og bedre serverrespons på HTML.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
Cache-Control forklaret: sådan bruger du caching til lavere TTFB
Lær hvordan Cache-Control påvirker HTML, CSS, JavaScript og billeder, og få en praktisk gennemgang af caching, TTFB og klassiske fejl.
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
