Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Pagina's vooraf renderen in Chrome voor onmiddellijke paginanavigatie

Barry Pollard

Gepubliceerd: 2 december 2022, Laatst geüpdatet: 29 oktober 2026

Browser Support

Het Chrome-team heeft de volledige prerendering teruggebracht van toekomstige pagina's waarnaar een gebruiker waarschijnlijk navigeert.

Een korte geschiedenis van prerenderen

In het verleden ondersteunde Chrome de bronhint <link rel="prerender" href="/next-page">, maar deze werd niet breed ondersteund buiten Chrome en was geen erg expressieve API.

Deze verouderde prerendering met de hint link rel=prerender is beëindigd ten gunste van NoState Prefetch, waarmee de bronnen worden opgehaald die de toekomstige pagina nodig heeft, maar de pagina niet volledig wordt geprerenderd en JavaScript niet wordt uitgevoerd. NoState Prefetch helpt de paginaprestaties te verbeteren door het laden van bronnen te verbeteren, maar levert geen onmiddellijke paginalading zoals een volledige pre-rendering dat zou doen.

Het Chrome-team heeft volledige prerendering opnieuw geïntroduceerd in Chrome. Dit nieuwe prerender-mechanisme gebruikt de syntaxis <link rel="prerender"...> niet om complicaties met bestaand gebruik te voorkomen en toekomstige uitbreiding van prerendering mogelijk te maken. Deze syntaxis blijft van kracht voor NoState Prefetch, met het oog op beëindiging op een bepaald moment in de toekomst.

Hoe wordt een pagina vooraf gerenderd?

Een pagina kan op een van de volgende 4 manieren worden geprerenderd, die allemaal zijn bedoeld om de navigatie te versnellen:

Als je een URL typt in de Chrome-adresbalk (ook wel de omnibox genoemd), kan Chrome de pagina automatisch vooraf renderen als Chrome er op basis van je eerdere browsegeschiedenis veel vertrouwen in heeft dat je die pagina gaat bezoeken.
Als je de bookmarkbalk gebruikt, kan Chrome de pagina automatisch vooraf voor je renderen als je de muisaanwijzer op een van de bookmarkknoppen plaatst.
Als je een zoekterm in de Chrome-adresbalk typt, kan Chrome de pagina met zoekresultaten automatisch vooraf renderen als de zoekmachine hiervoor een instructie geeft.
Sites kunnen de Speculation Rules API gebruiken om Chrome programmatisch te vertellen welke pagina's vooraf moeten worden gerenderd. Dit vervangt wat <link rel="prerender"...> eerder deed en biedt sites de mogelijkheid om een pagina proactief te pre-renderen op basis van speculatieregels op de pagina. Deze kunnen statisch op de pagina's aanwezig zijn of dynamisch worden geïnjecteerd door JavaScript, zoals de paginabeheerder dat wil.

In elk van deze gevallen gedraagt een vooraf gerenderde pagina zich alsof de pagina is geopend op een onzichtbaar achtergrondtabblad en daarna wordt geactiveerd door het tabblad op de voorgrond te vervangen door die vooraf gerenderde pagina. Als een pagina wordt geactiveerd voordat deze volledig is voorgerenderd, is de huidige status 'op de voorgrond' en wordt de pagina verder geladen. Dit betekent dat je nog steeds een goede voorsprong hebt.

Omdat de vooraf gerenderde pagina in een verborgen staat wordt geopend, worden een aantal API's die opdringerig gedrag veroorzaken (bijvoorbeeld prompts) niet geactiveerd in deze staat. In plaats daarvan worden ze vertraagd totdat de pagina wordt geactiveerd. In de weinige gevallen waarin dit nog niet mogelijk is, wordt de pre-rendering geannuleerd. Het Chrome-team werkt eraan om annuleringsredenen voor prerendering beschikbaar te maken als API en de DevTools-mogelijkheden te verbeteren om zulke randgevallen makkelijker te identificeren.

Opmerking: Vooraf gerenderde pagina's moeten worden behandeld als een hint en een progressive enhancement. In tegenstelling tot preload is pre-rendering een speculatieve hint en kan de browser ervoor kiezen om niet te reageren op de hint op basis van gebruikersinstellingen, het huidige geheugengebruik of andere heuristieken.

Impact van prerendering

Met prerendering kan een pagina bijna onmiddellijk worden geladen, zoals in de volgende video wordt getoond:

Voorbeeld van de impact van prerendering.

De voorbeeldsite is al een snelle site, maar zelfs hiermee kun je zien hoe prerendering de gebruikerservaring verbetert. Dit kan dus ook een directe impact hebben op de Core Web Vitals van een site, met een LCP van bijna nul, een lagere CLS (omdat elke laad-CLS plaatsvindt vóór de eerste weergave) en een verbeterde INP (omdat het laden moet zijn afgerond voordat de gebruiker interactie heeft).

Zelfs als een pagina wordt geactiveerd voordat deze volledig is geladen, zou de laadervaring moeten verbeteren als het laden van de pagina een voorsprong heeft. Als een link wordt geactiveerd terwijl de pre-rendering nog bezig is, wordt de voorrenderingspagina verplaatst naar het hoofdframe en wordt het laden voortgezet.

Voor prerendering is wel extra geheugen en netwerkbandbreedte nodig. Zorg dat je niet te veel vooraf rendert, want dat kost gebruikersresources. Voer alleen pre-rendering uit als de kans groot is dat de gebruiker naar de pagina navigeert.

Ga naar het gedeelte Prestaties meten voor meer informatie over hoe je de werkelijke prestatie-impact meet in je analyse.

Voorspellingen van de adresbalk van Chrome bekijken

Voor de eerste use case kun je de voorspellingen van Chrome voor URL's bekijken op de pagina chrome://predictors:

