Speculation Rules API: Complete Gids 2026

De Speculation Rules API: Razendsnel Navigeren met Prerendering en Prefetching in 2026

Het web wordt steeds sneller. Maar gebruikers? Die verwachten meer dan ooit. Een pagina die langer dan twee seconden laadt voelt in 2026 als een eeuwigheid -- en dat is geen overdrijving. De Speculation Rules API is wat mij betreft een van de krachtigste browserfeatures die de afgelopen jaren is geïntroduceerd. Deze API stelt je als ontwikkelaar in staat om op een gestructureerde, declaratieve manier aan de browser te vertellen welke pagina's waarschijnlijk als volgende bezocht worden. De browser kan die dan alvast ophalen of zelfs volledig renderen op de achtergrond.

Vroeger gebruikten we <link rel="prefetch"> en <link rel="prerender"> om pagina's vooraf te laden. Alleen hadden die oudere technieken flinke beperkingen. De oude prerender-hint werd door Chrome al in 2018 teruggeschaald tot een NoState Prefetch -- wat in de praktijk betekende dat er geen volledige pagina-rendering meer plaatsvond. En eerlijk gezegd boden die link-hints ook weinig controle over wanneer en onder welke omstandigheden de speculatie moest plaatsvinden.

De Speculation Rules API vervangt deze verouderde mechanismen volledig en biedt een veel rijkere aanpak. 't Is specifiek ontworpen voor Multi-Page Applications (MPA's), de architectuur die het overgrote deel van het web aandrijft. In plaats van losse link-elementen gebruik je nu een JSON-configuratie die de browser vertelt welke pagina's speculatief geladen moeten worden, met welke prioriteit, en onder welke voorwaarden. Dit artikel duikt diep in alle aspecten van deze API -- van de basis tot geavanceerde configuratie.

Hoe Werkt de Speculation Rules API?

De Speculation Rules API biedt twee fundamenteel verschillende acties waarmee de browser toekomstige navigaties kan voorbereiden: prefetch en prerender. Het verschil begrijpen tussen die twee is essentieel, want de keuze die je maakt heeft directe impact op zowel snelheid als resourceverbruik.

Prefetch: Bronnen Vooraf Ophalen

Bij een prefetch-actie haalt de browser de HTML-response van de opgegeven URL op en slaat die op in de cache. Dit omvat het volledige HTTP-verzoek inclusief de response-headers en de HTML-body. Maar -- en dit is belangrijk -- de browser doet verder niets met die response. Geen subresources ophalen (geen CSS, geen JavaScript, geen afbeeldingen), geen parsing, en al helemaal geen JavaScript uitvoeren.

Het voordeel? Wanneer de gebruiker daadwerkelijk naar die pagina navigeert, is de initiële netwerkvertraging voor het ophalen van de HTML volledig geëlimineerd. De browser kan direct beginnen met het verwerken van de al gecachte response.

Prefetch is de veiligste optie. Er treden geen bijwerkingen op omdat er geen JavaScript wordt uitgevoerd op de doelpagina. Analytics-scripts, formuliersubmissies of andere acties worden niet per ongeluk getriggerd. Het bandbreedteverbruik blijft ook beperkt -- alleen de HTML zelf wordt opgehaald.

Prerender: Volledige Pagina Vooraf Renderen

En hier wordt het pas echt interessant.

Prerender gaat aanzienlijk verder dan prefetch. Bij een prerender-actie opent de browser in feite een verborgen tabblad waarin de volledige doelpagina wordt geladen en gerenderd. Alle subresources worden opgehaald, alle CSS verwerkt, de DOM-boom opgebouwd, de layout berekend, en alle JavaScript uitgevoerd. De pagina wordt letterlijk volledig opgebouwd in het geheugen, klaar om direct weergegeven te worden.

Wanneer de gebruiker vervolgens naar die pagina navigeert, wordt de voorgerenderde pagina vrijwel onmiddellijk zichtbaar. De navigatie voelt instant aan, met laadtijden die vaak onder de 100 milliseconden liggen. Dat levert een ervaring op die vergelijkbaar is met een native applicatie -- zelfs voor content-rijke pagina's met complexe layouts en veel JavaScript.

Het nadeel? Prerender verbruikt meer resources (en dat is best logisch als je erover nadenkt). De browser moet geheugen, CPU en netwerkbandbreedte besteden aan het volledig renderen van een pagina die de gebruiker mogelijk nooit bezoekt. Bovendien wordt JavaScript uitgevoerd, wat gevolgen kan hebben voor analytics en andere scripts met bijwerkingen. Maar daarover later meer.

Drie Manieren om Speculation Rules te Implementeren

