103 Early Hints: Preload kritieke resources tijdens de verwerkingstijd van de server

Laatst gecontroleerd door Arjen Karel in maart 2026

Wat zijn 103 Early Hints?

Early Hints is een HTTP-statuscode (103) die wordt verstuurd voordat de webserver de definitieve response stuurt. Hiermee laat de server de browser al vroeg in het laadproces weten dat bepaalde resources, zoals een afbeelding of stylesheet, cruciaal zijn voor het renderen van de pagina.

De meeste dynamische pagina's kosten tijd om te genereren. De server bevraagt een database, voert applicatielogica uit en bouwt de HTML op. Tijdens die verwerkingstijd zit de browser gewoon te wachten. 103 Early Hints vullen dat gat: ze vertellen de browser wat hij kan 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 bij de definitieve response en pushte vaak bytes die de browser al in de cache had. Early Hints voorkomen dat probleem: ze geven alleen een hint, waarna de browser zelf beslist of hij er iets mee doet.

Browserondersteuning

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

• 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

Die beperking van Safari telt. Leunt je Early Hints-strategie volledig op het preloaden van afbeeldingen of fonts, dan hebben Safari-gebruikers er niets aan. Voeg naast preload-hints ook preconnect-hints toe, zodat Safari de verbinding met je resource-origins in elk geval alvast opzet.

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?

Vraagt een browser een pagina op, dan stuurt de server direct een 103-response terug, nog voordat de HTML klaar is. Deze response vertelt de browser om alvast te beginnen met het ophalen van de LCP-afbeelding en de 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 die klaar is, stuurt 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 het downloaden van de afbeelding en de stylesheet al begonnen. Die voorsprong maakt de Largest Contentful Paint sneller.

Hoe verstuur je 103 Early Hints?

Je hebt drie opties, van de eenvoudigste tot die met de meeste controle.

Cloudflare (het makkelijkst)

Gebruik je al Cloudflare voor performance, dan zet je Early Hints aan met één schakelaar. Ga naar Speed > Settings > Content Optimization en zet Early Hints aan. Dit zit in elk abonnement, ook in het gratis pakket.

Cloudflare cachet de Link-headers uit de 200-responses van je origin. Bij volgende requests stuurt Cloudflare die gecachete headers als een 103-response terug, nog voordat het request wordt doorgestuurd naar je origin. Je geeft de hints mee door Link-headers vanuit je applicatie te sturen:

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 heeft in versie 1.29.0 (juni 2025) native ondersteuning voor 103 Early Hints toegevoegd. 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 dat hints alleen worden verstuurd bij navigatie-requests via HTTP/2 of HTTP/3. Je backend-applicatie moet de 103-response zelf genereren; NGINX geeft hem alleen door.

Apache (2.4.58+)

Apache kan met mod_http2 zelf 103-responses genereren. Activeer dit met de H2EarlyHints-directive en geef de gewenste resources op:

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

In tegenstelling tot NGINX regelt Apache de 103-response op serverniveau. Je applicatie hoeft die dus niet zelf te genereren.

Wanneer Early Hints helpen (en wanneer niet)

103 Early Hints werken het best als 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 op te pakken.

Early Hints leveren minder op als:

• Je server binnen 100ms reageert. Is de TTFB al snel, dan valt er voor de browser geen gat te vullen. Richt je dan liever op resource prioritization in je HTML.
• Pagina's uit de cache worden geserveerd. Een volledig gecachete HTML-response laadt zo snel dat de 103-response nauwelijks een voorsprong heeft.
• Je te veel resources hint. Meer dan 10 resources hintten verzadigt de verbinding en kan de boel juist vertragen. Shopify zag dat agressief hintten op mobiele apparaten leidde tot slechtere scores voor TTFB, FCP en LCP. Houd het bij 2 tot 4 kritieke resources.

Ondanks 93% browserondersteuning blijft de adoptie laag. Volgens de 2025 Web Almanac gebruikt slechts zo'n 5% van de topsites 103 Early Hints. Het grootste knelpunt is bepalen welke resources je per pagina moet hintten. De meeste CMS'en doen dat niet automatisch.

Hoe controleer je of Early Hints werken?

Open Chrome DevTools, ga naar het Network-paneel en herlaad de pagina. Klik op het document-request en bekijk de response-headers. Werken de Early Hints, dan zie je in het timing-overzicht een 103-status vóór de 200.

Vanaf de command line kun je dit controleren met curl:

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

Je hoort zowel een 103- als een 200-response te zien.

Testresultaten

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

1. Early Hints op alleen de LCP-afbeelding

Met 103 Early Hints verscheen de LCP-afbeelding 35% eerder op het scherm dan bij een gewone 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

Een CSS-bestand van 85 kb toevoegen aan de hints maakte het verschil nog groter. De FCP verbeterde van 1,8 naar 1,4 seconden en de LCP ging van 3,2 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 sluiten aan bij wat Cloudflare mat bij meer dan 100.000 klanten: op desktop een LCP-verbetering van 6% op het 50e percentiel en 16% op het 75e percentiel. Shopify zag tijdens Black Friday en Cyber Monday een LCP-verbetering van 500 ms op p50. De grootste winst zie je op pagina's met trage server-responsetijden. Precies daar hebben Early Hints de meeste tijd om hun werk te doen.

Early Hints en TTFB

Let op een nuance bij de meting. Sinds Chrome 133 telt de browser de 103-response mee in de responseStart-timing (die de meeste tools gebruiken om de TTFB te rapporteren). Dit betekent dat je gerapporteerde TTFB daalt na het aanzetten van Early Hints, terwijl de verwerkingstijd van je server niet is veranderd.

Moet je de verwerkingstijd van de server apart meten: Chrome 133 introduceerde een nieuwe firstResponseHeadersStart-timestamp die aangeeft wanneer de headers van de definitieve 200-response binnenkomen. Real User Monitoring-tools die beide waarden bijhouden, geven je het complete plaatje: hoeveel tijd Early Hints de browser bespaarden én hoe lang je server echt nodig had om te antwoorden.