Preconnect vs prefetch vs preload — wanneer welk?

Wat MKB moet weten

• preconnect: bereid een verbinding voor (DNS + TCP + TLS). Gebruik voor fonts.googleapis.com, externe API's. preload: laad asset NU met hoge priority. Gebruik voor LCP-image, kritieke font. prefetch: laad asset bij idle voor volgende pagina. Gebruik voor next-page navigatie-doelen. Misbruik kost meer performance dan winst — gebruik max 2-3 per type per pagina.

Waarom dit voor MKB telt

Resource-hints zijn instructies aan de browser hoe hij beter kan plannen welke resources eerst geladen moeten worden. Het lijkt techniek voor specialisten, maar het effect op Core Web Vitals is direct meetbaar. Een hovenier in De Ronde Venen met een PageSpeed-score van 72 op mobiel kan met drie correcte hints naar 88 springen — voldoende om uit het oranje in het groen te zakken, waarmee Google de site beter waardeert.

preconnect — voorbereiding van een verbinding

Bij elke HTTP-request naar een extern domein moet de browser drie stappen doorlopen voordat hij data kan ontvangen: DNS-lookup (welke IP hoort bij dit domein?), TCP-handshake (verbinding opzetten) en TLS-handshake (HTTPS-encryptie). Totaal kost dit 100-300ms per nieuw domein. preconnect doet deze drie stappen alvast, voordat je echt een resource opvraagt.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Voor Google Fonts: twee preconnects nodig (één voor de CSS, één voor de WOFF-bestanden). Bij Cloudflare-CDN of een eigen subdomein voor afbeeldingen ook één preconnect. Aanbevolen maximum: 3-4 preconnects per pagina. Meer kost CPU-cycli die niet alle bezoekers zich kunnen veroorloven op oudere mobiele apparaten.

preload — laad asset met hoge prioriteit

preload zegt tegen de browser: "Begin nu met het downloaden van deze asset, het is kritiek voor de pagina." Het verschilt van een gewone <img>-tag of CSS-import: preload start het downloaden direct, zonder te wachten tot de HTML-parser bij de tag aankomt.

<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

Twee belangrijke use cases voor MKB: de hero-afbeelding (vaak de LCP-element) en het hoofdfont. Beide laden hierdoor 100-300ms eerder. Voor sites met dynamische content (een blog of webshop) is preload van het LCP-element per pagina-template essentieel voor goede Core Web Vitals.

Belangrijk: as-attribuut is verplicht. Vergeten = browser weet niet wat hij downloadt = warning in console + geen voordeel.

prefetch — vooruitkijken naar de volgende pagina

prefetch is anders: het downloadt resources met lage prioriteit zodra de browser idle is. Doel: als de bezoeker straks doorklikt naar een andere pagina, is die al deels geladen. Voor MKB-sites met duidelijke conversie-paden (homepage → diensten → contact) is dit een snelheidsboost op de tweede klik.

<link rel="prefetch" href="/contact">
<link rel="prefetch" href="/prijzen">

Voorzichtig met datagebruik: bezoekers op trage mobiele verbindingen of beperkte data-bundels kunnen dit als verspilling ervaren. Modern frameworks (Next.js, Astro) gebruiken intersection-observer om prefetch alleen te activeren wanneer een link in beeld komt. Voor handmatige sites: prefetch alleen op de 2-3 belangrijkste vervolgpagina's.

dns-prefetch — de oudere broer van preconnect

Voor browsers die geen preconnect ondersteunen (zeldzaam in 2026) is dns-prefetch een lichtere fallback. Het doet alleen de DNS-lookup, niet de TCP- en TLS-handshakes. Voor MKB-sites in 2026 niet meer praktisch nodig — alle moderne browsers ondersteunen preconnect.

<link rel="dns-prefetch" href="https://fonts.googleapis.com">

De volgorde-regel: welke hint waar?

Een veel gemaakte fout is alle hints door elkaar gebruiken. De juiste volgorde, van hoge naar lage urgentie:

1. preload voor kritieke resources van het eigen domein (hero-image, kritiek font).
2. preconnect voor externe domeinen waar je resources vandaan haalt (Google Fonts, CDN, API).
3. prefetch voor next-page navigatie.
4. dns-prefetch als fallback voor preconnect bij oudere browsers (zelden nodig).

Per pagina maximaal 8 hints in totaal. Meer hints = meer CPU-werk voor de browser bij de initiële parse = paradoxaal langzamer.

