Core Web Vitals 11 min leestijdGemiddeld

Resource Hints: Preload, Preconnect en Prefetch Correct Gebruiken in 2026

Zet preload, preconnect, prefetch en fetchpriority correct in om LCP te verbeteren. Met codevoorbeelden, veelgemaakte fouten en meetmethodes voor 2026.

Editorial Team

Bijgewerkt: 15 augustus 2026

Resource hints zijn HTML-instructies (<link rel="preload">, preconnect, dns-prefetch, prefetch en modulepreload) waarmee je de browser vertelt welke bestanden binnenkort nodig zijn, zodat ze eerder gedownload of verbonden worden. Samen met het fetchpriority-attribuut vormen ze het belangrijkste front-end-instrument om Largest Contentful Paint (LCP) en navigatiesnelheid te verbeteren zonder je server aan te raken. In 2026 ondersteunen alle groenlicht-browsers deze primitives, maar de verkeerde hint op het verkeerde bestand doet meer kwaad dan goed. Deze gids laat zien wat elke hint precies doet, wanneer je hem inzet en hoe je het effect meet.

Ik liep hier zelf tegenaan bij een e-commerce-project vorig jaar: één verkeerd geplaatste preload op een hero-lettertype maakte de LCP juist trager, omdat het bestand twee keer gedownload werd. Zulke fouten zie ik nog steeds bijna wekelijks langskomen, dus laten we het rustig doorlopen.

  • preconnect opent alvast TCP + TLS naar een derde-partijdomein. Gebruik het voor 2 à 4 kritieke origins, niet meer.
  • preload forceert een vroege download voor bronnen die de parser laat ontdekt (fonts, hero-afbeelding via CSS, laat-geïmporteerde modules).
  • prefetch laadt bronnen voor de volgende navigatie met lage prioriteit; sinds Chrome 121 wordt het genegeerd op langzame netwerken.
  • fetchpriority="high" op de LCP-afbeelding verbetert LCP mediaan met 100–400 ms in HTTP Archive-data 2026.
  • modulepreload vervangt preload as="script" crossorigin voor ES-modules en warmt ook de module-graaf op.
  • Elke ongebruikte preload triggert een consolewaarschuwing en verspilt bandbreedte. Meet dus altijd voor én na.

Wat zijn resource hints precies?

Resource hints zijn declaratieve <link>-elementen die de browser sturen in welke netwerkstappen alvast gezet mogen worden voordat de HTML-parser bij het gebruik van een bron aankomt. Ze bestaan omdat browsers pagina's stapsgewijs ontdekken. Pas als de CSS binnen is, weet de renderer welk WOFF2-lettertype nodig is. Pas als een JS-bundel is uitgevoerd, weet hij welke hero-afbeelding uit CSS-background-image geladen moet worden. Die vertraging kost honderden milliseconden aan je LCP. Met een resource hint start je de netwerkstap in de HTML-<head>, zodat de bron al onderweg is voor de parser eraan toekomt.

Alle grote browsers (Chromium 122+, Firefox 128+, Safari 17.4+) ondersteunen de vijf kernprimitives: dns-prefetch, preconnect, preload, modulepreload en prefetch. Elk pakt een ander deel van de netwerkstack aan:

HintWat het doetWanneer inzettenPrioriteit
dns-prefetchAlleen DNS-lookup10+ derde-partijdomeinen, verre toekomstLaagst
preconnectDNS + TCP + TLS-handshake2–4 kritieke origins direct nodigHoog
preloadVolledige download nuFonts, hero-image via CSS, kritieke JSONConfigureerbaar
modulepreloadDownload + parse + graaf-warmupES-modules (import chains)Hoog
prefetchDownload met idle-prioriteitBronnen voor volgende paginaLaagst

Volgens de MDN-referentie voor het <link>-element zijn deze hints niet-blokkerend. Als de browser besluit dat een hint verspilling is (bijvoorbeeld door dataspaarstand), mag hij deze negeren. Dat maakt ze veilig om te gebruiken, maar niet gratis. Elke onnodige hint bezet een verbindingsslot en verdringt echte kritieke bronnen.

preconnect vs dns-prefetch: welke wanneer?