De pagina Chrome-voorspellers is gefilterd om lage (grijs), gemiddelde (oranje) en hoge (groen) voorspellingen te tonen op basis van de ingevoerde tekst. — Pagina Chrome Predictors.

Groene lijnen geven aan dat er voldoende vertrouwen is om prerendering te activeren. In dit voorbeeld geeft het typen van 's' een redelijke zekerheid (oranje), maar zodra je 'sh' typt, heeft Chrome voldoende zekerheid dat je bijna altijd naar https://sheets.google.com gaat.

Dit screenshot is gemaakt in een relatief nieuwe Chrome-installatie en voorspellingen met een betrouwbaarheid van nul zijn weggefilterd. Als je je eigen voorspellers bekijkt, zie je waarschijnlijk aanzienlijk meer vermeldingen en misschien meer tekens die nodig zijn om een voldoende hoog betrouwbaarheidsniveau te bereiken.

Deze voorspellers bepalen ook de voorgestelde opties in de adresbalk die je misschien hebt opgemerkt:

De functie Typeahead in de Chrome-adresbalk — De functie Typeahead in de adresbalk.

Chrome updatet de voorspellers voortdurend op basis van je typgedrag en selecties.

Bij een betrouwbaarheidsniveau van meer dan 30% (getoond in oranje) maakt Chrome proactief vooraf verbinding met het domein, maar wordt de pagina niet vooraf gerenderd.
Als het betrouwbaarheidsniveau hoger is dan 50% (groen weergegeven), prerendert Chrome de URL.

De Speculation Rules API

Voor de prerenderoptie van de Speculation Rules API kunnen webontwikkelaars json-instructies op hun pagina's invoegen om de browser te informeren over welke URL's moeten worden geprerenderd.

Lijst met URL's

Speculatieregels kunnen gebaseerd zijn op lijsten met URL's:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Documentregels

Speculatieregels kunnen ook documentregels zijn die de syntaxis where gebruiken. Dit speculeert links die in het document zijn gevonden op basis van href-kiezers (gebaseerd op de URL Pattern API) of css-kiezers:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

Enthousiasme

Browser Support

Source

Een eagerness-instelling wordt gebruikt om aan te geven wanneer de speculaties moeten worden geactiveerd. Dit is vooral handig voor documentregels:

conservative: Dit speculeert over aanwijzer of aanraking.
moderate: Op een desktop voert dit speculaties uit als je de cursor 200 milliseconden op een link houdt (of bij de gebeurtenis pointerdown als dat eerder is, en op mobiele apparaten waar geen gebeurtenis hover is). Op mobiele apparaten baseren we dit vanaf augustus 2025 op complexe viewport-heuristieken. Complexe heuristieken voor de viewport worden 500 ms nadat de gebruiker is gestopt met scrollen geactiveerd voor ankers binnen 30% van de verticale afstand van de vorige muisklik, waarbij ankers minstens 0, 5x zo groot zijn als het grootste anker in de viewport. Zoals beschreven in dit document.
eager: Deze gretigheid gedroeg zich vroeger hetzelfde als immediate, maar is gewijzigd vanaf Chrome 143. Op een desktop worden speculaties uitgevoerd als je de muisaanwijzer 10 milliseconden op een link houdt. Op mobiele apparaten baseren we dit vanaf januari 2026 op eenvoudige viewport-heuristieken. Eenvoudige heuristieken voor het kijkvenster worden 50 ms nadat het anker het kijkvenster is binnengekomen, geactiveerd.
immediate: Dit wordt gebruikt om zo snel mogelijk te speculeren, dat wil zeggen zodra de speculatieregels worden waargenomen.

De standaard eagerness voor list-regels is immediate. De opties eager, moderate en conservative kunnen worden gebruikt om list-regels te beperken tot URL's waarmee een gebruiker interactie heeft met een specifieke lijst. In veel gevallen zijn document-regels met een geschikte where-voorwaarde misschien beter.

De standaard eagerness voor document-regels is conservative. Omdat een document uit veel URL's kan bestaan, moet je immediate voor document-regels voorzichtig gebruiken (zie ook het gedeelte Chrome-limieten hierna).

Welke eagerness-instelling je moet gebruiken, is afhankelijk van je site. Voor een lichte, statische site kost enthousiaster speculeren misschien weinig en is het voordelig voor gebruikers. Sites met complexere architecturen en zwaardere paginabelastingen geven er misschien de voorkeur aan om verspilling te verminderen door minder vaak te speculeren totdat je een positiever signaal van intentie van gebruikers krijgt om verspilling te beperken.

De optie moderate is een tussenweg. Veel sites kunnen baat hebben bij de volgende speculatieregel die een link vooraf rendert als de gebruiker de muisaanwijzer 200 milliseconden op de link houdt of bij de gebeurtenis pointerdown als een eenvoudige, maar krachtige implementatie van speculatieregels:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Prefetch

Speculatieregels kunnen ook worden gebruikt om pagina's vooraf op te halen, zonder volledige prerendering. Dit is vaak een goede eerste stap op weg naar prerendering:

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Opmerking: In tegenstelling tot de oudere bronhint <link rel="prefetch">, die alleen vooraf werd opgehaald naar het HTTP-geheugen, worden documenten die worden geladen met speculatieregels op dezelfde manier verwerkt als navigaties (maar dan niet gerenderd) en worden ze in het geheugen bewaard, zodat ze sneller beschikbaar zijn voor de browser als dat nodig is. Hierdoor kunnen ook documenten die niet kunnen worden opgeslagen in het HTTP-cachegeheugen, vooraf worden opgehaald.

Vanwege problemen met het prefetchen van documenten met <link rel="prefetch">, raden we je aan speculatieregels te gebruiken voor navigaties. Gebruik <link rel="prefetch"> alleen voor het prefetchen van subbronnen. Aan de andere kant moeten speculatieregels worden gebruikt voor speculaties over documentnavigatie en niet voor prefetching van subbronnen, vooral vanwege de cross-origin-beperkingen van de Speculation Rules API.