Veelgemaakte fouten

1. preconnect zonder crossorigin op fonts.gstatic.com. Browser opent twee verbindingen in plaats van één. Verspilling.
2. preload zonder as-attribuut. Browser weet niet wat hij downloadt — geen winst, wel console warning.
3. preload van resources die toch niet snel gebruikt worden. Tegenovergesteld effect: andere kritieke resources worden vertraagd.
4. prefetch op 20 links. Verspilling van bandbreedte van de bezoeker. Bij mobiel-only bezoekers irritant.
5. Hints voor third-party-scripts die toch async laden. Geen toegevoegde waarde.
6. preconnect naar domeinen die je niet meer gebruikt. Komt voor bij oude WordPress-installaties met verwijderde plug-ins.

Hoe je het instelt per platform

• WordPress. Yoast en Rank Math voegen preconnect-hints naar Google Fonts automatisch toe. Custom hints via theme's functions.php of een plug-in als "Pre* Party".
• Webflow. Custom code in "Project Settings" → "Custom Code" → "Head Code". Volledig handmatig.
• Shopify. theme.liquid bewerken. Plaats hints na de <head>-opening.
• Statische HTML (zoals deze site). Per pagina handmatig in <head>, of via template bij build-tools.
• Next.js en Astro. Eigen Link- of head-component. Hints automatisch geoptimaliseerd voor de huidige route.

Wat een goede set hints oplevert in cijfers

Voor een gemiddelde MKB-site die Google Fonts gebruikt en een hero-afbeelding heeft, levert de combinatie preconnect (Google Fonts) + preload (hero-image + hoofdfont) typisch een verbetering op van:

• LCP: -300 tot -500ms (van bv. 2.8s naar 2.3s)
• FCP: -100 tot -200ms
• TTI: -50 tot -100ms

Voor een hovenier in Vinkeveen die op het randje van Core Web Vitals zit is dit voldoende om in de groene zone te komen — direct gunstig voor Google-ranking.

Checklist: 10 stappen voor performance-hints

1. Identificeer je LCP-element via PageSpeed Insights (vaak hero-image of grote H1).
2. Voeg preload toe voor dat LCP-element met fetchpriority="high".
3. Voeg preload toe voor je hoofdfont (WOFF2-formaat).
4. Voeg preconnect toe voor fonts.googleapis.com en fonts.gstatic.com (crossorigin).
5. Voeg preconnect toe voor andere externe domeinen waar je resources van laadt.
6. Identificeer 2-3 vaak-geklikte vervolgpagina's, voeg prefetch toe.
7. Verwijder oude/onnodige hints van vorige plug-ins of theme-iteraties.
8. Test in Chrome DevTools Network-tab: zie je de hints werken (priority kolom)?
9. Hertest PageSpeed Insights mobiel én desktop.
10. Documenteer welke hints op welke pagina-template staan voor toekomstig onderhoud.

Hoe Keurmeesters dit toepast

Bij Keurmeesters — NL energielabel-bureau, live mei 2026 — staan op elke postcode-gegenereerde pagina drie hints: preconnect naar Cloudflare-CDN (waar het rapport-blad vandaan komt), preload van het hoofdfont, en prefetch naar /aanvraag/ (de logische volgende stap voor een bezoeker die zijn postcode invult). Resultaat: LCP 1.8s op mobiel, PageSpeed 96/100 op mobiel. Hints alleen leverden 250ms snelheidswinst op de gemiddelde pageload — meetbaar effect op zowel conversie als ranking in zoekresultaten.

De relatie met Core Web Vitals en SEO-ranking

Resource-hints zijn een direct middel om de Core Web Vitals te verbeteren. De drie metrics die Google sinds 2021 in ranking meeneemt:

• LCP (Largest Contentful Paint) — wanneer is het grootste element zichtbaar? Preload van het LCP-element is hier het meest effectief.
• INP (Interaction to Next Paint) — hoe snel reageert de site op een klik of swipe? Goed gebruik van resource-hints houdt de main thread vrij voor interactie.
• CLS (Cumulative Layout Shift) — verschuift de pagina tijdens laden? Preload van fonts voorkomt FOIT/FOUT en stabiliseert layout.

Voor een hovenier of klusbedrijf in De Ronde Venen waar de concurrentie in Google-zoekresultaten verzadigd is, kan een sprong van 70 naar 90 op PageSpeed het verschil zijn tussen positie 5 en 2 in lokale zoekresultaten. Resource-hints zijn een directe en goedkope route naar die verbetering.