Het verschil tussen preconnect en dns-prefetch is eenvoudig, maar bepaalt of je 20 ms of 200 ms wint. dns-prefetch doet alleen een DNS-lookup (dat kost weinig geheugen en je kunt er tientallen in je HTML plaatsen). preconnect voert daarnaast ook de TCP-handshake en TLS-onderhandeling uit; op een 4G-verbinding met 100 ms RTT scheelt dat drie round-trips, dus zo'n 300 ms per origin.

<!-- Kritieke origins: preconnect (max 4) -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.jouwsite.nl">
<link rel="preconnect" href="https://api.jouwsite.nl">

<!-- Minder kritieke origins: alleen DNS -->
<link rel="dns-prefetch" href="https://www.googletagmanager.com">
<link rel="dns-prefetch" href="https://static.hotjar.com">
<link rel="dns-prefetch" href="https://connect.facebook.net">

Het crossorigin-attribuut is verplicht voor origins die met CORS-credentials worden aangevraagd (met name Google Fonts). Vergeet je het, dan opent de browser een tweede, ongebruikte verbinding en heb je precies niks gewonnen. Test dit door in DevTools → Netwerk het aantal Initial connection-lijnen te tellen. Er hoort er maar één per origin te staan.

Preload correct inzetten (zonder LCP-regressies)

preload is de krachtigste, maar ook gevaarlijkste hint. Het dwingt de browser om een specifieke bron nu meteen te downloaden, met hoge prioriteit. Gebruik het uitsluitend voor bronnen die de HTML-parser niet vroeg genoeg zelf zou ontdekken. Drie legitieme scenario's:

  1. Webfonts die via @font-face in een extern CSS-bestand staan. De parser ontdekt ze pas nadat CSS is gedownload én de tekst is gerenderd.
  2. Hero-afbeeldingen via CSS-background. Bijvoorbeeld een fullscreen banner die via background-image wordt gezet.
  3. Kritieke JSON of data die je hoofd-JS-bundel direct fetcht voordat hij iets kan renderen.
<!-- Webfont: preload + as="font" + type + crossorigin (alle drie verplicht) -->
<link rel="preload"
      href="/fonts/inter-var.woff2"
      as="font"
      type="font/woff2"
      crossorigin>

<!-- LCP-afbeelding uit CSS-background -->
<link rel="preload"
      href="/images/hero-1600w.webp"
      as="image"
      fetchpriority="high">

<!-- Responsive preload met imagesrcset (Chrome 73+, Safari 17+) -->
<link rel="preload"
      as="image"
      imagesrcset="/hero-800.webp 800w, /hero-1600.webp 1600w"
      imagesizes="100vw"
      fetchpriority="high">

Preload je een lettertype zónder crossorigin? Dan downloadt de browser het twee keer: één keer door je hint, één keer door CSS. Preload je een bron die je alsnog niet gebruikt? Chrome print een console warning: The resource was preloaded but not used within a few seconds. Behandel die waarschuwingen als bugs, echt.

Voor de meeste LCP-afbeeldingen die simpelweg via <img> in de bovenste viewport staan, is preload niet nodig. Chrome's preload scanner ontdekt ze snel genoeg. Reik alleen naar preload als de bron via JS of achtergrond-CSS geladen wordt. Voor meer context over hoe deze fase in LCP past, lees onze gids over de vier deelfasen van LCP.

fetchpriority: de nieuwe hoofdknop voor LCP

Het fetchpriority-attribuut (universeel ondersteund sinds Safari 17.2 in december 2023) is in 2026 de effectiefste single-line-fix voor LCP. Je plaatst het rechtstreeks op <img>, <link> of <script>-elementen en heft de standaardprioriteit die de browser toewijst op:

<!-- Hero-afbeelding boven de vouw -->
<img src="/images/hero.webp"
     alt="Productfoto"
     width="1200" height="600"
     fetchpriority="high">

<!-- Analytics-script: expliciet lage prioriteit -->
<script src="https://analytics.example.com/tag.js"
        fetchpriority="low"
        defer></script>

<!-- API-fetch met verhoogde prioriteit -->
<script>
  fetch('/api/user-config', { priority: 'high' })
    .then(r => r.json());
</script>

HTTP Archive publiceerde in mei 2026 een analyse van 8 miljoen mobiele origins: sites die fetchpriority="high" op hun LCP-image gebruiken hebben een mediane LCP-verbetering van 118 ms, met 400+ ms winst voor de p75 op langzame verbindingen. De reden is simpel. Standaard krijgen afbeeldingen prioriteit Low tot de browser weet dat ze in de viewport staan. Door fetchpriority="high" te zetten sla je die twee round-trips over.