Prerender until script

Het Chrome-team werkt ook aan de toevoeging van prerender_until_script aan de Speculation Rules API (zie: implementatiefout). Dit is een stap tussen prefetchen en prerenderen en wordt op een vergelijkbare manier gebruikt:

<script type="speculationrules">
{
  "prerender_until_script": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Net als bij NoState prefetch worden hierbij zowel het HTML-document als de subbronnen die beschikbaar zijn in die HTML vooraf opgehaald. De browser gaat echter verder en begint ook met de prerendering van de pagina. Dit proces stopt wanneer het eerste script wordt gevonden.

Dit betekent dat pagina's zonder JavaScript of met alleen JavaScript in de voettekst bijna volledig vooraf kunnen worden gerenderd. Pagina's met scripts in de <head> kunnen niet vooraf worden gerenderd, maar hebben nog steeds baat bij het ophalen van subbronnen.

Zo voorkom je de risico's van onbedoelde bijwerkingen van de uitvoering van JavaScript, maar kun je een veel grotere prestatieverbetering behalen dan alleen prefetch.

Chrome-limieten

Chrome heeft limieten ingesteld om overmatig gebruik van de Speculation Rules API te voorkomen:

enthousiasme	Prefetch	Pre-renderen
`immediate`	50	10
`eager` / `moderate` op mobiel	6 (FIFO)	2 (FIFO)
`eager` / `moderate` op desktop	2 (FIFO)	2 (FIFO)
`conservative`	2 (FIFO)	2 (FIFO)

Speculatielimieten in Chrome.

De instellingen eager, moderate en conservative, die afhankelijk zijn van gebruikersinteractie, werken volgens het principe op volgorde van binnenkomst (FIFO): nadat de limiet is bereikt, wordt de oudste speculatie geannuleerd en vervangen door de nieuwere om geheugen te besparen.

Een geannuleerde speculatie kan opnieuw worden geactiveerd, bijvoorbeeld door de muisaanwijzer weer op die link te plaatsen. Dit leidt ertoe dat die URL opnieuw wordt gespeculeerd, waardoor de oudste speculatie wordt verwijderd. In dit geval heeft de vorige speculatie alle cachebare bronnen in het HTTP-cachegeheugen voor die URL gecachet, dus een verdere speculatie zou lagere kosten moeten hebben. Daarom is de limiet standaard ingesteld op de bescheiden drempel van 2. We gebruiken een hogere drempel van 6 voor prefetch op mobiele apparaten omdat er geen muisaanwijzer is, de alternatieve heuristieken voor mobiele weergavegebieden minder nauwkeurig zijn en prefetch minder kostbaar is dan prerender (we houden de limiet van 2 aan voor prerender op mobiele apparaten).

Regels voor statische lijsten worden niet geactiveerd door een gebruikersactie en hebben daarom een hogere limiet, omdat de browser niet kan weten welke regels nodig zijn en wanneer ze nodig zijn.

Chrome overweegt ook om de limiet te verhogen naar 5 op mobiele apparaten voor eager en moderate, ten minste voor prefetch, omdat dit een minder nauwkeurige heuristiek is. Ontwikkelaars die eager gebruiken, kunnen overwegen om daarnaast conservative-regels te gebruiken voor als er meerdere links beschikbaar zijn in de viewport, zodat ze nog steeds speculeren, zelfs als ze niet zijn geselecteerd als een van de eerste 2 links.

De limiet van immediate is ook dynamisch. Als je een list URL-scriptelement verwijdert, maak je capaciteit vrij door die verwijderde speculaties te annuleren.

Chrome voorkomt ook dat speculaties in bepaalde omstandigheden worden gebruikt, waaronder:

Save-Data.
Energiebesparing als deze functie aanstaat en de batterij bijna leeg is.
Geheugenbeperkingen.
Als de instelling Pagina's vooraf laden uitstaat (wat ook expliciet wordt uitgezet door Chrome-extensies zoals uBlock Origin).
Pagina's geopend in tabbladen op de achtergrond.

Chrome rendert ook geen cross-origin iframes op vooraf gerenderde pagina's tot de activering.

Al deze voorwaarden zijn bedoeld om de impact van overspeculatie te verminderen als dit nadelig is voor gebruikers.

Speculatieregels opnemen op een pagina

Speculatieregels kunnen statisch worden opgenomen in de HTML van de pagina of dynamisch worden ingevoegd in de pagina door JavaScript:

Statisch opgenomen speculatieregels: Een nieuwsmediasite of een blog kan bijvoorbeeld het nieuwste artikel prerenderen als dat vaak de volgende navigatie is voor een groot deel van de gebruikers. Je kunt ook documentregels met een moderate of conservative gebruiken om te speculeren als gebruikers interactie hebben met links.
Dynamisch ingevoegde speculatieregels: Dit kan gebaseerd zijn op app-logica, gepersonaliseerd voor de gebruiker of gebaseerd op andere heuristieken.

Als u de voorkeur geeft aan dynamische invoeging op basis van acties zoals de muisaanwijzer op een link plaatsen of op een link klikken (zoals veel bibliotheken in het verleden hebben gedaan met <link rel=prefetch>), raden we u aan documentregels te gebruiken. Hiermee kan de browser veel van uw use cases verwerken.

Je kunt speculatieregels toevoegen in de <head> of de <body> of in het hoofdframe. Er wordt geen actie ondernomen op speculatieregels in subframes en er wordt alleen actie ondernomen op speculatieregels op vooraf gerenderde pagina's nadat die pagina is geactiveerd.

De HTTP-header `Speculation-Rules`

Browser Support

Source

Speculatieregels kunnen ook worden geleverd via een Speculation-Rules HTTP-header, in plaats van ze rechtstreeks in de HTML van het document op te nemen. Zo kunnen CDN's makkelijker implementeren zonder de documentcontent zelf te hoeven wijzigen.

De HTTP-header Speculation-Rules wordt geretourneerd met het document en verwijst naar een locatie van een json-bestand met de speculatieregels:

Speculation-Rules: "/speculationrules.json"

Deze bron moet het juiste MIME-type gebruiken en, als het een cross-origin-bron is, een CORS-controle doorstaan.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Als je relatieve URL's wilt gebruiken, kun je de sleutel "relative_to": "document" opnemen in je speculatieregels. Anders zijn relatieve URL's relatief ten opzichte van de URL van het json-bestand met speculatieregels. Dit kan vooral handig zijn als je een aantal of alle links met dezelfde oorsprong wilt selecteren.

Tagveld voor speculatieregels

Browser Support

Source

Je kunt ook tags toevoegen aan de json-syntaxis van speculatieregels op het algemene niveau voor alle speculatieregels in een regelset:

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

Of op het niveau van de afzonderlijke regel:

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

Deze tag wordt dan weerspiegeld in de HTTP-header Sec-Speculation-Tags, die kan worden gebruikt om speculatieregels op de server te filteren. De HTTP-header Sec-Speculation-Tags kan meerdere tags bevatten als de speculatie onder meerdere regels valt, zoals in het volgende voorbeeld:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

Sommige CDN's injecteren automatisch speculatieregels, maar blokkeren speculaties voor pagina's die niet in de edge-cache zijn opgeslagen om te voorkomen dat deze functie leidt tot meer gebruik van de oorspronkelijke server. Met tags kunnen ze speculaties identificeren die zijn gestart door hun standaardregelset, maar kunnen regels die door de site zijn toegevoegd, nog steeds worden doorgegeven aan de oorsprong.

Regelsettags worden ook getoond in Chrome DevTools.

Veld `target_hint` voor speculatieregels

Browser Support

Source

Speculatieregels kunnen ook een veld target_hint bevatten, dat een geldige naam of geldig zoekwoord voor de browsecontext bevat die aangeeft waar de pagina verwacht dat de vooraf gerenderde content wordt geactiveerd:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

Met deze hint kunnen speculaties over prerendering worden verwerkt voor target="_blank"-links:

<a target="_blank" href="next.html">Open this link in a new tab</a>

Op dit moment worden alleen "target_hint": "_blank" en "target_hint": "_self" (de standaardwaarde als deze niet is opgegeven) ondersteund in Chrome en alleen voor prerenderen. Prefetchen wordt niet ondersteund.

target_hint is alleen nodig voor urls-speculatieregels, omdat voor documentregels de target bekend is via de link zelf.

Speculatieregels en SPA's

Speculatieregels worden alleen ondersteund voor paginanavigatie die door de browser wordt beheerd, en niet voor apps met één pagina (SPA) of app-shell-pagina's. Deze architectuur gebruikt geen documenten ophalen, maar maakt API- of gedeeltelijke ophaalacties van gegevens of pagina's, die dan worden verwerkt en gepresenteerd op de huidige pagina. De gegevens die nodig zijn voor deze zogenoemde zachte navigaties, kunnen vooraf worden opgehaald door de app buiten de speculatieregels, maar kunnen niet vooraf worden gerenderd.

Speculatieregels kunnen worden gebruikt om de app zelf vooraf te renderen vanaf een vorige pagina. Dit kan een deel van de extra initiële laadkosten compenseren die sommige SPA's hebben. Route-wijzigingen in de app kunnen niet vooraf worden gerenderd.

Fouten opsporen in speculatieregels

Bekijk de speciale post over het debuggen van speculatieregels voor nieuwe Chrome DevTools-functies om deze nieuwe API te bekijken en te debuggen.

Meerdere speculatieregels

Je kunt ook meerdere speculatieregels aan dezelfde pagina toevoegen. Deze worden toegevoegd aan de bestaande regels. Daarom leiden de volgende verschillende manieren allemaal tot prerendering van zowel one.html als two.html:

Lijst met URL's:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html", "two.html"]
  }]
}
</script>

