103 Early Hints: Preload kritieke resources tijdens serverbedenktijd

Laatst beoordeeld door Arjen Karel in maart 2026

Wat zijn 103 Early Hints?

Early Hints is een HTTP-statuscode (103) die de webserver verstuurt vóór de definitieve response. Hiermee vertelt de server vroeg in het laadproces aan de browser dat bepaalde resources, zoals een afbeelding of stylesheet, kritiek zijn voor het renderen van de pagina.

De meeste dynamische pagina's kosten tijd om te genereren. De server bevraagt een database, draait applicatielogica en stelt de HTML samen. Tijdens die verwerkingstijd wacht de browser simpelweg. 103 Early Hints vullen dat gat op door de browser te vertellen wat hij moet ophalen terwijl hij op de echte response wacht.

Early Hints vervangen het verouderde HTTP/2 Server Push, dat Chrome in versie 106 heeft verwijderd. Server Push bundelde resources met de uiteindelijke response en pushte vaak bytes die de browser al in de cache had. Early Hints voorkomen dat probleem omdat ze alleen een hint geven; de browser bepaalt of hij er iets mee doet.

Browserondersteuning

103 Early Hints wordt wereldwijd ondersteund door 93% van de browsers:

• Chrome 103+ en Edge 103+: volledige ondersteuning voor preconnect en preload (sinds juni 2022)
• Firefox 123+: volledige ondersteuning voor preconnect en preload (sinds februari 2024)
• Safari 17+: alleen preconnect. Safari ondersteunt geen preload in 103-responses

De beperking van Safari is belangrijk. Als je Early Hints-strategie volledig leunt op het preloaden van afbeeldingen of lettertypen, hebben Safari-gebruikers daar geen profijt van. Voeg preconnect-hints toe naast preload-hints, zodat Safari op z'n minst de verbinding met je resource-origins opwarmt.

Early Hints werken alleen via HTTP/2 of HTTP/3. Ze werken niet via HTTP/1.1, vanuit iframes of voor non-navigation requests. De browser verwerkt uitsluitend hints voor preload en preconnect; dns-prefetch en prefetch worden niet ondersteund in 103-responses.

Hoe zien 103 Early Hints eruit?

Wanneer een browser een pagina opvraagt, stuurt de server direct een 103-response terug, nog voordat de HTML volledig is gegenereerd. Deze response vertelt de browser om te starten met het ophalen van de LCP-afbeelding en stylesheet:

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Ondertussen genereert de server de pagina. Zodra deze klaar is, verstuurt hij de definitieve response:

HTTP/2 200 OK
Content-Length: 1234
[de rest van de response]

Tegen de tijd dat de browser de 200-response ontvangt, is hij al begonnen met het downloaden van de afbeelding en stylesheet. Die voorsprong is wat de Largest Contentful Paint sneller maakt.

Hoe verstuur je 103 Early Hints

Je hebt drie hoofdopties, van eenvoudig tot maximale controle.

Cloudflare (het makkelijkst)

Als je Cloudflare voor performance al gebruikt, is het inschakelen van Early Hints slechts één schakelaar omzetten. Navigeer naar Speed > Settings > Content Optimization en zet Early Hints aan. Het is beschikbaar op alle pakketten, inclusief de gratis versie.

Cloudflare cacht de Link-headers van de 200-responses van je origin. Bij volgende verzoeken verstuurt het die gecachte headers als een 103-response voordat het verzoek naar je origin wordt doorgestuurd. Je levert de hints aan door Link-headers vanuit je applicatie te versturen:

header("Link: </image.webp>; rel=preload; as=image", false);
header("Link: </style.css>; rel=preload; as=style", false);

NGINX (native sinds 1.29.0)

NGINX voegde in versie 1.29.0 (juni 2025) native ondersteuning voor 103 Early Hints toe. De early_hints-directive stuurt 103-responses van je backend door naar de client:

map $http_sec_fetch_mode $early_hints {
    navigate $http2$http3;
}

server {
    location / {
        early_hints $early_hints;
        proxy_pass http://backend.example.com;
    }
}

De sec-fetch-mode-map zorgt ervoor dat hints alleen worden verstuurd voor navigatieverzoeken via HTTP/2 of HTTP/3. Je backend-applicatie moet de 103-response genereren; NGINX geeft deze alleen door.