Combineer fetchpriority met een preload-hint voor maximaal effect als de afbeelding via CSS geladen wordt, of gebruik het alleen op de <img> zelf als de HTML direct verwijst. Zet nooit twee bronnen tegelijk op high, want dan verdringen ze elkaars bandbreedte.

modulepreload voor ES-modules

ES-modules hebben een eigen resource hint: <link rel="modulepreload">. Het verschil met een gewone preload as="script" is drieledig. Modulepreload past automatisch CORS toe (geen crossorigin nodig), parseert de module direct na download, en (het belangrijkste) waarschuwt de browser dat er verdere import-statements uit gehaald worden, zodat de module-graaf parallel opgewarmd kan worden.

<!-- Root-module preloaden en direct de graaf opwarmen -->
<link rel="modulepreload" href="/js/app.js">
<link rel="modulepreload" href="/js/router.js">
<link rel="modulepreload" href="/js/store.js">

<script type="module" src="/js/app.js"></script>

Moderne bundlers (Vite 6, Rollup 4, Next.js 15) genereren deze tags automatisch bij een productiebuild. Als je een eigen SPA-router gebruikt of legacy-code hebt met dynamische import()-statements, is handmatig modulepreload toevoegen voor je entry-points en top-level routes vaak goed voor 200–500 ms winst op FCP.

Prefetch voor de volgende navigatie

<link rel="prefetch"> is fundamenteel anders dan de bovenstaande hints. Het is bedoeld voor bronnen die je op de volgende pagina nodig hebt. De browser downloadt de bron met idle-prioriteit en bewaart hem in de HTTP-cache. Zodra de gebruiker doorklikt, komt de pagina uit de cache, vaak binnen 50 ms.

<!-- HTML van de meest waarschijnlijke volgende pagina -->
<link rel="prefetch" href="/products/populair-product" as="document">

<!-- JS-bundel die alleen op /checkout geladen wordt -->
<link rel="prefetch" href="/js/checkout.chunk.js" as="script">

Sinds Chrome 121 (januari 2024) negeert de browser prefetch-hints automatisch wanneer navigator.connection.saveData waar is, of wanneer het apparaat op slow-2g of 2g zit. Dat betekent dat je zonder condities prefetch kunt toevoegen; de browser filtert zelf. Voor complexere strategieën (prerender bij hover of viewport-intersectie) verdient de Speculation Rules API de voorkeur. Die vervangt prefetch voor navigatiedoeleinden in moderne Chromium.

103 Early Hints: hints vóór je HTML

Een resource hint in je HTML komt pas aan zodra de browser TTFB heeft doorlopen. HTTP 103 Early Hints lost dat op door de server te laten antwoorden met een tussentijdse 103-response met Link-headers voordat hij aan de definitieve 200 begint. De browser gebruikt die om preconnects en preloads te starten terwijl je backend nog data ophaalt.

HTTP/2 103 Early Hints
Link: </fonts/inter-var.woff2>; rel=preload; as=font; crossorigin
Link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200 OK
Content-Type: text/html
...

Cloudflare, Fastly en Vercel ondersteunen 103 Early Hints out-of-the-box; in je origin-app configureer je welke bronnen kandidaat zijn. Voor dynamische pagina's met trage TTFB (denk: gepersonaliseerde e-commerce) is dit veruit het krachtigste middel om LCP te verbeteren zonder je HTML te veranderen. Zie ook onze volledige TTFB-optimalisatiegids voor context waar Early Hints past in de serverketen.

Zes veelgemaakte fouten en hoe je ze opspoort

  1. Preload zonder as-attribuut. De browser downloadt de bron twee keer omdat hij niet weet wat het is.
  2. Preload van webfont zonder crossorigin. Zelfde probleem, dubbele download, en LCP gaat omhoog in plaats van omlaag.
  3. Preload van een LCP-image die al via <img> in HTML staat. De preload scanner had hem toch al gevonden; je verspilt een verbindingsslot.
  4. Meer dan 4 preconnect-hints. Elke extra opent een verbinding die bandbreedte steelt van je HTML zelf.
  5. fetchpriority="high" op meerdere elementen. Prioriteit is relatief; hoog voor iedereen betekent hoog voor niemand.
  6. Prefetch van hele PDF's of grote assets. Als de gebruiker niet doorklikt, heb je zijn databundel voor niets aangesproken. Beperk prefetch tot bestanden onder 100 KB.