Meerdere speculationrules-scripts:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html"]
  }]
}
</script>
<script type="speculationrules">
{
  "prerender": [{
    "urls": ["two.html"]
  }]
}
</script>

Meerdere lijsten binnen één set speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

`No-Vary-Search`-support

Browser Support

Source

Als je een pagina vooraf ophaalt of vooraf rendert, zijn bepaalde URL-parameters (technisch bekend als zoekparameters) misschien niet belangrijk voor de pagina die de server daadwerkelijk levert en worden ze alleen gebruikt door JavaScript aan de clientzijde.

Google Analytics gebruikt bijvoorbeeld UTM-parameters voor campagnemeting, maar deze leiden meestal niet tot verschillende pagina's die vanaf de server worden geleverd. Dit betekent dat page1.html?utm_content=123 en page1.html?utm_content=456 dezelfde pagina van de server leveren, zodat dezelfde pagina opnieuw kan worden gebruikt vanuit het cachegeheugen.

Op dezelfde manier kunnen apps andere URL-parameters gebruiken die alleen aan de clientzijde worden verwerkt.

Met het voorstel No-Vary-Search kan een server parameters specificeren die niet leiden tot een verschil in de geleverde bron. Hierdoor kan een browser eerder gecachte versies van een document hergebruiken die alleen verschillen door deze parameters. Dit wordt ondersteund in Chrome (en op Chromium gebaseerde browsers) voor navigatiespeculaties voor zowel prefetch als prerender.

Let op: Als je prerenderen gebruikt met No-Vary-Search, kan de pagina worden geprerenderd met een andere zoekparameter (of helemaal zonder zoekparameter). In eerste instantie is de URL (zoals geretourneerd door bijvoorbeeld location.href) de vooraf gerenderde URL, maar als er op een link wordt geklikt met andere zoekparameters die onder No-Vary-Search vallen, gebruikt de browser die vooraf gerenderde pagina en vervangt de URL door de uiteindelijke URL (inclusief de juiste zoekparameters).

