Gepubliceerd: 7 maart 2025, Laatst bijgewerkt: 23 oktober 2025
De Speculation Rules API stelt gebruikers in staat te profiteren van een prestatieverbetering door toekomstige paginanavigaties vooraf op te halen of weer te geven, wat resulteert in snellere – of zelfs directe – paginanavigatie.
De API is specifiek ontworpen met het oog op eenvoudige implementatie, maar er zijn enkele aandachtspunten waar met name complexe websites rekening mee moeten houden voordat ze de API gebruiken. Deze handleiding helpt website-eigenaren deze aandachtspunten te begrijpen.
Planning
Voordat je speculatieregels implementeert, is het de moeite waard om te overwegen hoe je de API implementeert (er zijn namelijk verschillende opties) en wat de kosten van speculaties zijn (dit zou je een idee moeten geven op welke pagina's je wilt speculeren).
Bepaal hoe de speculatieregels moeten worden geïmplementeerd.
Een van de eerste beslissingen die u moet nemen, is hoe u speculatieregels op uw site implementeert, aangezien u hiervoor verschillende methoden kunt gebruiken:
- Direct in de HTML van de pagina
- JavaScript gebruiken
- Het gebruik van een HTTP-header
Uiteindelijk hebben alle methoden hetzelfde effect, maar er kunnen voordelen zijn op het gebied van implementatiegemak en flexibiliteit.
Websites moeten de optie kiezen die het beste bij hen past en kunnen indien nodig zelfs een combinatie van deze opties gebruiken. Alternatief kunnen ze worden geïmplementeerd met behulp van een plugin (zoals de Speculative Loading plugin voor WordPress) of bibliotheken of platforms die de keuze voor u maken, maar het is toch de moeite waard om op de hoogte te zijn van de beschikbare opties.
Voeg speculatieregels direct toe aan de HTML van de pagina.
Speculatieregels kunnen direct op de pagina worden geïmplementeerd door het element <script type="speculationrules"> in de HTML op te nemen. Dit kan tijdens het bouwen van statische websites met sjablonen worden toegevoegd, of tijdens de uitvoering door de server wanneer de pagina wordt opgevraagd. Ze kunnen zelfs door edge workers in de HTML worden geïnjecteerd (hoewel de HTTP-header-methode die later in deze handleiding wordt besproken, daarvoor waarschijnlijk eenvoudiger is).
Hiermee kunt u statische regels voor de hele site toepassen, maar documentregels kunnen nog steeds dynamisch zijn doordat u de URL's kunt selecteren die vanaf de pagina moeten worden weergegeven door regels te gebruiken die worden geactiveerd door CSS-klassen:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
Het vorige script zal links met een prerender klasse vooraf renderen en op dezelfde manier prefetch-gegevens ophalen wanneer een link een prefetch klasse heeft. Dit stelt ontwikkelaars in staat om deze klassen in de HTML op te nemen om speculaties te activeren.
Naast het opnemen van deze klassen in de initiële HTML van een pagina, worden links ook automatisch gegenereerd als deze klassen dynamisch door uw app worden toegevoegd. Hierdoor kan uw app de generatie van deze klassen naar behoefte activeren (en verwijderen). Dit kan eenvoudiger zijn dan het aanmaken of verwijderen van meer specifieke generatieregels. Het is ook mogelijk om meerdere generatieregels per pagina op te nemen, bijvoorbeeld een basisregel die voor het grootste deel van de site geldt, en paginaspecifieke regels.
Als u echter meer specifieke speculatieregels wilt gebruiken, kunt u paginaspecifieke of sjabloonspecifieke regels instellen, waarmee u verschillende regels kunt toepassen op bepaalde pagina's of paginatypen.
Ten slotte kunnen server-side gerenderde pagina's ook dynamischere regels hebben op basis van de informatie die beschikbaar is voor de server, zoals analysegegevens voor die pagina of veelvoorkomende gebruikersroutes voor bepaalde pagina's.
Voeg speculatieregels toe met behulp van JavaScript.
Een alternatief voor het opnemen van de regels in een script op de pagina is om ze te injecteren met behulp van JavaScript. Dit kan minder aanpassingen aan paginasjablonen vereisen. Het injecteren van de regels via een tagmanager kan bijvoorbeeld een snelle manier zijn om speculatieregels uit te rollen (en maakt het ook mogelijk om ze snel weer uit te schakelen indien nodig).
Deze optie maakt ook dynamische, client-side regels mogelijk op basis van de interactie van de gebruiker met de pagina. Als de gebruiker bijvoorbeeld een artikel aan het winkelmandje toevoegt, kunt u de afrekenpagina vooraf renderen. U kunt dit ook gebruiken om speculaties te activeren op basis van bepaalde voorwaarden. Hoewel de API een instelling voor responsiviteit bevat die eenvoudige interactiegebaseerde regels mogelijk maakt, stelt JavaScript ontwikkelaars in staat om hun eigen logica te gebruiken om te bepalen wanneer en op welke pagina('s) er gespeculeerd moet worden.
Zoals eerder vermeld, is een alternatieve aanpak voor het invoegen van nieuwe regels het gebruik van een basisregel op de pagina, waarbij JavaScript de regels activeert door de juiste klassen aan links toe te voegen, zodat deze aan de regel voldoen.
Voeg speculatieregels toe met behulp van een HTTP-header.
De laatste optie voor ontwikkelaars is om de regels via een HTTP-header toe te voegen:
Speculation-Rules: "/speculationrules.json"
Er gelden enkele aanvullende vereisten voor de manier waarop de regelsresource (in dit voorbeeld /speculationrules.json ) wordt aangeleverd en gebruikt.
Deze optie maakt een eenvoudigere implementatie via CDN's mogelijk zonder dat de documentinhoud hoeft te worden aangepast. Dit betekent wel dat het dynamisch wijzigen van de speculatieregels met JavaScript niet mogelijk is. Documentregels met CSS-selectortriggers kunnen echter nog steeds dynamische wijzigingen toestaan, bijvoorbeeld door de prerender -klasse van een link te verwijderen.
Net als bij de JavaScript-optie, maakt het implementeren van speculatieregels met een HTTP-header het mogelijk om ze onafhankelijk van de site-inhoud te implementeren. Dit kan het toevoegen en verwijderen van regels vereenvoudigen zonder de hele site opnieuw op te bouwen.
Houd rekening met de kostenimplicaties
Voordat je speculatieregels implementeert, is het verstandig even stil te staan bij de kostenimplicaties voor zowel je gebruikers als je website met deze API. De kosten omvatten bandbreedte (wat zowel gebruikers als websites geld kost!) en verwerkingskosten (zowel aan de client- als aan de serverzijde).
Houd rekening met de kosten voor gebruikers.
Speculatief laden betekent dat je een weloverwogen gok doet naar waar een gebruiker mogelijk naartoe navigeert. Als die navigatie echter niet plaatsvindt, heb je mogelijk resources verspild. Daarom is het belangrijk om rekening te houden met de impact op gebruikers, met name:
- Er wordt extra bandbreedte gebruikt om die toekomstige navigatiegegevens te downloaden, vooral op mobiele apparaten waar de bandbreedte mogelijk beperkter is.
- Extra verwerkingskosten voor het renderen van die pagina's bij gebruik van prerendering.
Bij volledig accurate voorspellingen zijn er geen extra kosten, omdat bezoekers die pagina's vervolgens toch wel zullen bezoeken. Het enige verschil is dat die kosten vooraf worden gemaakt. Het is echter onmogelijk om de toekomst volledig accuraat te voorspellen, en hoe agressiever de speculatiestrategie, hoe groter het risico op verspilling.
Chrome heeft dit probleem zorgvuldig overwogen en de API bevat een aantal functies waardoor de kosten veel lager zijn dan je misschien denkt . Met name door de HTTP-cache te hergebruiken en geen iframes van andere oorsprong te laden, zijn de kosten voor het vooraf renderen van een navigatie op dezelfde site vaak aanzienlijk lager dan die van een volledige pagina zonder gecachede bronnen. Hierdoor zijn speculatieve laadprocessen minder kostbaar dan men zou verwachten.
Zelfs met deze beveiligingsmaatregelen moeten websites echter zorgvuldig overwegen welke pagina's ze speculatief laden en wat de kosten voor de gebruiker van dergelijke speculaties zijn. Goede kandidaten voor speculatief laden zijn pagina's die redelijkerwijs met een hoge mate van zekerheid te voorspellen zijn (bijvoorbeeld op basis van analyses of veelvoorkomende gebruikerstrajecten) en waarbij de kosten laag zijn (bijvoorbeeld minder uitgebreide pagina's).
Je kunt ook overwegen welke JavaScript-code pas geactiveerd moet worden. Net als bij het lazy loading van content totdat deze nodig is, kan dit de pre-rendering efficiënter maken en tegelijkertijd een veel betere gebruikerservaring opleveren. Met minder speculaties kun je wellicht vaker of sneller speculaties uitvoeren.
Als dit niet mogelijk is, wordt een minder agressieve strategie met gematigde of conservatieve 'eagerness'-regels aanbevolen. Als alternatief kunt u prefetch gebruiken, wat aanzienlijk minder kost dan prerendering wanneer het vertrouwen laag is, en vervolgens overschakelen naar een volledige prerendering als het vertrouwen toeneemt – bijvoorbeeld wanneer er met de muis over een link wordt bewogen of er daadwerkelijk op wordt geklikt.
Houd rekening met extra belasting van de backend.
Naast de extra kosten voor de gebruiker, moeten website-eigenaren ook rekening houden met hun eigen infrastructuurkosten. Als elke pagina twee, drie of zelfs meer paginaweergaven vereist, kunnen de backendkosten door het gebruik van deze API toenemen.
Door ervoor te zorgen dat uw pagina's en bronnen cachebaar zijn, vermindert u de belasting van uw servers aanzienlijk en daarmee ook het algehele risico. In combinatie met een CDN zouden uw servers minimaal extra belast moeten worden, maar houd wel rekening met eventuele hogere kosten voor het CDN.
Een server of CDN kan ook worden gebruikt om de resultaten van de speculatie te beheren, zoals aangegeven door de HTTP-header `sec-purpose` . Cloudflare's Speed Brain-product staat bijvoorbeeld alleen speculaties toe die al in de cache van een edge-server van een CDN zijn opgeslagen en stuurt geen verzoeken terug naar de oorspronkelijke server.
Omdat speculatieve laadprocessen doorgaans worden gebruikt voor pagina's die rechtstreeks van dezelfde bron afkomstig zijn, hebben gebruikers de gedeelde bronnen al in de cache van hun browser opgeslagen – ervan uitgaande dat ze überhaupt cachebaar zijn – waardoor een speculatief laadproces meestal minder kostbaar is dan een volledige paginalading.
Vind de juiste balans tussen te veel en te weinig speculeren.
De sleutel tot het optimaal benutten van de Speculation Rules API ligt in het vinden van de juiste balans tussen te veel speculeren – dat wil zeggen, wanneer de kosten onnodig worden betaald en de speculatie niet wordt benut – en te conservatief speculeren – ofwel te weinig, ofwel te laat, waardoor er weinig voordeel wordt behaald.
Waar de kosten laag zijn (bijvoorbeeld bij kleine, statisch gegenereerde pagina's die in de cache van CDN-edge-nodes worden opgeslagen), kun je het je veroorloven om agressiever te speculeren.
Voor grotere, complexere pagina's die mogelijk niet in de CDN-cache kunnen worden opgeslagen, is echter meer voorzichtigheid geboden. Ook pagina's die veel resources verbruiken, kunnen netwerkbandbreedte of processorkracht in beslag nemen, wat een negatieve invloed kan hebben op de huidige pagina. Het doel van de API is om de prestaties te verbeteren, dus prestatieverminderingen zijn absoluut ongewenst! Dit is nog een reden om het aantal vooraf gerenderde pagina's te beperken tot maximaal één of twee (merk ook op dat Chrome het aantal vooraf gerenderde pagina's beperkt tot twee of tien, afhankelijk van de 'eagerness').
Stappen om speculatieregels te implementeren
Zodra je hebt besloten hoe je speculatieregels wilt implementeren, moet je vervolgens plannen waarop je wilt speculeren en hoe je dit gaat uitrollen. Eenvoudigere sites, zoals statische persoonlijke blogs, kunnen wellicht direct overgaan tot het volledig vooraf renderen van bepaalde pagina's, maar complexere sites brengen extra complexiteiten met zich mee waarmee rekening moet worden gehouden.
Begin met prefetch
Prefetch is doorgaans relatief veilig om te implementeren voor de meeste websites en dit is de eerste aanpak die door velen wordt gekozen, waaronder grootschalige uitrolprojecten zoals Cloudflare en WordPress .
De belangrijkste aandachtspunten zijn of het vooraf ophalen van een URL statuswijzigingen en serverkosten met zich meebrengt, met name voor pagina's die niet in de cache kunnen worden opgeslagen. Idealiter zouden statuswijzigingen – bijvoorbeeld het vooraf ophalen van een /logout -pagina – niet via GET links moeten worden geïmplementeerd, maar helaas komt dit op het web vaak voor.
Dergelijke URL's kunnen specifiek van de regels worden uitgesloten:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Prefetches kunnen worden beperkt tot veelvoorkomende navigaties van de ene pagina naar de andere, of voor alle links van dezelfde oorsprong bij hover (of op viewport gebaseerde heuristieken op mobiel) of klik, met behulp van de instelling eagerness moderate ' of conservative . De conservative instelling brengt het laagste risico met zich mee, maar ook de laagste potentiële winst. Als je hiermee begint, streef er dan naar om minstens naar moderate te gaan, maar idealiter levert eager meer prestatievoordelen op (en vervolgens verder upgraden naar prerender waar dit zinvol is).
Vooraf renderen met een laag risico
Prefetch-speculaties zijn gemakkelijker te implementeren, maar het ultieme prestatievoordeel voor de API wordt behaald met prerendering. Dit kan extra aandachtspunten met zich meebrengen wanneer de pagina niet kort na de speculatie wordt bezocht (waar we in de volgende sectie op terugkomen), maar met een moderate of conservative prerendering, waarbij navigatie waarschijnlijk kort daarna plaatsvindt, kan dit een relatief risicoarme volgende stap zijn.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Haal veelgebruikte pagina's vooraf op om niet-eager prerenders te verbeteren.
Een veelgebruikte tactiek is om bij het laden van de pagina een kleiner aantal veelbezochte volgende pagina's vooraf op te halen met een eager instelling (door ze in een URL-lijst op te geven of door selector_matches te gebruiken), en vervolgens de rest van de pagina's vooraf weer te geven met een moderate instelling. Omdat het vooraf ophalen van de HTML waarschijnlijk al is voltooid tegen de tijd dat de muis over de link beweegt, levert dit een voordeel op ten opzichte van het direct vooraf weergeven van de pagina's zonder voorafgaande ophaling.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Eerdere prerenders
Hoewel moderate documentregels een relatief risicoarm gebruik van de API mogelijk maken met een bijbehorende eenvoudige implementatie, is dit vaak niet voldoende tijd voor een volledige prerendering. Om de directe navigatie te realiseren die deze API biedt, zult u waarschijnlijk verder moeten gaan en pagina's sneller moeten prerenderen.
Dit wordt bereikt met een statische lijst van URL's (zoals in het prefetch-voorbeeld eerder) of met selector_matches die een klein aantal URL's identificeren (idealiter één of twee pagina's), waarbij documentregels de overige URL's afdekken:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Dit vereist mogelijk een verkeersanalyse om de volgende navigatie zo nauwkeurig mogelijk te voorspellen. Inzicht in de typische klanttrajecten op uw website kan ook helpen bij het identificeren van geschikte kandidaten voor speculatief laden.
Overstappen op eager of immediate prerendering kan ook meer aandachtspunten met zich meebrengen op het gebied van analyses, advertenties en JavaScript, en de noodzaak om een vooraf gerenderde pagina actueel te houden , of zelfs om speculaties over statuswijzigingen te annuleren of te vernieuwen .
Analyses, advertenties en JavaScript
Bij het gebruik van prerendering moet bij complexere websites ook rekening worden gehouden met de impact op de analyses. Je wilt doorgaans geen paginaweergave (of advertentieweergave) registreren wanneer de pagina wordt gesimuleerd, en alleen wanneer de simulatie is geactiveerd.
Sommige analyseproviders (zoals Google Analytics) en advertentieproviders (zoals Google Publisher Tag) ondersteunen al speculatieregels en registreren pas weergaven wanneer de pagina is geactiveerd. Andere providers of aangepaste analysesystemen die u hebt geïmplementeerd, vereisen mogelijk extra aandacht. We houden een lijst bij van bekende providers die speculatieregels ondersteunen.
Je kunt controles aan JavaScript toevoegen om te voorkomen dat specifieke stukjes code worden uitgevoerd totdat pagina's zijn geactiveerd of zichtbaar zijn gemaakt , en zelfs hele <script> -elementen in dergelijke controles plaatsen . Wanneer pagina's tagmanagers gebruiken om dergelijke scripts te injecteren, is het mogelijk om dit allemaal in één keer aan te pakken door het tagmanager-script zelf uit te stellen.
Op dezelfde manier bieden toestemmingsmanagers de mogelijkheid om scripts van derden uit te stellen tot het moment van activering. Google werkt samen met verschillende platforms voor toestemmingsmanagers om ze geschikt te maken voor prerendering, en we helpen graag anderen die hetzelfde willen doen. PubTech is een van die bedrijven die ontwikkelaars de keuze biedt om hun JavaScript tijdens prerendering wel of niet uit te voeren .
Voor applicatiecode kunt u op vergelijkbare wijze een wijziging toevoegen om de uitvoering van code uit te stellen tot na activering, met name wanneer de pagina de JavaScript-code niet nodig heeft om te renderen. Dit is een snellere en veiligere optie, maar betekent wel dat alle code in één keer wordt uitgevoerd bij activering. Dit kan leiden tot veel werk tijdens de activering, wat de INP ( Input/Node Page) kan beïnvloeden, vooral omdat de pagina er volledig geladen en klaar voor interactie uit kan zien.
Daarnaast zal het uitstellen van JavaScript, als bepaalde content afhankelijk is van JavaScript (bijvoorbeeld client-side gerenderde content), de positieve impact op LCP en CLS die prerendering kan hebben, verminderen. Een meer gerichte aanpak, waarbij meer JavaScript tijdens de prerenderingfase wordt uitgevoerd, zal een betere gebruikerservaring opleveren, maar is mogelijk minder eenvoudig te implementeren.
Het uitstellen van veel scripttags kan in eerste instantie een goede strategie zijn voor complexere websites. Om echter optimaal te profiteren van de API, zou het uiteindelijke doel moeten zijn om zoveel mogelijk JavaScript tijdens de prerendering uit te voeren.
Websites die zich zorgen maken over analyses of advertenties, kunnen het beste beginnen met prefetch , waar deze aspecten minder een probleem vormen, terwijl ze onderzoeken wat er nodig is om prerendering te ondersteunen.
Speculaties over het bijwerken van de pre-rendering
Bij het vooraf renderen van pagina's vóór de navigatie bestaat het risico dat de vooraf gerenderde pagina verouderd raakt. Een voorbeeld hiervan is een e-commercewebsite waar een vooraf gerenderde pagina een winkelmandje kan bevatten – ofwel een volledig gevuld winkelmandje, ofwel slechts een teller die het aantal artikelen in het winkelmandje weergeeft op andere pagina's. Als er meer artikelen aan het winkelmandje worden toegevoegd en vervolgens naar een vooraf gerenderde pagina wordt genavigeerd, kan het verwarrend zijn voor de gebruiker om de oude status van het winkelmandje te zien.
Dit is geen nieuw probleem en gebruikers die meerdere tabbladen in hun browser open hebben, ondervinden hetzelfde probleem. Bij vooraf gerenderde pagina's is dit echter waarschijnlijker en onverwachtser, omdat de gebruiker de prerendering niet bewust heeft geactiveerd.
De Broadcast Channel API is een manier om een pagina in de browser in staat te stellen updates zoals deze naar andere pagina's te verzenden. Dit zou ook het probleem met meerdere tabbladen oplossen. Vooraf gerenderde pagina's kunnen naar broadcastberichten luisteren, maar kunnen pas zelf broadcastberichten verzenden nadat ze geactiveerd zijn.
Als alternatief kunnen vooraf gerenderde pagina's updates ontvangen via de server (met behulp van een periodieke fetch() -functie of een WebSocket verbinding), maar dit kan leiden tot vertragingen in de updates.
Voorrenderingsspeculaties annuleren of vernieuwen
Het bijwerken van vooraf gerenderde pagina's is de aanbevolen methode om deze te blijven gebruiken en verwarring bij gebruikers te voorkomen. Indien dit niet mogelijk is, kunnen speculaties worden geannuleerd.
Dit kan ook worden gebruikt om binnen de limieten van Chrome te blijven als websites andere pagina's willen vooraf renderen die waarschijnlijk vaker bezocht zullen worden.
Om speculaties te annuleren, moet u de speculatieregels van de pagina verwijderen, of klassen of andere overeenkomende criteria verwijderen als u die aanpak gebruikt. Als alternatief kan de gespeculeerde pagina window.close() aanroepen als deze detecteert dat deze niet langer actueel is. Als de pagina dit echter zelf kan detecteren, is het beter om de status bij te werken om deze weer actueel te maken.
Het is ook mogelijk om deze regels (of overeenkomende criteria) opnieuw in te voegen, zodat pagina's opnieuw kunnen worden geladen (hoewel het meestal beter is om een bestaande pagina up-to-date te houden, omdat dit minder tijdrovend is). Nadat speculatieregels zijn verwijderd, moet het opnieuw invoegen in een nieuwe microtaak of later gebeuren, zodat de browser de verwijderingen kan opmerken en de speculaties kan annuleren. Een manier om alle scripts voor speculatieregels te verwijderen, wordt in het volgende voorbeeld getoond:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
Het verwijderen van regels annuleert bestaande nep-regels (of prefetches), maar het opnieuw invoegen van regels zal alleen speculaties uitvoeren over onmiddellijke of enthousiaste regels (inclusief URL-lijstregels met de standaardinstelling 'onmiddellijk'). Gematigde of conservatieve speculaties worden echter wel verwijderd, maar niet automatisch opnieuw geactiveerd totdat er opnieuw interactie met de link plaatsvindt.
Deze vernieuwingsoptie is niet beperkt tot regels die met JavaScript zijn ingevoegd. Statische regels die in de HTML zijn opgenomen, kunnen op dezelfde manier worden verwijderd of gewijzigd, aangezien dit een standaard DOM-wijziging is. Regels voor HTTP-speculatie kunnen niet worden verwijderd, maar overeenkomende criteria (bijvoorbeeld prerender klassen) kunnen wel worden verwijderd en opnieuw worden toegevoegd met JavaScript.
Chrome heeft ook een Clear-Site-Data HTTP-header toegevoegd waarmee serverreacties prefecturen of prerenders kunnen annuleren (bijvoorbeeld wanneer een verzoek tot het bijwerken van het winkelmandje wordt gedaan).
Meet de impact
Na het implementeren van speculatieregels moet je het succes meten en niet zomaar aannemen dat het automatisch sneller is. Zoals eerder vermeld, kan overmatige speculatie juist leiden tot prestatievermindering als de client of server overbelast raakt.
Bij een implementatie met meerdere stappen (prefetch, low-risk prerenders en vervolgens early prerenders) moet je bij elke stap metingen uitvoeren.
Hoe meet je succes?
Speculatieregels zouden een positieve impact moeten hebben op belangrijke prestatie-indicatoren zoals LCP (en mogelijk ook op CLS en INP), maar dit is mogelijk niet direct zichtbaar in de algemene statistieken op siteniveau. Dit komt doordat sites voornamelijk uit andere navigatietypen kunnen bestaan (bijvoorbeeld landingspagina's) of doordat navigaties vanaf dezelfde oorsprong al snel genoeg zijn, waardoor zelfs een drastische verbetering ervan mogelijk geen invloed heeft op de 75e percentielstatistieken zoals gerapporteerd in het Chrome User Experience-rapport (CrUX) .
Je kunt de pagina-navigatietypen in CruX gebruiken om te controleren welk percentage van de navigaties via navigate_cache of prerender verloopt en of dat percentage in de loop van de tijd toeneemt. Voor een gedetailleerde analyse is het echter wellicht nodig om Real User Monitoring te gebruiken om je data te segmenteren in veronderstelde navigaties en te zien hoeveel sneller deze zijn dan andere navigaties.
Hoe meet je verbruik en verspilling?
Een andere belangrijke overweging is om te meten of je wel op de juiste pagina's speculeert. Dit voorkomt verspilling en helpt je de beste pagina's te selecteren om optimaal van deze API te profiteren.
Helaas kan de pagina die de speculaties initieert de status van de speculatiepogingen niet direct zien. Bovendien kan niet worden aangenomen dat pogingen zijn geactiveerd, aangezien de browser speculaties onder bepaalde omstandigheden kan blokkeren . Deze moeten daarom op de pagina zelf worden gemeten. Dit vereist ook het controleren van twee API's om te zien of de pagina aan het speculeren is of heeft gespeculeerd:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
Deze pagina kan de speculatiepoging vervolgens registreren op de backendservers.
Een complicatie bij analyses is dat sommige aanbieders (zoals Google Analytics) rekening houden met de pre-rendering en analyseverzoeken negeren totdat de pagina is geactiveerd – zelfs afzonderlijke gebeurtenisoproepen. Daarom moeten gebruikers van Google Analytics een alternatief gebruiken: server-side logging.
Het is ook mogelijk om dit aan de clientzijde te doen, waarbij elke vooraf gerenderde pagina de prerender in gedeelde opslag vastlegt, en de aanroepende pagina dit uitleest. localStorage werkt het beste, omdat het kan worden uitgelezen wanneer een pagina wordt verlaten (merk op dat sessionStorage niet kan worden gebruikt, omdat deze een speciale afhandeling heeft voor vooraf gerenderde pagina's ). Houd er echter rekening mee dat localStorage niet transactioneel veilig is en dat andere pagina's dit mogelijk tegelijkertijd bijwerken als er meerdere pagina's vooraf worden gerenderd. Deze demo gebruikt een unieke hash en afzonderlijke vermeldingen om problemen hiermee te voorkomen.
Conclusie
Speculatieregels bieden de mogelijkheid om de prestaties van uw pagina aanzienlijk te verbeteren. Deze handleiding geeft advies over aandachtspunten bij de implementatie van deze API om potentiële problemen te voorkomen en de API optimaal te benutten.
Door de implementatie vooraf te plannen, voorkomt u herwerk. Vooral voor complexere websites is een gefaseerde uitrol aan te raden, beginnend met prefetch, gevolgd door prerendering met een laag risico en vervolgens vroege prerendering. Tot slot is het belangrijk om de verbeteringen te meten, evenals het gebruik en de verspilling, om er zeker van te zijn dat u deze API optimaal benut.