Gepubliceerd: 7 maart 2025
Met de Speculation Rules API kunnen gebruikers profiteren van een prestatieverbetering door toekomstige paginanavigatie vooraf op te halen of vooraf weer te geven, voor snellere of zelfs directe paginanavigatie.
De API is specifiek ontworpen met het oog op eenvoudige implementatie, maar er zijn enkele overwegingen waarmee vooral complexe sites rekening moeten houden voordat ze deze gebruiken. Deze gids helpt site-eigenaren deze overwegingen te begrijpen.
Planning
Voordat u speculatieregels implementeert, is het de moeite waard om te overwegen hoe u de API implementeert (aangezien er een paar keuzes zijn), en ook de kosten van speculaties (die u zouden moeten begeleiden bij het bepalen op welke pagina's u moet speculeren).
Bepaal hoe u de speculatieregels implementeert
Een van de eerste beslissingen die u moet nemen, is hoe u speculatieregels op uw site implementeert. Er zijn namelijk verschillende methoden die u kunt gebruiken:
- Direct in de HTML van de pagina
- JavaScript gebruiken
- Een HTTP-header gebruiken
Uiteindelijk heeft elke methode hetzelfde effect, maar er kunnen voordelen zijn in termen van implementatiegemak en flexibiliteit.
Sites moeten de optie kiezen die het beste bij hen past, en kunnen indien nodig zelfs een combinatie van deze opties gebruiken. Als alternatief kunnen ze worden geïmplementeerd met behulp van een plug-in (zoals de Speculative Loading-plug-in voor WordPress) of bibliotheken of platforms die mogelijk de keuze voor u maken, maar het is toch de moeite waard om op de hoogte te zijn van de beschikbare opties.
Neem speculatieregels rechtstreeks op in de HTML van de pagina
Speculatieregels kunnen rechtstreeks op de pagina worden geïmplementeerd door het <script type="speculationrules"> element in de HTML op te nemen. Dit kan worden toegevoegd tijdens het bouwen van statische sites met behulp van sjablonen, of tijdens runtime door de server wanneer de pagina wordt opgevraagd. Ze kunnen zelfs door edge-workers in HTML worden geïnjecteerd (hoewel de HTTP-headermethode die verderop in deze handleiding wordt besproken daar waarschijnlijk gemakkelijker voor is).
Hierdoor kunt u statische regels voor de hele site opnemen, maar documentregels kunnen nog steeds dynamisch zijn doordat u de URL's kunt kiezen die vanaf de pagina moeten worden weergegeven door regels te gebruiken die door CSS-klassen moeten worden geactiveerd:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
Het vorige script zal links vooraf renderen met een prerender -klasse, en op dezelfde manier prefetchen wanneer een link een prefetch -klasse heeft. Hierdoor kunnen ontwikkelaars deze klassen in de HTML opnemen om speculaties uit te lokken.
Naast het opnemen van links in deze klassen in de initiële HTML van een pagina, wordt er ook gespeculeerd over links als deze klassen dynamisch door uw app worden toegevoegd, waardoor uw app indien nodig speculaties kan activeren (en verwijderen). Dit kan eenvoudiger zijn dan het creëren of schrappen van specifiekere speculatieregels. Het is ook mogelijk om meerdere speculatieregels per pagina per pagina op te nemen als u wilt dat een basisregel wordt gebruikt door het grootste deel van de site, en paginaspecifieke regel(s).
Als u echter specifiekere speculatieregels moet gebruiken, kunnen paginaspecifieke of sjabloonspecifieke regels andere regels toestaan voor bepaalde pagina's of paginatypen.
Ten slotte kunnen op de server weergegeven pagina's ook meer dynamische regels hebben, gebaseerd op de informatie die beschikbaar is voor de server, zoals analytische informatie voor die pagina of algemene gebruikerstrajecten voor bepaalde pagina's.
Voeg speculatieregels toe met JavaScript
Een alternatief voor het opnemen van de regels in een on-page script is om ze te injecteren met JavaScript. Hiervoor zijn mogelijk minder updates van paginasjablonen nodig. Als u bijvoorbeeld de regels laat injecteren door een tagmanager, kan dit een snelle manier zijn om speculatieregels uit te rollen (en kunt u deze indien nodig ook snel uitschakelen).
Deze optie maakt ook dynamische regels aan de clientzijde mogelijk, gebaseerd op hoe de gebruiker met de pagina omgaat. Als de gebruiker bijvoorbeeld een artikel aan het winkelmandje toevoegt, kunt u de afrekenpagina vooraf weergeven. Als alternatief kan dit worden gebruikt om speculaties op gang te brengen op basis van bepaalde voorwaarden. Hoewel de API een gretigheidsinstelling bevat die basisregels voor interactie mogelijk maakt, stelt JavaScript ontwikkelaars in staat hun eigen logica te gebruiken om te beslissen wanneer en op welke pagina('s) ze speculeren.
Zoals eerder vermeld, is een alternatieve benadering voor het invoegen van nieuwe regels het plaatsen van een basisdocumentregel op de pagina en het activeren van JavaScript-documentregels door de juiste klassen aan links toe te voegen, waardoor ze overeenkomen met de regel.
Voeg speculatieregels toe met behulp van een HTTP-header
De laatste optie voor ontwikkelaars is om de regels op te nemen met behulp van een HTTP-header:
Speculation-Rules: "/speculationrules.json"
Er zijn enkele aanvullende vereisten met betrekking tot de manier waarop de regelsresource ( /speculationrules.json in dit voorbeeld) wordt geleverd en gebruikt.
Deze optie maakt eenvoudigere implementatie door CDN's mogelijk zonder dat de documentinhoud hoeft te worden gewijzigd. Het betekent wel dat het dynamisch wijzigen van de speculatieregels met behulp van JavaScript geen optie is. Documentregels met CSS-selectortriggers kunnen echter nog steeds dynamische wijzigingen toestaan, bijvoorbeeld door de prerender -klasse uit een link te verwijderen.
Net als bij de JavaScript-optie zorgt het implementeren van speculatieregels met een HTTP-header ervoor dat ze onafhankelijk van de inhoud van de site kunnen worden geïmplementeerd, waardoor het gemakkelijker kan worden om regels toe te voegen en te verwijderen zonder dat de site volledig opnieuw hoeft te worden opgebouwd.
Houd rekening met de kostenimplicaties
Voordat u speculatieregels implementeert, loont het de moeite om even de tijd te nemen om de kostenimplicaties voor zowel uw gebruikers als uw site met deze API te overwegen. De kosten omvatten bandbreedte (wat zowel gebruikers als sites geld kost!) en verwerkingskosten (zowel aan de client- als aan de serverzijde).
Houd rekening met de kosten voor gebruikers
Speculatief laden betekent een goede inschatting maken van waar een gebruiker naar een nieuwe pagina kan navigeren. Als die navigatie echter niet plaatsvindt, heeft u mogelijk middelen verspild. Daarom moet u zich bewust zijn van de impact op gebruikers, in het bijzonder:
- Er wordt extra bandbreedte gebruikt om die toekomstige navigatie te downloaden, vooral op mobiele apparaten, waar de bandbreedte mogelijk beperkter is.
- Extra verwerkingskosten om die pagina's weer te geven bij gebruik van prerender.
Met volledig nauwkeurige voorspellingen zijn er geen extra kosten, omdat bezoekers die pagina's vervolgens bezoeken, met als enige verschil dat deze kosten vooraf worden betaald. Het is echter onmogelijk om de toekomst met volledige nauwkeurigheid 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 een stuk lager zijn dan u misschien denkt . Met name door het hergebruiken van de HTTP-cache en het niet laden van cross-origin iframes zijn de kosten van het vooraf weergeven van een navigatie op dezelfde site vaak aanzienlijk kleiner dan die van een volledige pagina zonder in de cache opgeslagen bronnen, waardoor speculatieve ladingen minder duur zijn dan misschien wordt aangenomen.
Zelfs met deze waarborgen moeten sites echter zorgvuldig overwegen op welke pagina's te speculeren, en wat de gebruikerskosten van dergelijke speculaties zijn. Goede kandidaten voor speculatief laden zijn onder meer de pagina's die redelijkerwijs kunnen worden voorspeld met een hoge mate van vertrouwen (misschien op basis van analyses of algemene gebruikerstrajecten) en wanneer de kosten laag zijn (bijvoorbeeld minder rijke pagina's).
U kunt ook overwegen welke JavaScript moet worden uitgesteld tot de activering. Net als bij het lui laden van inhoud totdat deze nodig is, kan dit pre-renders goedkoper maken, maar een veel betere gebruikerservaring bieden. Met goedkopere speculaties voelt u zich misschien op uw gemak als u vaker of gretig speculeert.
Waar dit niet mogelijk is, wordt een minder agressieve strategie aanbevolen, waarbij gebruik wordt gemaakt van gematigde of conservatieve gretigheidsregels . Als alternatief kunt u prefetch gebruiken, wat aanzienlijk minder kosten heeft dan pre-rendering wanneer de betrouwbaarheid laag is, en vervolgens upgraden naar een volledige pre-render als de betrouwbaarheid groeit, bijvoorbeeld wanneer er op een link wordt gehangen of er daadwerkelijk op wordt geklikt.
Overweeg extra back-endbelasting
Naast de extra kosten voor de gebruiker moeten site-eigenaren ook rekening houden met hun eigen infrastructuurkosten. Als elke pagina resulteert in het laden van twee, drie of zelfs meer pagina's, kunnen de backend-kosten stijgen door deze API te gebruiken.
Door ervoor te zorgen dat uw pagina's en bronnen in het cachegeheugen kunnen worden opgeslagen, wordt de hoeveelheid oorspronkelijke belasting, en dus het algehele risico, aanzienlijk verminderd. In combinatie met een CDN zouden uw oorspronkelijke servers een minimale extra belasting moeten ondervinden, maar houd wel rekening met eventuele stijgingen van de CDN-kosten.
Een server of CDN kan ook worden gebruikt om de speculatieresultaten te controleren, zoals geïdentificeerd door de secundaire HTTP-header . Het Speed Brain-product van Cloudflare staat bijvoorbeeld alleen speculaties toe die al in de cache op de edge-server van een CDN zijn opgeslagen , en stuurt geen verzoeken terug naar de oorsprong.
Omdat speculatieve laadacties doorgaans echter worden gebruikt voor het laden van pagina's van dezelfde oorsprong, hebben gebruikers al gedeelde bronnen in de cache van hun browser (ervan uitgaande dat ze in de eerste plaats in de cache kunnen worden opgeslagen). Dus ook hier is een speculatie meestal niet zo duur als het laden van een volledige pagina.
Vind de balans tussen te veel of te weinig speculeren
De sleutel tot het optimaal benutten van de Speculation Rules API is het vinden van de balans tussen te veel speculeren (dat wil zeggen, wanneer de kosten onnodig worden betaald en de speculatie niet wordt gebruikt) en te conservatief (te weinig, of te laat, waarbij weinig voordeel wordt gerealiseerd).
Waar de kosten laag zijn (bijvoorbeeld kleine, statisch gegenereerde pagina's die in de cache op CDN-edge-nodes zijn opgeslagen), kunt u het zich veroorloven agressiever te zijn met speculaties.
Voor grotere, rijkere pagina's die misschien niet in de cache aan de CDN-rand kunnen worden opgeslagen, moet echter meer voorzichtigheid worden betracht. Op dezelfde manier kunnen resource-intensieve pagina's netwerkbandbreedte of verwerkingskracht verbruiken, wat een negatieve invloed kan hebben op de huidige pagina. Het doel van de API is om de prestaties te verbeteren, dus prestatieregressies zijn absoluut niet wat we willen! Dit is nog een reden om pre-renders tot maximaal één of twee pagina's te beperken (merk ook op dat Chrome slechts twee of tien pre-renders tegelijk beperkt, afhankelijk van de gretigheid).
Stappen om speculatieregels te implementeren
Als u eenmaal heeft besloten hoe u de speculatieregels gaat implementeren, moet u vervolgens plannen wat u gaat speculeren en hoe u dit gaat uitrollen. Eenvoudigere sites, zoals statische persoonlijke blogs, kunnen mogelijk direct overgaan naar de volledige pre-weergave van bepaalde pagina's, maar complexere sites hebben extra complexiteit waarmee rekening moet worden gehouden.
Begin met vooraf ophalen
Prefetch is meestal relatief veilig te implementeren voor de meeste sites en dit is de eerste aanpak die door velen wordt gevolgd, waaronder grootschalige implementaties zoals Cloudflare en WordPress .
De belangrijkste problemen waarmee u rekening moet houden, zijn dat het vooraf ophalen van een URL statuswijzigingen en kosten aan de serverzijde met zich meebrengt, vooral voor niet-cachebare pagina's. Idealiter zouden statuswijzigingen (bijvoorbeeld het vooraf ophalen van een /logout -pagina) niet als GET links moeten worden geïmplementeerd, maar helaas is dit niet ongewoon op internet.
Dergelijke URL's kunnen specifiek worden uitgesloten van de regels:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Prefetches kunnen worden beperkt tot algemene navigatie van de ene pagina naar de andere, of voor alle links van dezelfde oorsprong bij zweven of klikken met behulp van de moderate of conservative eagerness . De conservative setting brengt het laagste risico met zich mee, maar ook de laagste potentiële beloning. Als je daar begint, probeer dan op zijn minst door te gaan naar moderate , maar eager zal meer prestatievoordelen opleveren (en vervolgens verder upgraden naar prerender waar dit zinvol is).
Prerenders met een laag risico
Prefetch-speculaties zijn gemakkelijker te implementeren, maar het ultieme prestatievoordeel voor de API is prerender. Dit kan enkele extra overwegingen met zich meebrengen als de pagina niet kort na het speculeren wordt bezocht (wat we in de volgende sectie zullen bespreken), maar met een moderate of conservative pre-render, waarbij de navigatie waarschijnlijk kort daarna zal plaatsvinden, kan dit een relatief laag risico zijn als volgende stap.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Haal algemene pagina's vooraf op om niet-enthousiaste pre-renders te verbeteren
Een veelgebruikte tactiek is om bij het laden een kleiner aantal vaak bezochte volgende pagina's vooraf op te halen met een eager instelling (door ze op te geven in een URL-lijst of door selector_matches te gebruiken), en vervolgens vooraf te renderen met een moderate instelling. Omdat de HTML-prefetch waarschijnlijk voltooid zal zijn tegen de tijd dat de link in de hovermodus terechtkomt, geeft dit een boost ten opzichte van alleen pre-rendering bij hover zonder een prefetch.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Eerdere pre-renders
Hoewel moderate documentregels een gebruik van de API met een relatief laag risico en het daarbij behorende implementatiegemak mogelijk maken, is dit vaak niet genoeg tijd voor een volledige pre-rendering. Als u directe navigatie wilt realiseren die deze API mogelijk maakt, zult u waarschijnlijk verder moeten gaan en pagina's gretiger vooraf moeten renderen.
Dit wordt bereikt met een statische lijst met URL's (zoals het prefetch-voorbeeld eerder) of met selector_matches die een klein aantal URL's identificeren (idealiter één of twee pagina's), met documentregels die de andere URL's dekken:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Hiervoor kan een verkeersanalyse nodig zijn om de beste kans te bieden op een nauwkeurige voorspelling van de volgende navigatie. Als u de typische klanttrajecten op uw site begrijpt, kunt u ook goede kandidaten voor speculatief laden identificeren.
De overstap naar meer enthousiaste pre-rendering kan ook leiden tot meer overwegingen rond analyses, advertenties en JavaScript en de noodzaak om een vooraf gerenderde pagina up-to-date te houden , of zelfs om speculaties over statuswijzigingen te annuleren of te vernieuwen .
Analytics, advertenties en JavaScript
Bij het gebruik van prerender moeten complexere sites ook rekening houden met de impact op analyses. Normaal gesproken wilt u geen paginaweergave (of advertentieweergave) registreren wanneer er over de pagina wordt gespeculeerd, maar alleen wanneer de speculatie is geactiveerd.
Sommige analyseproviders (zoals Google Analytics) en advertentieproviders (zoals de Google-uitgeverstag) ondersteunen al speculatieregels en registreren pas weergaven nadat de pagina is geactiveerd. Andere aanbieders of aangepaste analyses die u heeft geïmplementeerd, hebben mogelijk echter extra aandacht nodig.
U kunt controles aan JavaScript toevoegen om de uitvoering van specifieke stukjes code te voorkomen totdat pagina's worden geactiveerd of zichtbaar worden gemaakt , en u kunt zelfs hele <script> -elementen in dergelijke controles verwerken . Wanneer pagina's tagmanagers gebruiken om dergelijke scripts te injecteren, is het misschien mogelijk om deze allemaal in één keer aan te pakken door het tagmanagerscript zelf uit te stellen.
Op dezelfde manier bieden toestemmingsmanagers een mogelijkheid om scripts van derden uit te stellen totdat ze worden geactiveerd. Google heeft met verschillende platforms voor toestemmingsbeheer samengewerkt om ze pre-render-bewust te maken. We helpen graag anderen die hetzelfde willen doen. PubTech is zo'n bedrijf dat ontwikkelaars de keuze biedt om JavaScript tijdens pre-rendering uit te voeren of te blokkeren .
Voor applicatiecode kunt u op dezelfde manier een wijziging toevoegen om de uitvoering van code uit te stellen tot activering, vooral wanneer de pagina geen JavaScript-code vereist om te worden weergegeven. Dit is een snellere en veiligere optie, maar betekent wel dat alle code bij activering in één keer wordt uitgevoerd. Dit kan resulteren in veel werk tijdens de activering, wat van invloed kan zijn op INP , vooral omdat de pagina er volledig geladen en klaar voor gebruik uit kan zien.
Als bovendien inhoud afhankelijk is van JavaScript (bijvoorbeeld weergegeven inhoud aan de clientzijde), zal het uitstellen hiervan de positieve impact op LCP en CLS verminderen die vooraf renderen met zich mee kan brengen. Een meer gerichte aanpak om meer JavaScript te laten draaien tijdens de pre-renderingfase zal resulteren in een betere ervaring, maar kan minder triviaal zijn om te implementeren.
Beginnen met het volledig uitstellen van veel scripttags kan in eerste instantie een goede strategie zijn voor complexere sites. Om echter de meeste voordelen uit de API te halen, zou het uiteindelijke doel moeten zijn om zoveel mogelijk JavaScript te laten draaien tijdens pre-rendering.
Sites die zich zorgen maken over analyses of advertenties willen misschien ook beginnen met prefetch , waar deze minder zorgwekkend zijn, terwijl ze overwegen wat er moet gebeuren om pre-rendering te ondersteunen.
Prerender-speculaties bijwerken
Bij het vooraf weergeven van pagina's voorafgaand aan navigatie bestaat het risico dat de vooraf weergegeven pagina verouderd raakt. Op een e-commercesite kan een vooraf weergegeven pagina bijvoorbeeld een betaalmandje bevatten: een volledig mandje met artikelen of zelfs alleen maar een teller die het aantal artikelen in het winkelmandje op andere pagina's weergeeft. Als er meer artikelen aan een winkelmandje worden toegevoegd en er vervolgens naar een vooraf weergegeven pagina wordt genavigeerd, zou het voor de gebruiker verwarrend zijn om de oude afrekenstatus te zien.
Dit is geen nieuw probleem en wanneer gebruikers meerdere tabbladen in de browser hebben geopend, ervaren ze hetzelfde probleem. Bij vooraf weergegeven pagina's is dit echter zowel waarschijnlijker als onverwachter, omdat de gebruiker de pre-weergave niet bewust heeft gestart.
De Broadcast Channel API is een manier om één pagina in de browser dit soort updates naar andere pagina's te laten uitzenden. Dit zou ook het probleem met meerdere tabbladen oplossen. Vooraf gegenereerde pagina's kunnen naar uitgezonden berichten luisteren, maar kunnen pas hun eigen uitgezonden berichten verzenden nadat ze zijn geactiveerd.
Als alternatief kunnen vooraf weergegeven pagina's updates krijgen via de server (met behulp van een periodieke fetch() of een WebSocket verbinding), maar met mogelijk vertragingen in de updates.
Pre-rendering-speculaties annuleren of vernieuwen
Het bijwerken van vooraf weergegeven pagina's is de aanbevolen aanpak om vooraf weergegeven pagina's te blijven gebruiken en tegelijkertijd verwarring bij gebruikers te voorkomen. Waar dit niet mogelijk is, is het mogelijk om speculaties te annuleren.
Dit kan ook worden gebruikt om binnen de limieten van Chrome te blijven als sites andere pagina's waarvan de kans groter is dat ze worden bezocht, vooraf willen weergeven.
Om speculaties te annuleren, moet u de speculatieregels van de pagina verwijderen, of klassen of andere overeenkomende criteria verwijderen als u deze aanpak gebruikt. Als alternatief kan de gespeculeerde pagina window.close() aanroepen als deze detecteert dat deze niet langer actueel is. Maar als de pagina dit kan detecteren, is het een betere optie om de status bij te werken om deze weer up-to-date te maken.
Het is ook mogelijk om deze regels (of overeenkomende criteria) opnieuw in te voegen, zodat pagina's opnieuw vooraf kunnen worden weergegeven (hoewel het up-to-date houden van een bestaande pagina meestal de betere optie is, omdat dit minder verspillend is). Nadat speculatieregels zijn verwijderd, moet het opnieuw invoegen worden voltooid in een nieuwe microtaak of later, zodat de browser de verwijderingen kan opmerken en de speculaties kan annuleren. Eén benadering voor het verwijderen en verwijderen van alle scripts voor speculatieregels wordt weergegeven in het volgende voorbeeld:
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 zal bestaande pretenders (of prefetches) annuleren, maar het opnieuw invoegen van de regels zal alleen speculeren over onmiddellijke of enthousiaste regels (inclusief regels voor URL-lijsten die de standaardwaarde van onmiddellijk gebruiken). Gematigde of conservatieve speculaties worden echter verwijderd, maar niet automatisch opnieuw geactiveerd totdat er opnieuw interactie met de link plaatsvindt.
Deze vernieuwingsoptie is niet beperkt tot regels die in JavaScript zijn ingevoegd. Statische regels die in de HTML zijn opgenomen, kunnen op dezelfde manier ook worden verwijderd of gewijzigd, aangezien dit een standaard DOM-wijziging is. HTTP-speculatieregels kunnen niet worden verwijderd, maar overeenkomende criteria (bijvoorbeeld prerender klassen) kunnen worden verwijderd en opnieuw worden toegevoegd door JavaScript.
Chrome overweegt ook om Clear-Site-Header-ondersteuning toe te voegen om serverreacties mogelijk te maken om pre-renders te annuleren (bijvoorbeeld wanneer er een updatemandverzoek wordt gedaan).
Meet de impact
Nadat u de speculatieregels heeft geïmplementeerd, moet u het succes meten en er niet alleen maar vanuit gaan dat het automatisch sneller gaat. Zoals eerder vermeld, kan overspeculatie daadwerkelijk prestatieverlies veroorzaken als de client of server overwerkt is.
Bij implementatie met meerdere stappen (prefetch, prerenders met een laag risico en vervolgens vroege prerenders) moet u bij elke stap meten.
Hoe succes te meten
Speculatieregels zouden een positieve impact moeten hebben op belangrijke prestatiestatistieken zoals LCP (en mogelijk ook op CLS en INP), maar deze zijn misschien niet duidelijk zichtbaar in algemene statistieken op locatieniveau. Dit komt omdat sites voornamelijk uit andere navigatietypen bestaan (bijvoorbeeld landingspagina's) of omdat navigatie van dezelfde oorsprong al snel genoeg is dat zelfs een dramatische verbetering ervan geen invloed heeft op de 75e percentielstatistieken, zoals gerapporteerd in het Chrome User Experience Report (CrUX) .
U kunt de paginanavigatietypen in Crux gebruiken om te controleren welk percentage van de navigatie navigate_cache of prerender is en of dat in de loop van de tijd toeneemt. Voor een gedetailleerde analyse moet u echter mogelijk Real User Monitoring gebruiken om uw gegevens te segmenteren in speculatieve navigaties om te zien hoeveel sneller deze zijn dan andere navigaties.
Hoe u gebruik en verspilling kunt meten
Een andere belangrijke overweging is om te meten of u op de juiste pagina's speculeert. Dit voorkomt verspilling en zorgt ervoor dat u de beste pagina's target die u met deze API kunt bereiken.
Helaas kan de pagina die de speculaties start niet direct de status van speculatiepogingen zien. Bovendien kan er niet van worden uitgegaan dat pogingen zijn geactiveerd, aangezien de browser onder bepaalde omstandigheden speculaties kan tegenhouden . Deze moeten dus op de pagina zelf worden gemeten. Hiervoor moeten ook twee API's worden gecontroleerd om te zien of de pagina speculeert 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 vervolgens de speculatiepoging naar backend-servers registreren.
Een complicatie bij analyses is dat providers (zoals Google Analytics) zich bewust zijn van pre-rendering en analyseaanroepen negeren totdat de pagina wordt geactiveerd, zelfs afzonderlijke gebeurtenisaanroepen. Daarom moeten Google Analytics-gebruikers een andere optie voor logboekregistratie op de server gebruiken.
Het is ook mogelijk om deze client-side te gebruiken, waarbij elke vooraf weergegeven pagina de vooraf weergegeven pagina in de gedeelde opslag registreert en de oproepende pagina dit leest. localStorage werkt het beste omdat het kan worden gelezen bij het verlaten van een pagina (merk op dat sessionStorage niet kan worden gebruikt omdat het een speciale behandeling heeft voor vooraf gegenereerde pagina's ). Houd er echter rekening mee dat localStorage niet transactieveilig is en dat andere pagina's dit tegelijkertijd kunnen bijwerken als meerdere pagina's vooraf worden weergegeven. Deze demo gebruikt een unieke hash en individuele vermeldingen om problemen hiermee te voorkomen.
Conclusie
Speculatieregels bieden de mogelijkheid om de prestaties van uw pagina dramatisch te verbeteren. Deze handleiding geeft advies over overwegingen bij het implementeren van deze API om mogelijke problemen te voorkomen en ook het maximale uit de API te halen.
Door de implementatie vooraf te plannen, wordt herwerk vermeden. Met name voor complexere sites moet dit worden gevolgd door een uitrol in meerdere stappen, beginnend met prefetch, voordat wordt overgegaan op pre-render met een laag risico en vervolgens vroege pre-render. Ten slotte is het belangrijk om de verbeteringen, en eventueel gebruik en verspilling, te meten om er zeker van te zijn dat u de API optimaal gebruikt.