Preload, prefetch en preconnect: wanneer ze echt helpen
Resource hints zijn nuttig wanneer ze aansluiten op echte browserknelpunten. Blind gebruikt voegen ze prioriteitsruis toe en maken ze pagina’s soms trager.
Inhoudsopgave
- Resource hints zijn geen magie
- Wat de browser al goed doet
- Preload: voor resources van de huidige pagina die te laat worden ontdekt
- Preload en LCP-afbeeldingen
- Prefetch: voor de volgende pagina, niet deze
- Preconnect: voor dure verbindingen met belangrijke origins
- DNS-prefetch: het lichtere neefje
- Hoe je beslist: een praktische workflow
- 1. Identificeer het knelpunt
- 2. Voeg één hint tegelijk toe
- 3. Controleer neveneffecten op prioriteit
- 4. Verifieer headers en caching
- Veelvoorkomende fouten
- Te veel preloaden
- Prefetch gebruiken voor vereiste resources
- Preconnecten naar elke derde partij
- Mobiele omstandigheden vergeten
- Een eenvoudige beslissingstabel
- De rustige regel
Resource hints zijn geen magie
preload, prefetch en preconnect worden vaak behandeld als een performance-checklist. Voeg een paar tags toe aan de <head>, draai Lighthouse opnieuw, voel je beter. Zo werken ze niet.
Deze hints zijn instructies voor de laadpijplijn van de browser. Ze kunnen helpen wanneer jij iets weet dat de browser niet vroeg genoeg kan ontdekken. Ze kunnen schaden wanneer je gokt, niet-kritiek werk te veel prioriteit geeft, of verbindingen opwarmt die gebruikers nooit nodig hebben.
De korte versie:
- Gebruik
preloadvoor resources die nodig zijn voor de huidige pagina, maar te laat worden ontdekt. - Gebruik
prefetchvoor waarschijnlijke resources voor toekomstige navigatie, niet voor essentiële onderdelen van de huidige pagina. - Gebruik
preconnectvoor belangrijke externe origins waarbij het opzetten van de verbinding een echte vertraging is.
De praktische vraag is niet “welke hint is het snelst?” maar “waar wacht de browser op, en kan deze hint die wachttijd wegnemen?”
Wat de browser al goed doet
Moderne browsers zijn geen passieve bestandsdownloaders. Ze parsen HTML, scannen vooruit naar resources, kennen prioriteiten toe, hergebruiken verbindingen, stellen werk uit dat niet zichtbaar is en passen zich aan netwerkomstandigheden aan.
Dat betekent dat resource hints selectief moeten zijn. Als een stylesheet, script, afbeelding of lettertype al vroeg wordt ontdekt en de juiste prioriteit krijgt, doet een hint mogelijk niets. Erger nog: hij kan concurreren met resources die belangrijker zijn.
Kijk vóór het toevoegen van hints naar een waterfall-trace in DevTools of een labrapport. Als je Lighthouse gebruikt, begin dan met de diagnostiek in plaats van de score; we hebben een aparte gids over het lezen van een Lighthouse-rapport zonder paniek — maar let erop dat de juiste URL hoofdlettergevoelig is, dus gebruik zo nodig het gelinkte artikel vanuit de navigatie van je site.
Het echte bewijs is meestal op drie plekken zichtbaar:
- Een kritieke resource start laat omdat de browser die laat ontdekt.
- Een verbinding met een belangrijke origin kost merkbaar tijd vóór de eerste request.
- Een resource voor de volgende pagina is zeer voorspelbaar en goedkoop op te halen tijdens inactieve tijd.
Als geen van die dingen waar is, is een hint waarschijnlijk decoratie.
Preload: voor resources van de huidige pagina die te laat worden ontdekt
preload zegt tegen de browser: “Haal deze resource nu op, omdat de huidige pagina hem nodig zal hebben.”
Een typisch voorbeeld is een webfont waarnaar vanuit CSS wordt verwezen. De browser moet HTML downloaden, de CSS ontdekken, de CSS downloaden, die parsen, het lettertype ontdekken en daarna het lettertype aanvragen. Als dat lettertype belangrijk is voor tekst above the fold, kan de ontdekking laat genoeg zijn om layout shifts of vertraagde tekstweergave te veroorzaken.
Een preload kan die request naar voren halen:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>Het attribuut as is belangrijk. Het vertelt de browser om welk soort resource het gaat, wat invloed heeft op prioriteit, caching, content security policy en requestheaders. Lettertypen hebben meestal ook crossorigin nodig, zelfs wanneer ze vanaf dezelfde site worden geleverd, omdat het ophalen van lettertypen de CORS-modus gebruikt.
Goede kandidaten voor preload zijn onder meer:
- Het primaire webfont dat wordt gebruikt voor zichtbare tekst.
- Een hero-afbeelding die het Largest Contentful Paint-element is en niet vroeg ontdekbaar is.
- Een kritiek CSS-bestand dat indirect wordt geladen.
- Een module of script dat heel vroeg nodig is, maar verborgen zit achter een ander script.
Slechte kandidaten voor preload zijn onder meer:
- Elke font weight in het designsysteem.
- Afbeeldingen below the fold.
- Scripts die niet nodig zijn voor de initiële rendering.
- Resources die de browser al in de eerste HTML-chunk ontdekt.
Preload is krachtig omdat het de prioriteit op de huidige pagina beïnvloedt. Daarom is het ook gemakkelijk verkeerd te gebruiken. Als je vijf grote assets preloadt, help je de browser niet meer. Je gaat ermee in discussie.
Lettertypen zijn het klassieke geval. Eén primair fontbestand preloaden kan helpen. Zes weights en italics preloaden maakt het meestal erger. Als lettertypen je knelpunt zijn, ruim dan eerst de fontset op; onze gids over waarom webfonts nog steeds de gemakkelijkste performancewinst zijn op de meeste sites behandelt die opschoning uitgebreider.
Preload en LCP-afbeeldingen
Een LCP-afbeelding preloaden kan nuttig zijn wanneer de afbeelding niet zichtbaar is in de initiële HTML. Veelvoorkomende oorzaken zijn CSS-achtergrondafbeeldingen, client-rendered componenten of responsive image-logica die laat verschijnt.
Maar als je hero-afbeelding al in de HTML staat als een <img> met een zinnige srcset, sizes, afmetingen en zonder lazy loading, kan de browser hem waarschijnlijk snel vinden. In dat geval is fetchpriority='high' mogelijk passender dan preload, afhankelijk van de pagina.
Een goede test: als de image request laat start in de waterfall en het LCP-element wordt, overweeg dan preload. Als hij vroeg start maar langzaam downloadt, is het probleem grootte, formaat, CDN-gedrag of serverlatentie — niet ontdekking. Voor keuzes rond afbeeldingsformaten, zie wanneer AVIF beter is dan WebP en wanneer niet.
Prefetch: voor de volgende pagina, niet deze
prefetch zegt tegen de browser: “Deze resource is misschien binnenkort nodig, maar niet nu meteen.”
Dat onderscheid is belangrijk. Prefetch heeft bewust een lage prioriteit. De browser kan hem tijdens inactieve tijd ophalen en bewaren voor later gebruik. Hij kan hem ook overslaan bij slechte verbindingen, databesparende modi of geheugendruk.
Gebruik prefetch wanneer de intentie van de gebruiker sterk genoeg is om de volgende resource waarschijnlijk te maken.
Goede kandidaten voor prefetch zijn onder meer:
- De volgende stap in een checkout over meerdere pagina’s.
- Zoekresultaten nadat een gebruiker een zoekopdracht begint te typen, als de volgende route voorspelbaar is.
- Documentatiepagina’s die vanuit een inhoudsopgave zijn gelinkt wanneer de gebruiker actief nabije content leest.
- Route chunks in een single-page app nadat een gebruiker een navigatie-item aanwijst of focust.
Slechte kandidaten voor prefetch zijn onder meer:
- Je volledige navigatiestructuur.
- Grote video’s of afbeeldingsgalerijen.
- Scripts van derden “voor het geval dat”.
- Pagina’s die gebruikers zelden als volgende bezoeken.
Prefetch is waar terughoudendheid loont. Een resource die wordt opgehaald en nooit gebruikt, is niet gratis. Hij verbruikt bandbreedte, servercapaciteit, energie en mogelijk gebruikersdata. Op mobiele netwerken kan speculatief ophalen actief onvriendelijk zijn.
Voor veel sites is de beste prefetch-strategie gebaseerd op intentie. Prefetch de pricing-pagina niet zodra de homepagina laadt. Prefetch hem wanneer de gebruiker het pricing-menu opent, over de pricing-link hovert of bijna bij een call-to-action komt die sterk op navigatie wijst.
Onthoud ook dat browsergedrag varieert. Sommige browsers zijn conservatief met prefetch; sommige privacy-instellingen verminderen of schakelen speculatief laden uit. Behandel prefetch als een opportunistische verbetering, niet als een correctheidsmechanisme.
Preconnect: voor dure verbindingen met belangrijke origins
preconnect zegt tegen de browser: “Begin nu met het opzetten van een verbinding met deze origin.”
Dat kan DNS-lookup, TCP-verbinding en TLS-onderhandeling omvatten. Voor externe origins kan deze setup honderden milliseconden duren, vooral op netwerken met hoge latency. Als de pagina binnenkort een kritieke request van die origin nodig heeft, kan preconnect de latere request sneller maken.
Voorbeeld:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Goede kandidaten voor preconnect zijn onder meer:
- Een font-origin die wordt gebruikt voor render-blocking tekst.
- Een kritieke API-origin die nodig is tijdens de initiële interactie.
- Een CDN-origin die assets above the fold levert.
- Een betaal- of identity provider die direct na een gebruikersactie nodig is.
Slechte kandidaten voor preconnect zijn onder meer:
- Analytics- en advertentie-endpoints die niet gebruikerskritiek zijn.
- Origins die alleen in sommige sessies worden gebruikt.
- Lange lijsten met derden.
- Same-origin resources, waarvoor de browser de verbinding al heeft of binnenkort opent.
Preconnect heeft een aanhoudkost. Open sockets verbruiken geheugen en netwerkresources. Browsers sluiten ongebruikte verbindingen, maar dat maakt onnodige preconnects niet onschadelijk.
Een nuttige regel: preconnect naar hooguit één of twee externe origins met hoge zekerheid op een pagina. Als je in de verleiding komt er meer toe te voegen, heeft je third-party-architectuur waarschijnlijk meer behoefte aan review dan je hints aan uitbreiding.
DNS-prefetch: het lichtere neefje
Je kunt ook dns-prefetch tegenkomen:
<link rel='dns-prefetch' href='https://example-cdn.com'>Dit lost alleen de domeinnaam op. Het opent geen TCP- of TLS-verbinding. Het is goedkoper dan preconnect, maar ook minder behulpzaam.
DNS-prefetch kan redelijk zijn voor externe origins met lagere zekerheid waarbij volledige preconnect te agressief voelt. In de praktijk: als een origin kritiek is en zeker binnenkort wordt gebruikt, geef dan de voorkeur aan preconnect. Als het alleen mogelijk is, gebruik dan DNS-prefetch of doe niets.
Hoe je beslist: een praktische workflow
Begin met meten, niet met tags.
1. Identificeer het knelpunt
Open een performance-trace en zoek naar late ontdekking. Startte de request voor het lettertype, de hero-afbeelding of het script pas nadat een ander bestand was gedownload en geparsed? Dat is een kandidaat voor preload.
Als een request pas start na een lange DNS/TCP/TLS-setup naar een externe origin, is dat een kandidaat voor preconnect.
Als de huidige pagina in orde is maar de volgende navigatie voorspelbaar traag is, kan prefetch helpen.
2. Voeg één hint tegelijk toe
Resource hints beïnvloeden elkaar. Voeg er één toe, test hem en behoud hem alleen als de waterfall verbetert en gebruikersgerichte metrics niet achteruitgaan.
Let er bij preload op of de gehinte resource daadwerkelijk snel wordt gebruikt. Chrome kan waarschuwen wanneer een preloaded resource niet kort na het laden wordt gebruikt. Neem die waarschuwing serieus.
3. Controleer neveneffecten op prioriteit
Een preload kan bandbreedte wegtrekken van CSS, JavaScript of afbeeldingen die belangrijker zijn. Een preconnect kan een verbindingsslot bezetten. Een prefetch kan achtergrondverkeer toevoegen.
De juiste uitkomst is niet “het gehinte bestand start eerder.” De juiste uitkomst is “de pagina wordt merkbaar beter voor gebruikers.” Kijk waar mogelijk naar LCP, INP, CLS en real-user monitoring.
4. Verifieer headers en caching
Hints kunnen worden verzonden in HTML of HTTP Link-headers. Headers zijn nuttig wanneer de server vroeg weet wat de pagina nodig zal hebben, maar ze zijn moeilijker informeel te inspecteren. Als je debugt of een hint daadwerkelijk aanwezig is in productie, zijn ruwe headers belangrijk; dit is precies het soort situatie dat wordt behandeld in onze gids voor het debuggen van redirects en HTTP-headers.
Caching is ook belangrijk. Een resource preloaden met niet-overeenkomende credentials, een verkeerde as of andere URL-parameters kan dubbele downloads veroorzaken. Dat is een van de meest voorkomende manieren waarop een goedbedoelde preload een performance-bug wordt.
Veelvoorkomende fouten
Te veel preloaden
Als alles kritiek is, is niets dat. Beperk preload tot resources die nodig zijn voor initiële rendering of onmiddellijke interactiviteit. Een typische pagina zou nul tot drie preloads moeten hebben, geen twintig.
Prefetch gebruiken voor vereiste resources
Prefetch heeft een lage prioriteit en is optioneel. Gebruik het niet voor assets die door de huidige pagina vereist zijn. Als de pagina het nu nodig heeft, overweeg dan preload of normale HTML-ontdekking.
Preconnecten naar elke derde partij
Pagina’s met veel third parties hebben vaak tien of meer externe origins. Naar allemaal preconnecten creëert ruis. Kies de één of twee die zowel kritiek als voorspelbaar gebruikt zijn.
Mobiele omstandigheden vergeten
Resource hints zijn het waardevolst op tragere verbindingen, maar daar ook het gevaarlijkst. Een verspilde prefetch op een snelle desktopverbinding is een afrondingsfout. Op een beperkt mobiel abonnement is het een slechte ruil.
Een eenvoudige beslissingstabel
| Situatie | Beste hint | Waarom | |---|---:|---| | Kritiek lettertype ontdekt via CSS | preload | De huidige pagina heeft het nodig, ontdekking is laat | | Hero-afbeelding verborgen achter CSS of client rendering | preload | Kan LCP verbeteren als de afbeelding laat start | | Waarschijnlijke volgende route na gebruikersintentie | prefetch | Helpt toekomstige navigatie zonder de huidige pagina te blokkeren | | Kritieke externe font/API-origin | preconnect | Haalt verbindingsopbouw uit het kritieke pad | | Mogelijke maar onzekere externe origin | dns-prefetch of geen | Lagere kosten, lagere zekerheid | | Afbeelding below the fold | geen | Laat lazy loading en browserprioriteit hun werk doen |
De rustige regel
Resource hints werken het best wanneer ze saai en specifiek zijn. Eén lettertype. Eén LCP-afbeelding. Eén belangrijke externe origin. Eén waarschijnlijke volgende route na intentie.
Ze werken slecht wanneer ze als optimisme worden gebruikt: misschien heeft de gebruiker dit nodig, misschien moet de browser dat ophalen, misschien betekenen meer hints meer snelheid.
Browsers optimaliseren al agressief. Het is niet jouw taak om elke request te micromanagen. Het is jouw taak om de paar gevallen te corrigeren waarin de browser op het juiste moment informatie mist.
Veelgestelde vragen
Moet ik al mijn lettertypen preloaden?
Is prefetch veilig te gebruiken voor elke interne link?
Wat is het verschil tussen preconnect en dns-prefetch?
Kunnen resource hints Core Web Vitals verbeteren?
Moeten resource hints in HTML of HTTP-headers worden toegevoegd?
Bronnen & verder lezen