Apache (2.4.58+)

Apache kan zelf 103-responses genereren via mod_http2. Schakel dit in met de H2EarlyHints-directive en definieer de resources voor de hints:

H2EarlyHints on
H2EarlyHint Link "</style.css>;rel=preload;as=style"
H2EarlyHint Link "</image.webp>;rel=preload;as=image"

In tegenstelling tot NGINX genereert Apache de 103-response op serverniveau zonder dat je applicatie deze hoeft te produceren.

Wanneer Early Hints helpen (en wanneer niet)

103 Early Hints zijn het meest effectief wanneer je server merkbaar tijd nodig heeft om te reageren: dynamische pagina's die databases bevragen, API's aanroepen of templates renderen. Hoe trager de Time to First Byte, hoe meer tijd de browser heeft om de hints te verwerken.

Early Hints leveren minder voordeel op wanneer:

• Je server binnen 100 ms reageert. Als de TTFB al snel is, is er geen gat voor de browser om te vullen. Richt je in plaats daarvan op resource-prioritering in je HTML.
• Pagina's vanuit de cache worden geserveerd. Een volledig gecachte HTML-response laadt zo snel dat de 103-response nauwelijks een voorsprong heeft.
• Je te veel resources hint. Meer dan 10 resources hinten verzadigt de verbinding en kan de boel vertragen. Shopify ontdekte dat agressief hinten op mobiele apparaten leidde tot een verslechtering van de TTFB, FCP en LCP. Houd het bij 2 tot 4 kritieke resources.

Ondanks de browserondersteuning van 93% blijft de adoptie laag. Volgens de 2025 Web Almanac gebruikt slechts zo'n 5% van de topwebsites 103 Early Hints. De grootste barrière is weten welke resources je voor elke pagina moet hinten. De meeste CMS'en doen dit niet automatisch.

Hoe controleer je of Early Hints werken

Open Chrome DevTools, ga naar het Network-paneel en herlaad de pagina. Klik op het documentverzoek en bekijk de response-headers. Als Early Hints werken, zie je een 103-status voor de 200 in het timingsoverzicht.

Vanaf de command line kun je dit verifiëren met curl:

curl -v --http2 https://example.com 2>&1 | grep "< HTTP"

Je zou zowel een 103- als een 200-response moeten zien.

Testresultaten

Ik heb twee scenario's getest om de impact op de First Contentful Paint en Largest Contentful Paint te meten.

1. Early Hints alleen op de LCP-afbeelding

De LCP-afbeelding verscheen 35% eerder op het scherm met 103 Early Hints, vergeleken met een reguliere preload in de HTML.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image

2. Early Hints met een grote stylesheet en de LCP-afbeelding

Het toevoegen van een CSS-bestand van 85 kB aan de hints maakte het verschil nog duidelijker. De FCP verbeterde van 1,8 seconden naar 1,4 seconden en de LCP verbeterde van 3,2 seconden naar 2,0 seconden.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Deze cijfers komen overeen met wat Cloudflare heeft gemeten bij meer dan 100.000 klanten: een LCP-verbetering van 6% in het 50e percentiel en 16% in het 75e percentiel op desktop. Shopify zag een LCP-verbetering van 500 ms op p50 tijdens Black Friday en Cyber Monday. De grootste winst zit bij pagina's met trage serverreactietijden. Dit is precies het moment waarop Early Hints de meeste tijd hebben om hun werk te doen.

Early Hints en TTFB

Er is een meetnuance waar je je bewust van moet zijn. Sinds Chrome 133 bevat de responseStart-timing van de browser (die de meeste tools gebruiken om de TTFB te rapporteren) ook de 103-response. Dit betekent dat je gerapporteerde TTFB daalt na het inschakelen van Early Hints, ook al is de daadwerkelijke verwerkingstijd van je server niet veranderd.

Als je de serververwerkingstijd afzonderlijk wilt meten: Chrome 133 introduceerde een nieuwe firstResponseHeadersStart-timestamp. Deze rapporteert wanneer de definitieve 200-response-headers aankomen. Real User Monitoring-tools die beide waarden bijhouden geven je het complete plaatje: hoeveel tijd Early Hints de browser hebben bespaard, en hoe lang je server er daadwerkelijk over deed om te reageren.