JavaScript die afhankelijk is van de zoekparameters, mag daarom alleen worden uitgevoerd nadat de pagina is geactiveerd. Voor UTM-parameters is dit misschien geen probleem als de analysecode pas na de activering wordt uitgevoerd, maar voor pagina's die aan de clientzijde worden gerenderd en die verschillende content weergeven op basis van zoekparameters, kan dit een probleem zijn. Wees voorzichtig en zorg dat de aan de clientzijde gerenderde content wordt geüpdatet bij activering.

Speculatieregels ondersteunen het gebruik van expects_no_vary_search om aan te geven waar een No-Vary-Search HTTP-header naar verwachting wordt geretourneerd. Zo kun je onnodige downloads voorkomen voordat de reacties worden bekeken.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

In dit voorbeeld is de oorspronkelijke HTML van de pagina /products hetzelfde voor beide product-ID's 123 en 124. De paginacontent verschilt uiteindelijk op basis van weergave aan de clientzijde met JavaScript om productgegevens op te halen met de zoekparameter id. We halen die URL dus vooraf op en deze moet een No-Vary-Search HTTP-header retourneren die aangeeft dat de pagina kan worden gebruikt voor elke id-zoekparameter.

Als de gebruiker op een van de links klikt voordat de prefetch is afgerond, heeft de browser de pagina /products misschien niet gekregen. In dit geval weet de browser niet of de HTTP-header No-Vary-Search wordt opgenomen. De browser kan dan kiezen of de link opnieuw wordt opgehaald of dat wordt gewacht tot het prefetchen is afgerond om te zien of de link een No-Vary-Search HTTP-header bevat. Met de instelling expects_no_vary_search weet de browser dat de pagina-reactie naar verwachting een No-Vary-Search HTTP-header bevat en dat de browser moet wachten tot die prefetch is afgerond.

Opmerking: Alleen expects_no_vary_search gebruiken is niet genoeg om te zorgen dat een pagina met een andere zoekparameter opnieuw wordt gebruikt. Het is meer een hint voor de browser over wat deze kan verwachten. De server moet ook een No-Vary-Search HTTP-header retourneren, zodat de browser weet dat deze de pagina uit het cachegeheugen kan gebruiken, zelfs als de zoekparameter niet overeenkomt.

Je kunt ook meerdere parameters toevoegen aan expects_no_vary_search, gescheiden door een spatie (omdat No-Vary-Search een HTTP-gestructureerde kop is):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

Beperkingen voor speculatieregels en toekomstige verbeteringen

Speculatieregels zijn beperkt tot pagina's die op hetzelfde tabblad worden geopend, maar we werken eraan om die beperking te verminderen.

Standaard zijn prerenders beperkt tot pagina's met dezelfde oorsprong. Je kunt pre-rendering van cross-origin-pagina's op dezelfde site aanzetten (https://a.example.com kan bijvoorbeeld een pagina op https://b.example.com vooraf renderen). Als je dit wilt gebruiken, moet de gespeculeerde pagina (https://b.example.com in dit voorbeeld) zich aanmelden door een Supports-Loading-Mode: credentialed-prerender HTTP-header op te nemen. Anders annuleert Chrome de speculatie.

Toekomstige versies kunnen ook pre-rendering toestaan voor cross-origin-pagina's die niet op dezelfde site staan, zolang er geen cookies bestaan voor de vooraf gerenderde pagina en de vooraf gerenderde pagina zich aanmeldt met een vergelijkbare Supports-Loading-Mode: uncredentialed-prerender HTTP-header.

Speculatieregels ondersteunen al cross-origin prefetching. Voor cross-origin prefetching op dezelfde site gelden geen beperkingen. Cross-origin prefetching op verschillende sites wordt alleen ondersteund als er geen cookies voor het cross-origin-domein bestaan. Als er cookies bestaan omdat de gebruiker die site eerder heeft bezocht, wordt de speculatie niet gebruikt en wordt er een fout getoond in DevTools.

Gezien deze huidige beperkingen is er een patroon dat de gebruikerservaring voor zowel interne als externe links kan verbeteren, waar mogelijk: URL's van dezelfde oorsprong vooraf renderen en proberen cross-origin-URL's vooraf op te halen:

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }],
    "prefetch": [{
      "where": { "not": { "href_matches": "/*" } },
      "eagerness": "moderate"
    }]
  }
</script>

De beperking om cross-origin-speculaties voor cross-origin-links standaard te voorkomen, is nodig voor de beveiliging. Het is een verbetering ten opzichte van <link rel="prefetch"> voor cross-origin-bestemmingen die ook geen cookies sturen, maar wel proberen de prefetch uit te voeren. Dit leidt tot een verspilde prefetch die opnieuw moet worden gestuurd of, erger nog, tot het laden van de onjuiste pagina.

Ondersteuning voor de Speculation Rules API detecteren

Je kunt ondersteuning voor de Speculation Rules API detecteren met standaard HTML-controles:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

Speculatieregels dynamisch toevoegen via JavaScript

Dit is een voorbeeld van hoe je een speculatieregel voor prerender toevoegt met JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Je kunt een demo van pre-rendering met de Speculation Rules API, met JavaScript-invoeging, bekijken op deze demopagina voor pre-rendering.

Als je een <script type = "speculationrules">-element rechtstreeks in de DOM invoegt met innerHTML, worden de speculatieregels om veiligheidsredenen niet geregistreerd. Dit moet worden toegevoegd zoals eerder getoond. Content die dynamisch wordt ingevoegd met innerHTML en die nieuwe links bevat, wordt wel opgepikt door bestaande regels op de pagina.