Er zijn drie manieren om Speculation Rules aan de browser te communiceren. Elke methode heeft z'n eigen voor- en nadelen, afhankelijk van de architectuur van je website en je deployment-strategie.

Methode 1: Inline Script-tag

De meest directe manier is het toevoegen van een <script>-element met type="speculationrules" in de <head> van je HTML-document. De inhoud is simpelweg een JSON-object dat de speculatieregels definieert.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "urls": ["/producten", "/over-ons", "/contact"]
    }
  ]
}
</script>

Deze methode is ideaal wanneer je directe controle hebt over de HTML-output van je pagina's. Een mooi detail: het script-element wordt door browsers die de API niet ondersteunen gewoon genegeerd vanwege het onbekende type-attribuut. Dat zorgt voor natuurlijke progressive enhancement zonder dat je er iets extra's voor hoeft te doen.

Methode 2: HTTP Speculation-Rules Header

De tweede methode gebruikt een HTTP-responseheader om naar een extern JSON-bestand te verwijzen. Dit is bijzonder handig wanneer je de regels wilt beheren via een CDN of reverse proxy zonder de HTML van je pagina's aan te passen.

Speculation-Rules: "/speculationrules.json"

Het bijbehorende JSON-bestand op /speculationrules.json bevat dezelfde structuur als de inline variant:

{
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "selector_matches": ".no-prefetch" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}

Het grote voordeel hier is dat je speculatieregels kunt aanpassen op CDN-niveau. Diensten zoals Cloudflare, Akamai of Fastly kunnen deze header injecteren zonder dat je de oorspronkelijke applicatiecode hoeft te wijzigen. Dat maakt het ook mogelijk om de regels centraal te beheren voor meerdere websites of microservices -- erg handig in grotere organisaties.

Methode 3: JavaScript-gebaseerde Dynamische Regels

De derde methode maakt het mogelijk om speculatieregels dynamisch toe te voegen, te wijzigen of te verwijderen via JavaScript. Dit is krachtig wanneer de regels afhankelijk zijn van gebruikersgedrag, A/B-tests of andere runtime-condities.

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {

  const rules = {
    prerender: [
      {
        urls: ['/volgende-stap'],
        eagerness: 'immediate'
      }
    ]
  };

  const script = document.createElement('script');
  script.type = 'speculationrules';
  script.textContent = JSON.stringify(rules);
  document.head.appendChild(script);
}

Let op dat je met HTMLScriptElement.supports('speculationrules') eerst controleert of de browser de API ondersteunt. Dit voorkomt fouten in browsers die d'r niets mee kunnen. Je kunt ook bestaande speculatieregel-scripts verwijderen door het script-element uit de DOM te halen, waarna de browser de bijbehorende speculaties netjes annuleert.

Een praktisch voorbeeld: dynamisch prerender-regels toevoegen op basis van gebruikersinteractie.

// Prerender de volgende pagina in een wizard-flow
// zodra de gebruiker het formulier begint in te vullen
const formulier = document.querySelector('#stap-1-formulier');

formulier.addEventListener('input', () => {
  if (!document.querySelector('script[data-wizard-prerender]')) {
    const rules = {
      prerender: [{
        urls: ['/wizard/stap-2'],
        eagerness: 'immediate'
      }]
    };

    const script = document.createElement('script');
    script.type = 'speculationrules';
    script.dataset.wizardPrerender = 'true';
    script.textContent = JSON.stringify(rules);
    document.head.appendChild(script);
  }
}, { once: true });

Document Rules vs. List Rules: Welke Kies Je?

Oké, dit is een belangrijk onderscheid om goed te begrijpen. De Speculation Rules API biedt twee fundamenteel verschillende manieren om te specificeren welke URL's speculatief geladen moeten worden: list rules en document rules.

List Rules: Expliciete URL-lijsten

List rules zijn de eenvoudigste vorm. Je geeft expliciet een array van URL's op die gespekuleerd moeten worden. Handig wanneer je precies weet welke pagina's de gebruiker waarschijnlijk gaat bezoeken -- denk aan de belangrijkste landingspagina's of de volgende stap in een checkout-flow.

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": [
        "/producten/bestsellers",
        "/aanbiedingen",
        "/winkelwagen"
      ]
    }
  ]
}
</script>

De standaard eagerness voor list rules is immediate, wat betekent dat de browser direct begint zodra de regels worden verwerkt. Logisch, want je hebt bij expliciete URL's al een bewuste keuze gemaakt over wat er voorgeladen moet worden.

Document Rules: Patroongebaseerde Matching

Document rules zijn veel dynamischer en -- eerlijk gezegd -- veel krachtiger voor de meeste websites. In plaats van specifieke URL's op te sommen, definieer je patronen die de browser gebruikt om links in het huidige document te matchen. De browser scant alle links op de pagina en past de speculatieregels toe op links die aan jouw criteria voldoen.