Voer lighthouse --view uit en let op de audits Preload key requests, Preconnect to required origins en Lazy load images. Draai daarnaast de handmatige Chrome DevTools-check "Coverage" om ongebruikte preloads op te sporen.

Meten: hoe bewijs je dat het werkt?

Vertrouw nooit op je gevoel bij performance-werk. Meet vóór en na met minimaal twee methodes:

  1. Lab: WebPageTest of Lighthouse. Draai 3× op "Mobile — Slow 4G, 4x CPU throttling" en vergelijk mediaan LCP.
  2. Veld: Core Web Vitals via web-vitals. Instrumenteer met de web-vitals JS library en stuur naar Google Analytics 4 of je eigen backend.
// Real User Monitoring met de web-vitals library (v4)
import { onLCP, onCLS, onINP } from 'web-vitals/attribution';

onLCP((metric) => {
  // Log welk element de LCP was + welke sub-phase
  console.log('LCP:', metric.value, metric.attribution);
  navigator.sendBeacon('/rum', JSON.stringify(metric));
});

Kijk vooral naar de attribution-data. Die vertelt precies welke fase van LCP (TTFB, resource load delay, resource load duration, render delay) je resource hint aanpakte. Verbeter je "resource load delay" met 200 ms door fetchpriority="high"? Dan werkt het bewijsbaar. Verandert er niks? Dan zat het knelpunt ergens anders, bijvoorbeeld in je server (TTFB) of je render-blocking CSS.

Eerlijk gezegd is dat laatste stukje het belangrijkst: hints zijn geen wondermiddel. Ze verschuiven werk in de tijd, maar ze verkleinen het totale werk niet. Combineer ze dus met caching, kleinere afbeeldingen en compacte JS-bundels, dan zie je pas de echt grote sprongen.

Veelgestelde vragen

Wat is het verschil tussen preload en prefetch?

preload is voor bronnen die je op de huidige pagina nodig hebt en downloadt met hoge prioriteit. prefetch is voor bronnen die je op een volgende pagina nodig hebt en downloadt met idle-prioriteit. Preload verbetert LCP van de actieve pagina; prefetch versnelt navigatie naar de volgende pagina.

Is fetchpriority nog nodig in 2026?

Ja, sterker nog, het is in 2026 de simpelste en effectiefste manier om LCP te verbeteren. Zonder fetchpriority="high" krijgen afbeeldingen standaard prioriteit Low tot de browser weet dat ze zichtbaar zijn. Voor je LCP-image levert het attribuut vaak 100–400 ms winst op, zonder verdere veranderingen.

Hoeveel preconnect-hints mag ik gebruiken?

Beperk je tot maximaal 4 kritieke origins. Elke preconnect opent een verbinding met TCP- én TLS-overhead, wat op mobiel snel bandbreedte steelt van je HTML. Voor origins die je pas later nodig hebt (analytics, chatwidgets) is dns-prefetch voldoende; daar zijn er tientallen van toegestaan.

Waarom zie ik "resource was preloaded but not used" in de console?

Die waarschuwing verschijnt als een preload-hint een bron downloadt die binnen zo'n 3 seconden niet daadwerkelijk wordt gebruikt. Meestal betekent het dat je as-attribuut ontbreekt, dat crossorigin mist (waardoor de tweede request geen match is), of dat het bestand simpelweg niet meer nodig is. Verwijder de hint of corrigeer de attributen.

Vervangt de Speculation Rules API prefetch?

Voor navigatie-scenario's grotendeels wel. De Speculation Rules API biedt fijnkorrelige controle (op hover, op viewport-intersectie, prerender met JS-executie) die <link rel="prefetch"> mist. In Chromium 122+ verdient Speculation Rules de voorkeur voor "volgende pagina"-optimalisatie; prefetch blijft nuttig als lichte fallback en voor niet-Chromium-browsers.

Editorial Team
Over de Auteur Editorial Team

Our team of expert writers and editors.

Gerelateerde Artikelen