Onderhoud na de eerste implementatie

Resource-hints zijn geen set-and-forget. Bij elke significante site-wijziging (nieuwe hero-foto, nieuw font, nieuwe externe service) check je of de hints nog logisch zijn. Standaard ritme: na elke kwartaalupdate van content of bij elke nieuwe campagne. Twee minuten werk in Chrome DevTools per pagina-template volstaat om dit netjes te houden.

Een veelvoorkomende valkuil: oude hints blijven staan na verwijdering van een resource. Een hovenier die zijn site overzet van Google Fonts naar zelf-gehoste fonts moet vergeten preconnect-hints naar fonts.googleapis.com verwijderen — anders bezet de browser onnodig CPU-cycli. Bij elke majeure wijziging kort scannen op verouderde hints. Een halve dag onderhoud per jaar volstaat voor een gemiddelde MKB-site om dit fundament intact te houden.

Wat doe je als je site al snel is?

Sommige MKB-eigenaren met al goed presterende sites (PageSpeed 90+) twijfelen of extra hints zinvol zijn. Twee adviezen: blijf monitoren bij elke site-update (een nieuwe plug-in kan stilletjes performance verlagen), en richt je dan op andere optimalisaties zoals image-optimalisatie of caching-strategie. Diminishing returns boven 90 zijn reëel — investeer je tijd waar het echte effect zit.

Voor sites onder PageSpeed 75 daarentegen zijn hints meestal de snelste route naar verbetering. Een halve dag werk, blijvend effect, geen content-wijzigingen nodig en geen herontwerp. Een goedkope quick-win die direct rendement oplevert.

fetchpriority — een nieuwe speler in 2024-2026

Sinds Chrome 101 (mei 2022) en Firefox 119 (oktober 2023) bestaat het fetchpriority-attribuut. Hiermee kun je per resource expliciet de prioriteit aangeven: "high", "low" of "auto". Krachtig in combinatie met preload:

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<img src="/hero.webp" fetchpriority="high">

Voor LCP-optimalisatie is dit een gamechanger. De browser weet nu niet alleen dat je het bestand wilt preloaden, maar ook dat het de hoogste prioriteit krijgt. Voor MKB-sites in 2026 standaard om dit toe te voegen op het LCP-element. Werkt op alle moderne browsers, valt elegant terug bij oudere browsers.

Tegenovergesteld kun je fetchpriority="low" gebruiken voor below-fold afbeeldingen of niet-kritieke scripts. Browser besluit zelf op basis van het signaal, maar volgt het advies meestal.

De relatie met andere performance-optimalisaties

Resource-hints zijn één laag in de complete performance-stack. Voor een volledig snelle MKB-site werk je samen aan:

• Image-optimalisatie. WebP- of AVIF-formaat, juiste resolutie per device, lazy-loading voor below-fold afbeeldingen.
• Caching. Cache-Control headers op static assets (1 jaar), korte cache op HTML.
• Code-splitting. Alleen de JavaScript die voor de huidige pagina nodig is laden.
• CDN. Resources serveren vanaf het dichtstbijzijnde datacenter.
• HTTP/3. Modern protocol voor lagere latency.
• Resource-hints. Browser informeren over kritieke resources.
• Critical CSS. Bovenste-zichtbare CSS inline in <head> voor instant rendering.

Resource-hints alleen leveren 200-500ms. Gecombineerd met de andere optimalisaties: 1-3 seconden snelheidswinst. Dat is het verschil tussen een gemiddelde site en een snelle, ranking-vriendelijke site die bovenin Google staat.

De anatomie van een trage MKB-site

Een typisch voorbeeld uit een audit van een Mijdrecht-bedrijf zonder hints: de site laadt Google Fonts via twee externe domeinen, het hoofdscript komt van een CDN, het hero-element is een 2MB-foto, en de pagina linkt naar /contact/ en /diensten/ die elk weer eigen assets laden. Resultaat zonder hints: LCP 3.4s, FCP 2.1s, PageSpeed 64/100 op mobiel.

Stappenplan dat we volgen om dit te repareren:

1. Hero-foto converteren naar WebP-formaat — bestandsgrootte van 2MB naar 280KB.
2. Preload toevoegen voor de hero-foto met fetchpriority="high".
3. Preconnect toevoegen voor fonts.googleapis.com en fonts.gstatic.com (met crossorigin).
4. Preconnect toevoegen voor het CDN-domein.
5. Preload toevoegen voor het hoofdfont (WOFF2).
6. Prefetch toevoegen voor /contact/ omdat dat de vaakst geklikte vervolgpagina is.
7. Onnodige preload-hints van vorige plug-ins verwijderen.
8. Hertest in PageSpeed.