Document rules gebruiken het where-sleutelwoord in combinatie met twee soorten matchers:

href_matches: Matcht URL's op basis van het URL Pattern API-formaat. Hiermee kun je wildcards en patronen gebruiken om URL's te selecteren.
selector_matches: Matcht links op basis van CSS-selectors. Dit is krachtig omdat je bestaande CSS-klassen of data-attributen kunt gebruiken om links te markeren voor speculatie.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/blog/*" },
          { "not": { "href_matches": "/blog/concept-*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": {
        "or": [
          { "selector_matches": ".navigatie-link" },
          { "selector_matches": "[data-prefetch]" }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

De standaard eagerness voor document rules is conservative. Logisch ook -- de browser kan potentieel veel links matchen en het zou onverstandig zijn om al die pagina's onmiddellijk te gaan laden.

Een van de grote voordelen van document rules is dat ze automatisch reageren op DOM-wijzigingen. Worden er dynamisch nieuwe links aan de pagina toegevoegd (door infinite scroll of AJAX-gebaseerde navigatie)? Dan worden die automatisch geëvalueerd tegen de bestaande document rules. Dat is echt slim bedacht.

Eagerness-niveaus: De Balans Tussen Snelheid en Zuinigheid

Het eagerness-niveau bepaalt wanneer de browser de speculatie daadwerkelijk uitvoert. Dit is een van de belangrijkste configuratieopties, want het bepaalt de balans tussen snelheid en resourceverbruik. Er zijn vier niveaus beschikbaar.

Immediate

Met "eagerness": "immediate" begint de browser zo snel mogelijk met de speculatie, zodra de regels zijn waargenomen. Dit is het meest agressieve niveau. Ideaal voor situaties waarin je heel zeker weet dat de gebruiker naar een specifieke pagina zal navigeren. Denk aan de volgende stap in een checkout-proces of een enkele call-to-action op een landingspagina.

Eager

Het eager-niveau gedraagt zich momenteel identiek aan immediate, maar het Chrome-team heeft aangegeven dat dit in de toekomst mogelijk een licht afwijkend gedrag kan krijgen -- bijvoorbeeld een minimale vertraging of een heuristiek-gebaseerde trigger. Het is bedoeld als tussenstap tussen immediate en moderate.

Moderate

Bij "eagerness": "moderate" start de speculatie wanneer de gebruiker minimaal 200 milliseconden over een link hovert, of bij een pointerdown-event (de muisknop wordt ingedrukt). Dit is wat mij betreft de sweet spot: het wacht op een duidelijk signaal van gebruikersintentie voordat er resources worden besteed, maar begint vroeg genoeg om een merkbaar snelheidsvoordeel te bieden.

Conservative

Het conservative-niveau is het meest terughoudend. De speculatie start alleen bij een pointerdown- of touchstart-event -- het moment waarop de gebruiker daadwerkelijk een klik of tap initieert. Minste voorbereidingstijd, maar ook het minste resourceverbruik.

Overzicht van Eagerness-niveaus

Immediate — Start: direct bij het waarnemen van de regel. Standaard voor: list rules. Ideaal voor: bekende navigatiedoelen met hoge waarschijnlijkheid.
Eager — Start: momenteel direct (kan wijzigen). Standaard voor: geen. Ideaal voor: toekomstig gebruik als tussenniveau.
Moderate — Start: na 200ms hover of bij pointerdown. Standaard voor: geen. Ideaal voor: de meeste document rules in productie.
Conservative — Start: alleen bij pointerdown/touchstart. Standaard voor: document rules. Ideaal voor: websites met veel links of beperkte bandbreedte.

In mijn ervaring is moderate het beste eagerness-niveau voor document rules met prerender, en conservative een veilige keuze wanneer je net begint met de implementatie. Die 200 milliseconden hover-detectie bij moderate klinken misschien als niets, maar het kan al genoeg zijn om een DNS-lookup, TCP-verbinding en het ophalen van de HTML af te ronden. Dat scheelt de gebruiker merkbaar wachttijd.

Uitsluiten van URL's

Laten we eerlijk zijn: je wilt niet elke link op je website speculatief laden. Pagina's met bijwerkingen (zoals uitloggen), API-endpoints, externe links en pagina's achter authenticatie moeten worden uitgesloten. Gelukkig biedt de Speculation Rules API hiervoor krachtige uitsluitingsmechanismen.

Uitsluiting met href_matches

Je kunt URL-patronen uitsluiten met de not-operator in combinatie met href_matches:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "href_matches": "/admin/*" } },
          { "not": { "href_matches": "/winkelwagen/afrekenen" } },
          { "not": { "href_matches": "/*\?*(^|&)modal=*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Uitsluiting met CSS-selectors

Een elegantere aanpak is het gebruik van CSS-selectors via selector_matches. Je voegt simpelweg een CSS-klasse toe aan links die niet gespekuleerd mogen worden:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "selector_matches": ".no-prerender" } },
          { "not": { "selector_matches": "[data-no-speculate]" } },
          { "not": { "selector_matches": "a[href^='mailto:']" } },
          { "not": { "selector_matches": "a[href^='tel:']" } },
          { "not": { "selector_matches": "a[download]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

In je HTML kun je vervolgens eenvoudig links markeren die niet voorgeladen mogen worden:

<!-- Deze link wordt NIET gespekuleerd -->
<a href="/uitloggen" class="no-prerender">Uitloggen</a>

<!-- Deze link wordt WEL gespekuleerd -->
<a href="/producten/schoenen">Bekijk schoenen</a>

<!-- Data-attribuut voor uitsluiting -->
<a href="/betaling/starten" data-no-speculate>Betaal nu</a>

Het combineren van href_matches en selector_matches uitsluitingen geeft je maximale controle. Mijn advies: gebruik href_matches voor brede patronen (hele paden uitsluiten) en selector_matches voor individuele links die een specifieke context vereisen.

No-Vary-Search Header

Dit is een subtiel maar belangrijk probleem dat veel mensen over het hoofd zien. Stel je voor dat je de pagina /producten/schoenen hebt geprefetcht. Vervolgens klikt de gebruiker op een link naar /producten/schoenen?utm_source=newsletter&utm_medium=email. Hoewel beide URL's exact dezelfde pagina-inhoud opleveren, beschouwt de browser ze als verschillende URL's. De prefetch-cache wordt niet gebruikt, en je hele speculatie was voor niets.

Frustrerend, toch?

De No-Vary-Search HTTP-header lost dit probleem op. Deze header vertelt de browser dat bepaalde URL-parameters de response niet beïnvloeden, waardoor gecachte responses hergebruikt kunnen worden ongeacht de aanwezigheid van die parameters.

Op je server configureer je de header als volgt:

No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign" "utm_content" "utm_term" "fbclid" "gclid" "ref")

Dit vertelt de browser: "De parameters utm_source, utm_medium, enzovoort, veranderen niets aan de inhoud van de response. Een gecachte versie zonder deze parameters mag worden gebruikt voor een verzoek mét deze parameters."

In je speculatieregels kun je met expects_no_vary_search de browser alvast informeren dat de server deze header zal meesturen. Dit stelt de browser in staat om de speculatiecache efficiënter te gebruiken, zelfs voordat de server-response is ontvangen:

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["/producten/schoenen"],
      "expects_no_vary_search": "params=(\"utm_source\" \"utm_medium\" \"utm_campaign\" \"ref\")"
    }
  ]
}
</script>

Voor websites die zwaar leunen op UTM-tracking en andere marketingparameters is dit een essentiële configuratie. Ik heb dit zelf meermaals gezien op projecten: zonder No-Vary-Search worden veel speculatieve loads verspild omdat de daadwerkelijke navigatie-URL verschilt van de gespekuleerde URL door tracking-parameters die geen invloed hebben op de pagina-inhoud.

Impact op Core Web Vitals

De impact van de Speculation Rules API op Core Web Vitals is niets minder dan transformatief, met name wanneer prerendering wordt gebruikt.

Largest Contentful Paint (LCP)

LCP meet hoe snel het grootste zichtbare content-element op de pagina verschijnt. Bij een volledig voorgerenderde pagina? Vrijwel onmiddellijk.

Uit studies van het Chrome-team blijkt dat prerendering de LCP met tot wel 98% kan reduceren. In de praktijk rapporteren websites dat hun LCP daalt van enkele seconden naar minder dan 200 milliseconden. Dat zijn geen theoretische cijfers -- dat is productiedata.

Op het 95e percentiel (P95) wordt een LCP-verbetering van ongeveer 500 milliseconden waargenomen. Op het 75e percentiel (P75), de drempel die Google gebruikt voor Core Web Vitals-beoordeling, is de verbetering ongeveer 170 milliseconden. Dat klinkt misschien bescheiden, maar dit kan voor veel websites het verschil betekenen tussen een "goede" en "te verbeteren" LCP-score.

Interaction to Next Paint (INP)

INP meet de responsiviteit van de pagina op gebruikersinteracties. Prerendering helpt INP indirect doordat JavaScript al vooraf is uitgevoerd. Event handlers zijn al geregistreerd, frameworks zijn geïnitialiseerd, en de pagina is volledig interactief op het moment dat de gebruiker ze ziet. Geen hydratietijd, geen initialisatievertraging.

Dit is bijzonder waardevol voor pagina's met zware JavaScript-frameworks die normaal gesproken een merkbare vertraging hebben tussen het eerste visuele beeld en volledige interactiviteit. Met prerendering is die kloof volledig geëlimineerd.

Cumulative Layout Shift (CLS)

CLS profiteert ook van prerendering. Omdat de pagina volledig is gerenderd -- inclusief alle layout-berekeningen, lazy-loaded afbeeldingen en dynamisch ingevoegde content -- treden er geen visuele verschuivingen op wanneer de pagina aan de gebruiker wordt getoond. De layout is stabiel vanaf het eerste frame.

Het netto-effect? Websites die de Speculation Rules API effectief implementeren zien een dramatische verbetering in hun algehele pagina-ervaring. Navigaties voelen instant aan. Vergelijkbaar met het wisselen tussen tabbladen of het navigeren in een native applicatie.

Analytics en Bijwerkingen: Hier Moet Je Op Letten

Een van de meest kritieke aandachtspunten bij prerendering is de impact op analytics en andere scripts die bijwerkingen veroorzaken. Omdat een voorgerenderde pagina volledig wordt geladen en alle JavaScript wordt uitgevoerd, kunnen analytics-events, advertentie-impressies en andere meetgebeurtenissen per ongeluk worden getriggerd voor pagina's die de gebruiker nooit daadwerkelijk ziet.

Het document.prerendering Property

Gelukkig biedt de browser het document.prerendering-property waarmee JavaScript kan detecteren of de pagina momenteel wordt voorgerenderd. Dit property is true wanneer de pagina zich in een prerenderingcontext bevindt, en false wanneer de pagina normaal is geladen of is geactiveerd (de gebruiker is er daadwerkelijk naartoe genavigeerd).

Het prerenderingchange Event

Het prerenderingchange-event wordt afgevuurd op het document wanneer een voorgerenderde pagina wordt geactiveerd -- dus wanneer de gebruiker daadwerkelijk naar de pagina navigeert. Dit is je signaal om analytics en andere bijwerkingen uit te voeren.

// Analytics uitstellen tot de pagina daadwerkelijk wordt bekeken
function registreerPaginabezoek() {
  // Stuur pageview naar je analytics-systeem
  analytics.track('pageview', {
    url: window.location.href,
    titel: document.title,
    tijdstip: new Date().toISOString()
  });
}

if (document.prerendering) {
  // Pagina wordt voorgerenderd, wacht op activatie
  document.addEventListener('prerenderingchange', () => {
    registreerPaginabezoek();
  }, { once: true });
} else {
  // Pagina is normaal geladen, registreer direct
  registreerPaginabezoek();
}

Dit patroon is essentieel voor elke custom analytics-implementatie. Je controleert eerst of de pagina wordt voorgerenderd, en zo ja, stel je de analytics-call uit tot het moment dat de pagina daadwerkelijk door de gebruiker wordt gezien. Simpel, maar vergeet het niet.

Google Analytics en Tag Manager

Het goede nieuws: Google Analytics (zowel GA4 als Universal Analytics via gtag.js) en Google Tag Manager handelen de Speculation Rules API al standaard correct af. Deze tools detecteren automatisch of een pagina wordt voorgerenderd en stellen hun meetgebeurtenissen uit tot activatie. Je hoeft hier dus geen extra code voor te schrijven als je uitsluitend Google's analytics-tools gebruikt.

Andere Bijwerkingen

Naast analytics zijn er meer zaken om rekening mee te houden bij prerendering:

Advertentie-impressies: Advertentienetwerken moeten correct omgaan met voorgerenderde pagina's om te voorkomen dat impressies worden geteld voor pagina's die de gebruiker nooit ziet.
Chat-widgets: Live chat-systemen kunnen onnodig verbindingen opzetten voor voorgerenderde pagina's.
Video/audio autoplay: Browsers blokkeren autoplay in voorgerenderde contexten, maar dit kan tot onverwacht gedrag leiden bij activatie.
Wachtwoord-managers en formulieren: Voorgerenderde formulieren kunnen interacteren met browser-autofill en wachtwoordmanagers.

Een robuust patroon voor het afhandelen van willekeurige bijwerkingen:

// Generieke helper voor het uitstellen van bijwerkingen
function naActivatie(callback) {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', callback, { once: true });
  } else {
    callback();
  }
}

// Gebruik
naActivatie(() => {
  // Chat-widget initialiseren
  initialiseerChatWidget();
});

naActivatie(() => {
  // Advertenties laden
  laadAdvertenties();
});

naActivatie(() => {
  // Performance-metingen starten
  performance.mark('pagina-geactiveerd');
});

WordPress Integratie

Een van de meest opmerkelijke adoptieverhalen van de Speculation Rules API is de integratie in WordPress. Vanaf WordPress 6.8 worden speculatieregels standaard meegeleverd met elke WordPress-installatie. Miljoenen websites profiteren automatisch van speculatief laden zonder dat sitebeheerders technische kennis nodig hebben. Even tot je laten doordringen: miljoenen.

De Speculative Loading Plugin

De functionaliteit is oorspronkelijk ontwikkeld als de "Speculative Loading"-plugin, een samenwerking tussen het WordPress Performance Team en Google's Chrome-team. Deze plugin is uitgebreid getest op duizenden websites voordat de functionaliteit werd opgenomen in de WordPress-core.

De standaardinstellingen zijn bewust conservatief gekozen om problemen te voorkomen:

Actie: Prefetch (niet prerender)
Eagerness: Conservative (alleen bij pointerdown/touchstart)
Scope: Alle interne links met WordPress-specifieke uitsluitingen

Veilig voor vrijwel elke WordPress-website. Prefetch met conservative eagerness verbruikt minimale bandbreedte en heeft geen bijwerkingen.

Aanpassen van de Instellingen

Ontwikkelaars kunnen de speculatieregels aanpassen via WordPress-filters. Bijvoorbeeld, om over te schakelen naar prerender met moderate eagerness:

// In functions.php of een custom plugin
add_filter('wp_speculation_rules_configuration', function($config) {
    return array(
        'mode' => 'prerender',
        'eagerness' => 'moderate',
    );
});

// URL's uitsluiten van speculatie
add_filter('wp_speculation_rules_href_exclude_paths', function($exclude_paths) {
    $exclude_paths[] = '/mijn-account/*';
    $exclude_paths[] = '/wp-admin/*';
    $exclude_paths[] = '/privé-pagina/*';
    return $exclude_paths;
});

Voor niet-technische sitebeheerders biedt de Speculative Loading-plugin ook een gebruiksvriendelijke interface in het WordPress-dashboard onder Instellingen > Lezen, waar de actie en het eagerness-niveau eenvoudig kunnen worden aangepast.

Het feit dat WordPress -- dat meer dan 40% van alle websites aandrijft -- deze technologie standaard levert, is een enorme stap vooruit voor de snelheid van het web als geheel.

Browserondersteuning en Beperkingen

Oké, even serieus over browserondersteuning, want hier moet je realistisch in zijn. De Speculation Rules API wordt momenteel ondersteund door Chromium-gebaseerde browsers:

Google Chrome: Volledige ondersteuning sinds versie 121 (prefetch en prerender met document rules)
Microsoft Edge: Volledige ondersteuning (deelt de Chromium-engine met Chrome)
Opera: Volledige ondersteuning (eveneens Chromium-gebaseerd)

De volgende browsers ondersteunen de API niet:

Mozilla Firefox: Geen ondersteuning. Het Firefox-team heeft interesse getoond maar er is nog geen concrete implementatie of tijdlijn bekendgemaakt.
Apple Safari: Geen ondersteuning. Apple heeft zich niet publiekelijk uitgesproken over plannen om de API te implementeren.

Beperkingen

Naast browserondersteuning zijn er functionele beperkingen waar je rekening mee moet houden:

Cross-origin beperkingen: Prerendering is beperkt tot same-origin pagina's tenzij de doelpagina expliciet toestemming geeft via de Supports-Loading-Mode-header. Cross-origin prefetch is wel mogelijk.
Resource-limieten: De browser beperkt het aantal gelijktijdige speculaties. Voor moderate en conservative eagerness worden maximaal twee speculaties tegelijk in de wachtrij gehouden. Nieuwe speculaties vervangen de oudste op een FIFO-basis (First In, First Out).
Batterijbesparingsmodus: Wanneer de batterijbesparingsmodus is ingeschakeld, kan de browser speculaties beperken of uitschakelen om energie te besparen.
Lage datasnelheid: Op langzame verbindingen of wanneer de Data Saver-modus is ingeschakeld, kan de browser speculaties overslaan.
Geheugen: Voorgerenderde pagina's verbruiken aanzienlijk geheugen. De browser kan besluiten om voorgerenderde pagina's te verwijderen wanneer het geheugen schaars is.
Bepaalde API's: Sommige browser-API's worden geblokkeerd of uitgesteld in voorgerenderde pagina's, waaronder geolocation, notificaties, Web Serial, Web Bluetooth en WebUSB.

Progressive Enhancement

Het mooie aan de Speculation Rules API is dat het van nature progressive enhancement ondersteunt. Browsers die de API niet begrijpen, negeren simpelweg het <script type="speculationrules">-element vanwege het onbekende type-attribuut. Geen fouten, geen problemen -- de website functioneert gewoon normaal, alleen zonder de extra snelheidsvoordelen.

Dit maakt het volkomen veilig om de API vandaag te implementeren, zelfs als een deel van je gebruikers browsers gebruikt die 't niet ondersteunen. Die gebruikers merken er simpelweg niets van, terwijl Chrome-, Edge- en Opera-gebruikers profiteren van snellere navigatie.

Debugging in Chrome DevTools

Chrome DevTools biedt uitstekende ondersteuning voor het debuggen van speculatieregels. Dit is essentieel tijdens de implementatie en voor het monitoren van de effectiviteit van je configuratie.

Het Application Panel

De belangrijkste plek voor het debuggen van speculatieregels is het Application-paneel in Chrome DevTools. Navigeer naar Application > Background services > Speculative loads. Hier vind je een overzicht van:

Speculation Rules: Een lijst van alle gedetecteerde speculatieregels op de huidige pagina, inclusief hun bron (inline script, HTTP-header of JavaScript-gegenereerd).
Speculations: Een gedetailleerd overzicht van alle speculaties die zijn gestart, inclusief hun status (nog in behandeling, uitgevoerd, mislukt of gebruikt).
Prerendered pages: Een lijst van alle momenteel voorgerenderde pagina's met hun status en het resourceverbruik.

Het Network Panel

In het Network-paneel kun je verzoeken die voortkomen uit speculatieregels herkennen. Prefetch-verzoeken worden gemarkeerd en prerender-gerelateerde verzoeken zijn zichtbaar wanneer je het juiste filter toepast. Je kunt ook de grootte van gespekuleerde resources zien om de bandbreedte-impact te evalueren.

Praktische Debugging-tips

Valideer je JSON: Een syntaxfout in je speculatieregel-JSON zorgt ervoor dat de hele regel wordt genegeerd. Gebruik het Application-paneel om te controleren of je regels correct worden herkend.
Controleer de eagerness: Als speculaties niet worden uitgevoerd, controleer dan of je eagerness-niveau overeenkomt met je verwachtingen. Bij conservative moet je daadwerkelijk op een link klikken (pointerdown) om de speculatie te triggeren.
Gebruik chrome://process-internals: Deze interne Chrome-pagina biedt gedetailleerde informatie over actieve prerender-processen en hun status.
Test met throttling: Simuleer langzame netwerken in DevTools om te zien hoe speculatieregels de gebruikerservaring verbeteren onder suboptimale omstandigheden.
Monitor het Console-paneel: Chrome logt waarschuwingen in de console wanneer speculaties worden geannuleerd of mislukken, inclusief de reden (bijvoorbeeld een cross-origin beperking of een API die niet beschikbaar is in voorgerenderde context).

Best Practices en Aanbevelingen

Op basis van de ervaringen van duizenden websites die de Speculation Rules API hebben geïmplementeerd, zijn er duidelijke best practices naar voren gekomen. Hier zijn de belangrijkste lessen.

Begin Conservatief en Bouw Op

Start met de meest conservatieve configuratie en werk geleidelijk toe naar agressievere instellingen. Dit is geen technologie waar je meteen de maximale configuratie wilt uitrollen:

Stap 1: Begin met prefetch en conservative eagerness. Dit is veilig, verbruikt minimale bandbreedte, en geeft je basisdata over hoe gebruikers navigeren.
Stap 2: Schakel over naar prefetch met moderate eagerness. De hover-detectie biedt meer voorbereidingstijd en dus snellere navigaties.
Stap 3: Test prerender met moderate eagerness op specifieke, veelgebruikte navigatiepaden. Monitor de impact op Core Web Vitals en resourceverbruik.
Stap 4: Breid prerendering uit naar meer pagina's als de resultaten positief zijn.

Vermijd Prerendering voor Pagina's met Bijwerkingen

Dit kan ik niet genoeg benadrukken. Render nooit pagina's vooraf die ongewenste bijwerkingen kunnen veroorzaken:

Pagina's die bestellingen plaatsen of betalingen verwerken
Uitlogpagina's of sessie-management endpoints
Pagina's die gegevens wijzigen (POST-achtige acties via URL)
Pagina's met rate-limited API-aanroepen

Gebruik Uitsluitingspatronen Consequent

Ontwikkel een standaard set uitsluitingspatronen die je op al je pagina's toepast:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "href_matches": "/admin/*" } },
          { "not": { "href_matches": "/account/*" } },
          { "not": { "href_matches": "/*\?*(^|&)action=*" } },
          { "not": { "selector_matches": ".no-prerender" } },
          { "not": { "selector_matches": "[data-turbo]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Monitor Bandbreedte-impact

Houd de bandbreedte-impact van speculatieregels in de gaten, vooral bij prerendering. Elke voorgerenderde pagina laadt alle subresources, wat aanzienlijke data-overdracht kan veroorzaken. Gebruik je server-logs en Real User Monitoring (RUM)-data om te controleren hoeveel speculatieve verzoeken daadwerkelijk leiden tot navigatie -- de zogenaamde "hit rate".

Een lage hit rate (veel speculaties maar weinig daadwerkelijke navigaties) duidt op verspilde bandbreedte. In dat geval kun je je regels verfijnen door het eagerness-niveau te verlagen, specifiekere URL-patronen te gebruiken, of over te schakelen van prerender naar prefetch.

Progressive Enhancement als Filosofie

De Speculation Rules API is ontworpen als een progressive enhancement. Browsers die de API niet ondersteunen negeren de regels simpelweg. Dat betekent dat je geen fallback-mechanisme nodig hebt. Maar het betekent ook dat je niet afhankelijk moet zijn van speculatief laden voor de basisfunctionaliteit van je website.

Zorg ervoor dat je website ook zonder speculatieregels goed presteert. Optimaliseer je LCP, minimaliseer je JavaScript-bundels, en implementeer goede caching. De Speculation Rules API is de kers op de taart, niet het fundament van je performance-strategie.

Test Grondig

Ik heb het te vaak gezien: speculatieregels die in de testomgeving perfect werken maar in productie onverwacht gedrag vertonen. Test in verschillende scenario's:

Op mobiele apparaten met beperkt geheugen
Op langzame netwerkverbindingen
Met de batterijbesparingsmodus ingeschakeld
Na het wissen van de browsercache
Met en zonder ingelogde gebruikersstatus
Op pagina's met dynamisch geladen content

Combineer met Andere Optimalisaties

De Speculation Rules API werkt het best in combinatie met andere performance-optimalisaties:

Efficiënte caching: Goed geconfigureerde cache-headers zorgen ervoor dat gespekuleerde resources niet opnieuw gedownload hoeven te worden.
CDN-deployment: Een CDN vermindert de netwerklatentie voor gespekuleerde verzoeken, waardoor zelfs conservative eagerness effectief kan zijn.
Geoptimaliseerde server-responstijden: Een snelle server maakt speculatief laden effectiever doordat de voorbereidingstijd beter benut wordt.
No-Vary-Search headers: Zoals eerder besproken, maximaliseren deze headers de cache-effectiviteit van gespekuleerde requests.

Conclusie

De Speculation Rules API vertegenwoordigt een echte paradigmaverschuiving in hoe we navigatiesnelheid op het web benaderen. In plaats van te focussen op het optimaliseren van individuele pagina-laadtijden, stelt deze API ons in staat om navigaties proactief voor te bereiden. Het resultaat: een waargenomen laadtijd die vrijwel tot nul kan worden gereduceerd.

De kracht van de API ligt in de combinatie van eenvoud en flexibiliteit. Een simpele JSON-configuratie in een script-tag is voldoende om te beginnen. Maar wanneer je meer controle nodig hebt, bieden geavanceerde features zoals document rules, eagerness-niveaus, uitsluitingspatronen en No-Vary-Search-integratie alles wat je nodig hebt voor complexe websites.

De adoptie door WordPress vanaf versie 6.8 is een bijzonder krachtig signaal. Miljoenen websites profiteren nu automatisch van speculatief laden. Dat verbetert de algehele snelheid van het web merkbaar, en het laat zien dat de API volwassen en productie-klaar is.

De resultaten spreken voor zich: LCP-reducties tot 98%, navigatietijden onder de 100 milliseconden, en verbeteringen over de hele linie van Core Web Vitals. Voor gebruikers voelt het alsof pagina's instant laden -- een ervaring die voorheen voorbehouden was aan native applicaties en single-page applications.

Begin vandaag nog met de implementatie. Start eenvoudig met prefetch en conservative eagerness, meet de resultaten, en bouw geleidelijk op naar prerendering. De API is ontworpen als progressive enhancement: browsers die 't niet ondersteunen negeren het simpelweg, dus er is geen risico om het uit te proberen.

En met de debugging-tools in Chrome DevTools kun je precies zien wat er gebeurt en je configuratie fijn afstemmen.

Het web van 2026 is sneller dan ooit, en de Speculation Rules API is een van de belangrijkste redenen daarvoor. De vraag is niet langer of je deze technologie moet implementeren, maar hoe snel je ermee aan de slag gaat.