Als je het deelvenster Elementen in Chrome DevTools rechtstreeks bewerkt om het element <script type = "speculationrules"> toe te voegen, worden de speculatieregels niet geregistreerd. In plaats daarvan moet het script om dit dynamisch aan de DOM toe te voegen, worden uitgevoerd vanuit de console om de regels in te voegen.

Speculatieregels toevoegen via een Tag Manager

Als je speculatieregels wilt toevoegen met een tagmanager zoals Google Tag Manager (GTM), moet je deze invoegen via JavaScript in plaats van het element <script type = "speculationrules"> rechtstreeks via GTM toe te voegen. Dit heeft dezelfde redenen als eerder vermeld:

Configuratie van aangepaste HTML-tag in Google Tag Manager — Speculatieregels toevoegen via Google Tag Manager.

In dit voorbeeld wordt var gebruikt, omdat GTM const niet ondersteunt.

Speculatieregels annuleren

Als je speculatieregels verwijdert, wordt de pre-rendering geannuleerd. Tegen de tijd dat dit gebeurt, zijn er waarschijnlijk al resources gebruikt om de prerender te starten. Daarom raden we je aan niet te prerenderen als de kans bestaat dat je de prerender moet annuleren. Aan de andere kant kunnen gecachte bronnen nog steeds worden hergebruikt, dus annuleringen zijn misschien niet helemaal verspild en kunnen nog steeds nuttig zijn voor toekomstige speculaties en navigaties.

Browser Support

Source

Speculaties kunnen ook worden geannuleerd met de HTTP-header Clear-Site-Data met de instructies prefetchCache en prerenderCache.

Dit kan handig zijn als de status op de server wordt gewijzigd. Bijvoorbeeld als je een API voor toevoegen aan winkelwagen of een API voor in- of uitloggen aanroept.

In het ideale geval worden deze statusupdates doorgegeven aan vooraf gerenderde pagina's met API's zoals de Broadcast Channel API. Als dit niet mogelijk is of totdat deze logica is geïmplementeerd, kan het makkelijker zijn om de speculatie te annuleren.

Speculatieregels en Content Security Policy

Omdat speculatieregels een <script>-element gebruiken, ook al bevatten ze alleen JSON, moeten ze worden opgenomen in het script-src-Content-Security-Policy als de site dit gebruikt, met een hash of nonce.

Er kan een nieuwe inline-speculation-rules worden toegevoegd aan script-src, zodat <script type="speculationrules">-elementen die zijn geïnjecteerd vanuit hash- of nonce-scripts kunnen worden ondersteund. Dit biedt geen ondersteuning voor regels die zijn opgenomen in de oorspronkelijke HTML. Regels moeten dus worden geïnjecteerd door JavaScript voor sites die een strikt CSP gebruiken.

Prerendering detecteren en uitzetten

Prerender is meestal een positieve ervaring voor gebruikers, omdat pagina's snel worden gerenderd, vaak onmiddellijk. Dit is voordelig voor zowel de gebruiker als de site-eigenaar, omdat vooraf gerenderde pagina's een betere gebruikerservaring bieden die anders misschien moeilijk te bereiken is.

Er kunnen echter gevallen zijn waarin je niet wilt dat pagina's vooraf worden gerenderd, bijvoorbeeld als de status van pagina's verandert, op basis van het eerste verzoek of op basis van JavaScript dat op de pagina wordt uitgevoerd.

Voorrenderen aan- en uitzetten in Chrome

Voorrenderen staat alleen aan voor Chrome-gebruikers met de instelling Pagina's vooraf laden in chrome://settings/performance/. Daarnaast staat prerenderen uit op apparaten met weinig geheugen of als het besturingssysteem in de modus Databesparing of Energiebesparing staat. Ga naar het gedeelte Chrome-limieten.

Prerenderen aan de serverzijde detecteren en uitzetten

Vooraf gerenderde pagina's worden verstuurd met de HTTP-header Sec-Purpose:

Sec-Purpose: prefetch;prerender

Voor vooraf opgehaalde pagina's die de Speculation Rules API gebruiken, is deze kop ingesteld op prefetch:

Sec-Purpose: prefetch

Servers kunnen reageren op basis van deze header om speculatieverzoeken te registreren, andere content te retourneren of te voorkomen dat een prerender plaatsvindt. Als er een niet-geslaagde uiteindelijke reactiecode wordt geretourneerd (dat wil zeggen, niet in het bereik 200-299 na omleidingen), wordt de pagina niet vooraf gerenderd en wordt een eventuele vooraf opgehaalde pagina verwijderd. 204- en 205-reacties zijn ook niet geldig voor prerendering, maar wel voor prefetch.

Als je niet wilt dat een bepaalde pagina vooraf wordt gerenderd, kun je het beste een niet-2XX-reactiecode (zoals 503) retourneren om te zorgen dat dit niet gebeurt. Voor de beste gebruikerservaring raden we je aan om prerendering toe te staan, maar acties die alleen mogen plaatsvinden als de pagina daadwerkelijk wordt bekeken, uit te stellen met JavaScript.

Prerenderen waarnemen in JavaScript

De document.prerendering-API retourneert true terwijl de pagina vooraf wordt gerenderd. Pagina's kunnen dit gebruiken om bepaalde activiteiten tijdens de prerendering te voorkomen of uit te stellen totdat de pagina daadwerkelijk wordt geactiveerd.

Nadat een vooraf gerenderd document is geactiveerd, wordt PerformanceNavigationTiming van activationStart ook ingesteld op een tijd die niet nul is en die de tijd vertegenwoordigt tussen het moment waarop de prerender is gestart en het document daadwerkelijk is geactiveerd.

Je kunt een functie gebruiken om te controleren op prerendering en geprerenderde pagina's, zoals de volgende:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

De makkelijkste manier om te zien of een pagina vooraf is gerenderd (volledig of gedeeltelijk), is door DevTools te openen nadat de pagina is geactiveerd en performance.getEntriesByType('navigation')[0].activationStart te typen in de console. Als er een andere waarde dan 0 wordt geretourneerd, weet je dat de pagina vooraf is gerenderd:

Console in Chrome DevTools met een positieve activationStart die aangeeft dat de pagina vooraf is gerenderd — Prerender testen in de console.

Als de pagina wordt geactiveerd doordat de gebruiker de pagina bekijkt, wordt de gebeurtenis prerenderingchange verzonden naar de document. Dit kan dan worden gebruikt om activiteiten aan te zetten die eerder standaard werden gestart als de pagina werd geladen, maar die je wilt uitstellen totdat de pagina daadwerkelijk door de gebruiker wordt bekeken.

Met deze API's kan frontend JavaScript vooraf gerenderde pagina's detecteren en hierop reageren.

Waarschuwing: De PerformanceNavigationTiming.type gebruikt de waarde prerender niet. Die was voor het oudere, oorspronkelijke navigatietype <link rel="prerender"...>. Dit kan in de toekomst veranderen, maar voorlopig moeten clients de document.prerendering API gebruiken om pre-rendering pagina's te identificeren en een veld dat niet nul is PerformanceNavigationTiming.activationStart om vooraf gerenderde pagina's te identificeren die sindsdien zijn geactiveerd.

Impact op de analyse

Analyse wordt gebruikt om websitegebruik te meten, bijvoorbeeld met Google Analytics om paginaweergaven en gebeurtenissen te meten. Of door prestatiestatistieken van pagina's te meten met Real User Monitoring (RUM).

Pagina's mogen alleen vooraf worden gerenderd als de kans groot is dat de pagina door de gebruiker wordt geladen. Daarom worden de opties voor prerendering van de Chrome-adresbalk alleen uitgevoerd als de kans zo groot is (meer dan 80% van de tijd).

Vooral als je de Speculation Rules API gebruikt, kunnen vooraf gerenderde pagina's invloed hebben op de analyse. Site-eigenaren moeten misschien extra code toevoegen om de analyse voor vooraf gerenderde pagina's alleen aan te zetten bij activering, omdat niet alle analyseproviders dit standaard doen.

Dit kun je doen met een Promise die wacht op de gebeurtenis prerenderingchange als een document vooraf wordt gerenderd of die onmiddellijk wordt opgelost als het nu is:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Een alternatieve aanpak is om analytische activiteiten uit te stellen totdat de pagina voor het eerst zichtbaar wordt gemaakt. Dit dekt zowel het prerendering-geval als wanneer tabbladen op de achtergrond worden geopend (bijvoorbeeld door met de rechtermuisknop te klikken en te openen in een nieuw tabblad):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

Hoewel dit logisch kan zijn voor analytische gegevens en vergelijkbare use cases, wil je in andere gevallen misschien meer content laden voor die use cases. Je kunt dan document.prerendering en prerenderingchange gebruiken om specifiek pre-rendering-pagina's te targeten.

Andere content tegenhouden tijdens prerendering

Dezelfde API's die we eerder hebben besproken, kunnen worden gebruikt om andere content tegen te houden tijdens de prerenderfase. Dit kunnen specifieke delen van JavaScript of hele scriptelementen zijn die je liever niet wilt uitvoeren tijdens de prerenderfase.

Bijvoorbeeld met dit script:

<script src="https://example.com/app/script.js" async></script>

U kunt dit wijzigen in een dynamisch ingevoegd scriptelement dat alleen wordt ingevoegd op basis van de vorige functie whenActivated:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Dit kan handig zijn om verschillende scripts tegen te houden die analyses bevatten of content weergeven op basis van de status of andere variabelen die tijdens een bezoek kunnen veranderen. Aanbevelingen, de inlogstatus of winkelwageniconen kunnen bijvoorbeeld allemaal worden tegengehouden om te zorgen dat de meest up-to-date informatie wordt getoond.

Hoewel dit misschien vaker gebeurt bij het gebruik van prerendering, gelden deze voorwaarden ook voor pagina's die worden geladen in de eerder genoemde achtergrondtabbladen (de functie whenFirstVisible kan dus worden gebruikt in plaats van whenActivated).

In veel gevallen moet de status idealiter ook worden gecontroleerd op algemene visibilitychange-wijzigingen. Als je bijvoorbeeld terugkeert naar een pagina die op de achtergrond is geplaatst, moeten alle winkelwagentellers worden geüpdatet met het nieuwste aantal artikelen in de winkelwagen. Dit is dus geen probleem dat specifiek is voor prerenderen, maar prerenderen maakt een bestaand probleem duidelijker.

Chrome vermindert de noodzaak om scripts of functies handmatig te wrappen door bepaalde API's tegen te houden, zoals eerder vermeld. Ook worden iframes van derden niet gerenderd, dus alleen content die hier bovenop komt, moet handmatig worden tegengehouden.

Prestaties meten

Voor het meten van prestatiestatistieken moet de analyse overwegen of het beter is om deze te meten op basis van de activeringstijd in plaats van de laadtijd van de pagina die browser-API's rapporteren.

Voor de Core Web Vitals, die door Chrome worden gemeten via het Chrome User Experience Report, is het de bedoeling dat de gebruikerservaring wordt gemeten. Deze worden dus gemeten op basis van de activeringstijd. Dit leidt vaak tot een LCP van 0 seconden, wat aantoont dat dit een geweldige manier is om uw Core Web Vitals te verbeteren.

Vanaf versie 3.1.0 is de web-vitals-bibliotheek geüpdatet om vooraf gerenderde navigaties op dezelfde manier te verwerken als Chrome Core Web Vitals meet. Deze versie markeert ook vooraf gerenderde navigaties voor die statistieken in het kenmerk Metric.navigationType als de pagina volledig of gedeeltelijk vooraf is gerenderd.

Vooraf renderen meten