Resultaat na de fix: LCP 1.6s, FCP 1.1s, PageSpeed 91/100 op mobiel. Vier uur werk, blijvend effect op ranking. Voor een MKB-site die op het randje van de Core Web Vitals-drempel zit is dit een directe ranking-boost.

Wat resource-hints kosten op je server

Een vaak ongeziene kant: resource-hints werken aan de browser-kant, niet op je server. Je serverbelasting verandert niet door extra hints. Wel wijzigt het downloadpatroon — bij hoge prefetch-volumes kunnen bezoekers méér resources downloaden dan ze daadwerkelijk nodig hebben. Voor sites op hosting met bandbreedte-limieten (sommige goedkope shared hosters in NL) iets om in de gaten te houden. Voor sites op Vercel of Cloudflare Pages: geen praktisch issue, ruime bandbreedte standaard.

Hoe moderne frameworks dit automatiseren

Voor sites op moderne frameworks (Next.js, Astro, Nuxt, SvelteKit) regelt het framework automatisch een deel van de resource-hints. Bijvoorbeeld:

• Next.js — Image-component prefetcht automatisch, Link-component prefetcht next-page bij hover of when in viewport.
• Astro — built-in prefetch via data-astro-prefetch-attribuut op links, configureerbaar per pagina.
• Nuxt — automatische prefetch op alle Nuxt-Links in viewport, uit te schakelen voor specifieke links.
• SvelteKit — data-sveltekit-preload-data-attribuut activeert prefetch op hover.

Voor MKB-sites op moderne frameworks: hoeft weinig gehandmatigd. Voor sites op klassieke WordPress, statische HTML of legacy CMS: alle hints handmatig. DesignCheck-builds gebruiken Astro voor de meeste statische sites omdat dit automatisch optimaliseert plus rauwe HTML uitlevert (Lighthouse-vriendelijk en goed indexeerbaar).

Veelvoorkomende scenario's per branche

Per type bedrijf hebben de hints een andere focus:

• Hoveniers en klusbedrijven. Belangrijkste optimalisatie: preload van de hero-foto (vaak een groot project-overzicht). Preconnect naar Google Fonts. Prefetch naar /contact/.
• Boekhouders en advocaten. Preload van het portretfoto van de eigenaar of de service-illustratie. Prefetch naar /diensten/ en /contact/.
• Restaurants. Preload van menu-afbeelding of sfeerfoto. Prefetch naar /reserveren/.
• Webshops. Preload van eerste productfoto. Preconnect naar betaalprovider-domein (Mollie, Stripe). Prefetch naar checkout-flow.
• Energielabel-bureaus. Preconnect naar BAG-API. Preload van rapport-template-afbeelding.
• SaaS/techbedrijven. Preload van product-screenshot in hero. Preconnect naar analytics-domein, betaalprovider.

Tools om hints te valideren

• Chrome DevTools Network-tab. Zie per resource de priority (High/Medium/Low) en of hij via preload of preconnect is getriggerd.
• PageSpeed Insights. Toont concrete adviezen onder "Opportunities": "Preconnect to required origins", "Preload key requests".
• WebPageTest.org. Geeft een complete waterval-grafiek waaruit je precies kunt zien wanneer welke resource start met laden.
• Lighthouse. Onderdeel van Chrome DevTools, geeft per pagina een score plus concrete adviezen.
• web.dev/measure. Google's web-vitals-tool met uitleg per metric.

Voor een snelle audit zonder licentie zijn Chrome DevTools + PageSpeed Insights ruim voldoende. Beide gratis, samen 20 minuten werk voor een gemiddelde MKB-site.

Wat doe je vandaag?

Wat krijg je bij DesignCheck?

Elke Rebuild (€3.995) en Premium (€6.995) wordt opgeleverd met geoptimaliseerde hints per pagina-template. Refresh (€1.995) voegt ontbrekende preconnect- en preload-hints toe aan bestaande sites. Vanuit Mijdrecht voor klanten in De Ronde Venen, Wilnis, Vinkeveen, Utrecht en daarbuiten (remote werkbaar tot wereldwijd). Performance-hints zijn standaard onderdeel — geen aparte factuur.

Veelgestelde vragen

Verder lezen