Je klikt op een link en de volgende pagina staat er gewoon. Geen wit scherm, geen wachten. Daar zit vaak geen snellere server achter, maar een browser die vooruit heeft gedacht. Precies dat is Speculative Loading: de browser schat in welke pagina je als volgende opent en laadt die alvast. Gokt hij goed, dan lijkt de nieuwe pagina meteen te verschijnen. Gokt hij mis, dan heeft hij een paar kilobyte voor niets geladen. Sinds WordPress 6.8 zit deze techniek standaard in WordPress ingebouwd, en veel websitebeheerders weten niet eens dat hun site er al gebruik van maakt. Hier lees je hoe het allemaal werkt, wat WordPress standaard instelt en wanneer je zelf moet bijsturen.
Wat is Speculative Loading? Een eenvoudige uitleg
Speculative Loading, in het Nederlands zoiets als speculatief laden, is de verzamelnaam voor technieken waarmee een browser pagina's opvraagt voordat iemand ze echt opent. Speculatief, omdat niemand zeker weet of de bezoeker echt op de link klikt. De browser doet eigenlijk een gok.
Stel je de oplettende barista in je vaste koffiezaak voor. Je loopt binnen en je cappuccino wordt al gezet voordat je iets hebt besteld. Meestal klopt die inschatting en heb je je koffie zonder te wachten. Bestel je bij uitzondering thee, dan is die cappuccino voor niets gemaakt. Zo ongeveer werkt Speculative Loading ook.
Nieuw is het idee niet. Met <link rel="prefetch"> en <link rel="prerender"> bestonden jaren geleden al hints waarmee websites de browser konden aanraden om bepaalde pagina's vooraf te laden, en bibliotheken zoals instant.page of Quicklink voegden hetzelfde met JavaScript toe. Echt betrouwbaar was dat allemaal niet. Chrome heeft het oude rel="prerender" zelfs al lang vervangen door een uitgeklede variant die helemaal niet meer rendert. Als het vandaag over Speculative Loading gaat, bedoelt men daarom bijna altijd de Speculation Rules API die Google in Chrome heeft geïntroduceerd.
En waarom al die moeite? Omdat laadtijd rechtstreeks meetelt in de Core Web Vitals. Wordt een pagina volledig op de achtergrond voorbereid, dan ligt de Largest Contentful Paint (LCP) voor de bezoeker praktisch op nul. Sneller wordt het niet.
Hoe werkt de Speculation Rules API?
De website geeft de browser een paar regels mee. Die staan als JSON in een blok van het type speculationrules. Zo ziet een eenvoudige regel eruit:
<script type="speculationrules">
{
"prerender": [
{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}
]
}
</script>In gewone taal betekent dit: alle links op deze website mogen vooraf worden gerenderd zodra de bezoeker interesse toont, bijvoorbeeld door met de muis even op de link te blijven hangen. Zulke regels, die betrekking hebben op de links in het document, heten Document Rules. Daarnaast zijn er List Rules, waarbij je de browser een vaste lijst met URL's meegeeft, bijvoorbeeld de volgende pagina van een artikelreeks.
Twee dingen maken de API prettig ongecompliceerd. Ten eerste beslist uiteindelijk de browser of hij de regel volgt. Is de accu bijna leeg of het werkgeheugen krap, dan laat hij het gewoon. Ten tweede negeren browsers die de API niet kennen dit blok simpelweg. Er kan dus niets stukgaan. In plaats van in de HTML kun je de regels trouwens ook via een header in het antwoord van de server meesturen (Speculation-Rules), wat vooral CDN's doen.
Prefetch of Prerender: wat is het verschil?
De Speculation Rules API kent twee modi, en het verschil is groter dan de namen doen vermoeden.
Bij Prefetch haalt de browser alleen de kale HTML van de doelpagina op en legt die even opzij. Afbeeldingen, stylesheets en scripts blijven erbuiten en er wordt niets uitgevoerd. Klikt de bezoeker daarna, dan valt het wachten op de server weg, dus in wezen de Time to First Byte. De rest laadt de browser zoals gewoonlijk. Prefetch is goedkoop en heeft nauwelijks bijwerkingen.
Bij Prerender gaat de browser er helemaal voor. Hij laadt de complete pagina inclusief afbeeldingen, CSS en JavaScript in een onzichtbaar tabblad en bouwt die volledig op. Bij de klik verwisselt hij simpelweg de zichtbare pagina. Voor de bezoeker voelt het alsof de pagina er altijd al was. De prijs: meer dataverbruik, meer rekenkracht, en JavaScript draait terwijl de bezoeker de pagina misschien nooit te zien krijgt. Om veiligheidsredenen werkt Prerender standaard alleen voor pagina's op hetzelfde domein.
Als vuistregel geldt: Prefetch is de veilige basisinstelling, Prerender de turbo voor pagina's die met grote waarschijnlijkheid als volgende worden geopend.
Verwar ze allebei niet met preload en preconnect. Die hints versnellen bestanden van de huidige pagina, zoals lettertypen of de grootste afbeelding. Hoe je die goed inzet, lees je in ons artikel over het gebruik van preload en preconnect voor fonts en assets in WordPress.
Wanneer laadt de browser vooraf? De vier niveaus van eagerness
Met eagerness (in het Nederlands zoiets als gretigheid) bepaal je hoe vroeg de browser aan de slag mag. Hoe vroeger, hoe meer tijd je wint, maar hoe vaker hij er ook naast zit.
- immediate: meteen, zodra de browser de regel leest. Alleen zinvol voor een handvol URL's waar je heel zeker van bent.
- eager: bijna net zo vroeg. Chrome heeft het gedrag in de laatste versies verfijnd, waardoor dit niveau tussen immediate en moderate ligt.
- moderate: Op de desktop start de speculatie wanneer de muisaanwijzer ongeveer 200 milliseconden op een link blijft staan, of eerder als de muisknop wordt ingedrukt. Op smartphones, waar geen hover bestaat, gebruikt Chrome andere signalen, zoals het aantikken.
- conservative: pas als de bezoeker echt klikt, of preciezer: op het moment dat de muisknop of vinger omlaaggaat. Tot de klik is afgerond, verstrijkt maar een fractie van een seconde. De voorsprong is klein, maar bijna geen enkele speculatie is voor niets.
Chrome let er bovendien zelf op dat niemand overdrijft. Bij moderate en conservative houdt de browser hooguit twee speculaties tegelijk achter de hand en gooit hij de oudste eruit zodra er een nieuwe bij komt. Bij immediate en eager zijn tot 50 Prefetches en 10 Prerenders toegestaan. In de energiebesparingsmodus, met databesparing ingeschakeld, bij weinig werkgeheugen of als de gebruiker het vooraf laden van pagina's in de instellingen heeft uitgezet, speculeert Chrome helemaal niet. De details beschrijft Google in de documentatie voor Chrome.
Speculative Loading in WordPress: wat er sinds versie 6.8 automatisch gebeurt
Het Performance Team van WordPress testte de functie eerst als losse plugin met de naam Speculative Loading. Die draaide op meer dan 50.000 websites, en volgens een analyse van HTTP Archive en het Chrome UX Report verbeterde bij die websites het slagingspercentage voor de Largest Contentful Paint in de mediaan met zo'n 1,9 procent. Dat klinkt als weinig, maar voor een functie die je geen enkele moeite kost, is het een flinke winst. Met WordPress 6.8 is het geheel in april 2025 in de core opgenomen. De standaardinstelling is bewust terughoudend:
- Modus prefetch, eagerness conservative. Er wordt dus alleen de HTML geladen, en pas wanneer een klik al is begonnen.
- Alleen voor uitgelogde bezoekers. Wie is ingelogd, ziet de werkbalk en vaak persoonlijke inhoud. Zulke pagina's komen in geen enkele cache terecht en zouden duur zijn om vooraf te laden.
- Alleen met Pretty Permalinks. Staat onder Instellingen › Permalinks nog de optie Eenvoudig aan, dan blijft de functie uit.
- Geen URL's met parameters. Alles met een vraagteken in het adres wordt uitgesloten, zoals de zoekfunctie of een link als
?add-to-cart=123in een webshop. Ook het beheergedeelte, de inlogpagina en links metrel="nofollow"zijn taboe. - Uitzonderingen via een klasse. Links met de klasse
no-prefetchof links in een blok met die klasse worden nooit vooraf geladen. De klasseno-prerendersluit alleen het vooraf renderen uit.
Waarom zo voorzichtig? De plugin gebruikte nog Prerender met moderate als standaard en haalde daarmee meer snelheid binnen. Maar bij miljoenen websites met talloze combinaties van thema's en plugins vond het team het risico te groot dat JavaScript draait op pagina's die nooit iemand bezoekt. Zo licht het team het ook toe in de officiële aankondiging. Wil je meer, dan kun je de plugin Speculative Loading nog steeds installeren. Die voegt onder Instellingen › Lezen een eigen sectie toe, waarin je modus en eagerness zonder code aanpast en de functie desgewenst ook voor ingelogde gebruikers inschakelt.
Speculative Loading in WordPress aanpassen of uitschakelen
Zonder plugin gaat het via filters. De volgende stukjes code horen in de functions.php van je Child Theme of, nog beter, in een kleine eigen plugin, zodat ze het wisselen van thema overleven.
Prerender gebruiken in plaats van Prefetch:
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
if ( is_array( $config ) ) {
$config['mode'] = 'prerender';
$config['eagerness'] = 'moderate';
}
return $config;
} );De controle met is_array() is belangrijk. Voor ingelogde gebruikers en websites zonder Pretty Permalinks geeft WordPress hier null door, en dankzij die controle blijft de functie in die gevallen uit.
Bepaalde onderdelen uitsluiten:
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths, $mode ) {
$paths[] = '/go/*';
if ( 'prerender' === $mode ) {
$paths[] = '/winkelwagen/*';
}
return $paths;
}, 10, 2 );Typische kandidaten zijn doorverwijzingen voor affiliatelinks die bij het openen een klik tellen, een winkelwagen of pagina's waarvan de inhoud voortdurend verandert. De paden geef je op ten opzichte van de startpagina, een submap vult WordPress zelf aan. Met de tweede parameter kun je paden voor maar één modus uitsluiten, in het voorbeeld de winkelwagen alleen voor het vooraf renderen.
Losse links uitsluiten: Geef de link of het omringende blok de klasse no-prefetch. In de blokeditor kan dat onder Geavanceerd in het veld voor extra klassen, helemaal zonder code.
Speculative Loading volledig uitschakelen:
add_filter( 'wp_speculation_rules_configuration', '__return_null' );Zet de functie alleen helemaal uit als je daar een concrete reden voor hebt. In de standaardinstelling kost ze zo goed als niets.
Welke nadelen heeft Speculative Loading?
Helemaal gratis is de snelheidswinst niet. Dit zijn de punten die je moet kennen:
Meer belasting voor de server. Elke speculatie is een echte aanvraag. Serveert een Page Cache de pagina direct vanuit de cache, dan merkt de server daar nauwelijks iets van. Zonder cache start elke Prefetch PHP en databasequery's, alsof er een echte bezoeker is. Op krap bemeten Shared Hosting kan een agressieve instelling als immediate of eager daarom merkbaar worden. Voor bezoekers met een beperkte databundel geldt hetzelfde op kleine schaal.
Links die iets in gang zetten. Eigenlijk zou een gewone link nooit iets mogen veranderen. In de praktijk doen sommige links dat toch: uitloglinks, tellers voor affiliatelinks, beoordelingen met één klik of een snelle klik op „In winkelwagen”. Doordat WordPress alle URL's met parameters uitsluit, vangt het veel van die gevallen af, maar nette adressen zoals /go/partner/ niet. Die sluit je het best gericht uit.
Vertekende statistieken. Prefetch voert geen JavaScript uit, dus analysetools zoals Matomo of Google Analytics merken er niets van. Statistieken die uit de logbestanden van de server worden opgebouwd, bijvoorbeeld in het klantenpaneel van veel hostingproviders, tellen de aanvragen mogelijk wel als paginaweergave. Bij Prerender draait JavaScript echt. Google Analytics en Google Publisher Tag wachten uit zichzelf tot de pagina daadwerkelijk wordt getoond. Tools die dat niet doen, tellen bezoeken die nooit hebben plaatsgevonden. Voor je eigen scripts is er een eenvoudige controle:
if (document.prerendering) {
document.addEventListener('prerenderingchange', startTracking, { once: true });
} else {
startTracking();
}Op de server herken je speculatieve aanvragen aan de header Sec-Purpose, met de waarde prefetch of prefetch;prerender.
Inhoud kan even verouderd zijn. Chrome bewaart vooraf geladen pagina's een paar minuten. Bij conservative maakt dat niet uit, omdat de klik meteen volgt. Bij de niveaus die eerder in actie komen, kan een pagina met snel wisselende inhoud, zoals een liveticker, bij het openen al een paar minuten oud zijn.
Welke browsers ondersteunen Speculative Loading?
Chrome ondersteunt de Speculation Rules API volledig, net als Edge, Opera en andere browsers die op Chromium zijn gebouwd. Safari werkt aan een eigen implementatie, maar die zit in recente versies nog verstopt achter een schakelaar voor ontwikkelaars. Firefox ondersteunt de API tot nu toe niet.
Dat klinkt als een gat, maar in de praktijk is het geen probleem. Omdat browsers regels negeren die ze niet begrijpen, profiteert iedereen die Chrome gebruikt, en voor de rest verandert er gewoon niets. Bij de meeste websites is Chrome sowieso veruit het grootste brok. Al begin 2025, dus nog vóór de lancering in WordPress, liep volgens het WordPress Performance Team meer dan 8 procent van alle paginaweergaven in Chrome via Speculation Rules.
Hoe controleer ik of Speculative Loading actief is op mijn website?
Drie snelle manieren:
- Bekijk de broncode. Open je website in een privévenster, zodat je niet bent ingelogd, en zoek in de broncode naar
speculationrules. WordPress zet de regels in de footer. - Gebruik Chrome DevTools. In het tabblad Application vind je onder Background services het onderdeel Speculative loads. Daar zie je de actieve regels, welke URL's vooraf zijn geladen en waarom een speculatie niet is gelukt.
- Controleer de header. Voegt een CDN eigen regels toe, zoals Cloudflare met de functie Speed Brain, dan staan die niet in de HTML maar in de header
Speculation-Rulesvan het antwoord. Er draaien dan mogelijk twee sets regels naast elkaar. Dat kan geen kwaad, maar je moet het wel weten voordat je op één plek aan de knoppen draait en je afvraagt waarom er niets verandert.
Hoe InspectWP je helpt om laadtijd en Resource Hints in de gaten te houden
Het rapport van InspectWP laat je eerst zien welke versie van WordPress er op je website draait. Vanaf 6.8 weet je daarmee dat Speculative Loading standaard actief is voor uitgelogde bezoekers, mits Pretty Permalinks zijn ingeschakeld. In het onderdeel HTML somt het rapport bovendien de klassieke Resource Hints op, dus Prefetch, DNS Prefetch, Preconnect en Prerender, en markeert het vermeldingen die meerdere keren in de broncode staan. Dat wijst vaak op plugins die elkaar in de weg zitten. Duikt daar nog een oude rel="prerender" op, dan is dat een goede aanleiding om over te stappen op de Speculation Rules API. Omdat vooraf geladen pagina's met een cache veel minder kosten, loont het ook om te kijken naar de herkende cacheplugins en de headers van het serverantwoord. Een gratis rapport laat je binnen korte tijd zien waar je website staat.