Of een pagina vooraf is gerenderd, kun je zien aan een activationStart-vermelding van PerformanceNavigationTiming die niet nul is. Dit kan dan worden geregistreerd met een aangepaste dimensie of iets vergelijkbaars wanneer de paginaweergaven worden geregistreerd, bijvoorbeeld met de pagePrerendered-functie die eerder is beschreven:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

Zo kun je in je analyse zien hoeveel navigaties vooraf zijn gerenderd in vergelijking met andere typen navigatie. Ook kun je prestatiestatistieken of bedrijfsstatistieken koppelen aan deze verschillende navigatietypen. Snellere pagina's betekenen tevreden gebruikers, wat vaak een echte impact kan hebben op bedrijfsmaatregelen, zoals onze casestudy's laten zien.

Terwijl je de zakelijke impact meet van pagina's vooraf renderen voor directe navigatie, kun je beslissen of het de moeite waard is om meer moeite te investeren in het gebruik van deze technologie om meer navigatie vooraf te renderen of om te onderzoeken waarom pagina's niet vooraf worden gerenderd.

Hitpercentages meten

Naast het meten van de impact van pagina's die worden bezocht na een prerender, is het ook belangrijk om pagina's te meten die vooraf zijn gerenderd en daarna niet worden bezocht. Dit kan betekenen dat je te veel prerendert en waardevolle bronnen van de gebruiker gebruikt zonder dat dit veel voordeel oplevert.

Dit kan worden gemeten door een analysegebeurtenis te activeren wanneer speculatieregels worden ingevoegd (nadat is gecontroleerd of de browser prerendering ondersteunt met HTMLScriptElement.supports('speculationrules')) om aan te geven dat prerendering is aangevraagd. (Als er een pre-render is aangevraagd, betekent dit niet dat een pre-render is gestart of afgerond. Zoals eerder vermeld, is een pre-render een hint voor de browser en kan deze ervoor kiezen om pagina's niet vooraf te renderen op basis van gebruikersinstellingen, het huidige geheugengebruik of andere heuristieken.)

U kunt het aantal van deze gebeurtenissen dan vergelijken met de werkelijke paginaweergaven van de prerender. U kunt ook een andere gebeurtenis activeren bij activering als dat makkelijker te vergelijken is.

Het 'percentage geslaagde hits' kan dan worden benaderd door naar het verschil tussen deze 2 cijfers te kijken. Voor pagina's waarvoor je de Speculation Rules API gebruikt om de pagina's vooraf te renderen, kun je de regels aanpassen om een hoog hitpercentage te behouden. Zo houd je de balans tussen het gebruik van de bronnen van de gebruikers om ze te helpen en onnodig gebruik.

Houd er rekening mee dat er misschien prerendering plaatsvindt vanwege de prerendering van de adresbalk en niet alleen vanwege je speculatieregels. Je kunt de document.referrer controleren (die leeg is voor navigatie via de adresbalk, waaronder vooraf gerenderde navigatie via de adresbalk) als je deze wilt onderscheiden.

Kijk ook naar pagina's die geen prerenders hebben, omdat dit erop kan wijzen dat deze pagina's niet in aanmerking komen voor prerendering, zelfs niet vanuit de adresbalk. Dit betekent misschien dat u niet profiteert van deze prestatieverbetering. Het Chrome-team wil extra tools toevoegen om te testen of een pagina in aanmerking komt voor prerendering, misschien vergelijkbaar met de bfcache-testtool. Ook willen ze misschien een API toevoegen om aan te geven waarom een prerender is mislukt.

Impact op extensies

Ga naar de speciale post over Chrome-extensies: API uitbreiden om directe navigatie te ondersteunen voor meer informatie over aanvullende overwegingen waar extensie-auteurs rekening mee moeten houden voor vooraf gerenderde pagina's.

Feedback

Het Chrome-team is bezig met de ontwikkeling van prerendering en er zijn veel plannen om de reikwijdte van wat beschikbaar is gemaakt in de Chrome 108-release uit te breiden. We horen graag je feedback over de GitHub-repo of het gebruik van onze Issue Tracker. We kijken ernaar uit om casestudy's van deze spannende nieuwe API te horen en te delen.

Gerelateerde links

Erkenning

Thumbnailafbeelding door Marc-Olivier Jodoin op Unsplash

Pagina's vooraf renderen in Chrome voor onmiddellijke paginanavigatie Stay organized with collections Save and categorize content based on your preferences.

Een korte geschiedenis van prerenderen

Hoe wordt een pagina vooraf gerenderd?

Impact van prerendering

Voorspellingen van de adresbalk van Chrome bekijken

De Speculation Rules API

Lijst met URL's

Documentregels

Enthousiasme

Prefetch

Prerender until script

Chrome-limieten

Speculatieregels opnemen op een pagina

De HTTP-header Speculation-Rules

Tagveld voor speculatieregels

Veld target_hint voor speculatieregels

Speculatieregels en SPA's

Fouten opsporen in speculatieregels

Meerdere speculatieregels

No-Vary-Search-support

Beperkingen voor speculatieregels en toekomstige verbeteringen

Ondersteuning voor de Speculation Rules API detecteren

Speculatieregels dynamisch toevoegen via JavaScript

Speculatieregels toevoegen via een Tag Manager

Speculatieregels annuleren

Speculatieregels en Content Security Policy

Prerendering detecteren en uitzetten

Voorrenderen aan- en uitzetten in Chrome

Prerenderen aan de serverzijde detecteren en uitzetten

Prerenderen waarnemen in JavaScript

Impact op de analyse

Andere content tegenhouden tijdens prerendering

Prestaties meten

Vooraf renderen meten

Hitpercentages meten

Impact op extensies

Feedback

Gerelateerde links

Erkenning

Pagina's vooraf renderen in Chrome voor onmiddellijke paginanavigatie

De HTTP-header `Speculation-Rules`

Veld `target_hint` voor speculatieregels

`No-Vary-Search`-support