Tegenwoordig staan webpagina’s vol met afbeeldingen, video’s en interactieve elementen die de gebruikerservaring moeten verbeteren. Deze elementen kunnen echter de laadtijd van je pagina vertragen.
Naarmate de technologie voortschrijdt, blijft één doel constant: prestaties. Iedereen hoopt dat zijn webpagina’s razendsnel laden.
Eén manier om webpagina’s sneller te laten laden is door ze te prerenderen of prefetchen voordat een gebruiker er naartoe navigeert.
Een korte geschiedenis van prerendering
In 2011 introduceerde het Chromium team een vroege vorm van prerendering in de Chrome browser via de <link rel="prerender" … > tag.
Hiermee konden ontwikkelaars de browsers laten doorschemeren welke pagina(‘s) een gebruiker als volgende zou kunnen bezoeken. De browser zou deze pagina’s dan stilletjes op de achtergrond ophalen en renderen, waardoor de laadtijd drastisch werd verkort wanneer de gebruiker naar deze pagina’s navigeerde.
Ondanks de voordelen gebruikte deze vroege implementatie van prerendering veel bandbreedte en CPU resources en kon het tot privacyproblemen leiden als de gebruiker de vooraf gerenderde pagina’s niet bezocht. Bovendien moest je handmatig selecteren welke links je wilde prerenderen, wat niet altijd effectief of haalbaar was.
Om een aantal van deze problemen aan te pakken, heeft Chrome het prerenderen met behulp van de link rel=prerender hint afgeschaft ten gunste van de NoState Prefetch methode, waarbij bronnen binnen een pagina worden opgehaald zonder JavaScript of andere mogelijk privacyschendende acties uit te voeren.
De NoState Prefetch methode verbeterde het laden van bronnen, maar kon geen onmiddellijke paginalading leveren zoals een volledige prerender.
Introductie van de Speculation Rules API
De Speculation Rules API is een nieuwe experimentele in JSON gedefinieerde API die URL’s speculatief prerendert voordat er naartoe wordt genavigeerd, wat leidt tot snellere renderingstijden en verbeterde gebruikerservaringen.
Met de API kunnen developers regels configureren met een in JSON format gedefinieerde structuur binnen een script type="speculationrules" die de browser kan gebruiken om te beslissen welke URL’s vooraf moeten worden geladen.
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["firstpage.html", "secondpage.html"]
}
]
}
</script>Hetzelfde geldt voor prefetching, wat vaak een goede eerste stap kan zijn op weg naar prerendering:
<script type="speculationrules">
{
"prefetch": [
{
"urls": ["firstpage.html", "secondpage.html"]
}
]
}
</script>De bovenstaande codefragmenten laten zien hoe de Speculation Rules API werkte door een lijst met URL’s op te geven om te prefetchen of te prerenderen.
Onlangs kondigde Google nieuwe verbeteringen aan voor de Speculation Rules API, die nu de optie biedt voor het automatisch vinden van links met behulp van documentregels. Dit werkt door URL’s uit het document te halen op basis van een where voorwaarde.
<script type="speculationrules">
{
"prerender": [
{
"source": "document",
"where": {
"and": [
{
"href_matches": "/*"
},
{
"not": {
"href_matches": [
"/wp-login.php",
"/wp-admin/*"
]
}
}
]
},
"eagerness": "moderate"
}
]
}
</script>In dit codefragment worden alle URL’s op de pagina in aanmerking genomen voor prerendering, behalve de URL’s die leiden naar de WordPress inlog– en beheerpagina’s. Je specificeert ook een niveau van eagerness – eager (meteen), moderate (bij een hover van 200 ms) en conservative (bij muis of aanraking).
CSS selectors kunnen ook worden gebruikt als alternatief of in combinatie met href overeenkomsten om links op de huidige pagina te vinden:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "selector_matches": ".prerender" },
{ "not": {"selector_matches": ".do-not-prerender"}}
]
},
"eagerness": "moderate"
}]
}
</script>Wanneer je de Speculation Rules API gebruikt, kun je deze inspecteren met behulp van de Speculative Loading background services in het Chrome Application dashboard wanneer je de pagina inspecteert.
Er is nog meer – we zullen dit onderzoeken in de sectie over troubleshooting.
Browser ondersteuning
De Speculation Rules API wordt ondersteund in moderne op Chromium gebaseerde browsers, waaronder Chrome en Edge, vanaf specifieke versies.
Dit zorgt ervoor dat gebruikers op ondersteunde browsers kunnen profiteren van snellere laadtijden, terwijl gebruikers op andere browsers geen negatieve effecten ondervinden, omdat de API een progressieve verbeteringstool is.
De Speculative Loading WordPress plugin
Om te kunnen profiteren van de voordelen van de Speculation Rules API in WordPress, heeft het WordPress performance team (met daarin devs van Google) onlangs de Speculative Loading plugin gepubliceerd. Deze plugin maakt speculative loading van frontend URL’s die gekoppeld zijn op de pagina.
Tot nu toe is de plugin weinig gebruikt omdat de API zich nog in de beginfase bevindt, maar hij heeft wel positieve recensies gekregen.
Standaard is de plugin geconfigureerd om WordPress frontend URL’s te prerenderen wanneer de gebruiker met de muisaanwijzer over een relevante link gaat. Dit kan worden aangepast via de Speculative Loading sectie onder Settings > Reading.
Dit betekent dat alle URL’s waarnaar op de pagina wordt gelinkt, worden voorgeladen met een eagerness configuratie van moderate, die meestal wordt geactiveerd wanneer je met de muis over een link beweegt. Je hoeft dus niets te doen na het activeren van de plugin; het werkt gewoon out of the box.
Als je de Speculative Loading plugin bijvoorbeeld al hebt geïnstalleerd op een WordPress site, gebruik dan de Chrome DevTools om de site te inspecteren en klik op het tabblad Elements. Als je naar beneden scrollt, zie je dat er al een script type="speculationrules" voor je is toegevoegd met de verschillende speculative rules.
Het gebruikt een Regex om links te specificeren die moeten worden geprerendered, specificeert links die niet moeten worden geprerendered en stelt de gretigheid in. De volgende secties leggen deze regels in detail uit.
Limieten om overmatig gebruik te voorkomen
Chrome heeft limieten ingesteld om overmatig gebruik van de API te voorkomen:
| Eagerness | Prefecth | Prerender |
| immediate/eager | 50 | 10 |
| moderate/conservative | 2 (FIFO) | 2 (FIFO) |
Ze voorkomen overmatig gebruik door middel van verschillende instellingen op basis van urgentie en interactie met de gebruiker.
immediateeneager– Ze zijn niet afhankelijk van gebruikersacties en hebben dus hogere limieten. Ze maken dynamische capaciteitsaanpassingen mogelijk door oudere speculaties te verwijderen.moderateenconservative– Deze instellingen worden daarentegen door de gebruiker getriggerd en houden zich aan het First In, First Out (FIFO) principe met een bovengrens van 2, waarbij de oudste speculaties worden vervangen door nieuwe om geheugen te sparen.
Voorkomen dat bepaalde URL’s worden geprefetcht en geprerenderd
Het is belangrijk om op te merken dat WP-admin routes standaard zijn uitgesloten van prerendering en prefetching. Als WordPress ontwikkelaar is het aan jou om te bepalen welke routes je prioriteit wilt geven.
Je kunt de regels voor welke soorten URL’s gebruik maken van speculative loading aanpassen met het plsr_speculation_rules_href_exclude_paths filter.
Het volgende codevoorbeeld zorgt ervoor dat URL’s zoals https://wordpresssite.com/cart/ of https://wordpresssite.com/cart/book/ worden uitgesloten van prefetchen en prerenderen:
<?php
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function ( $exclude_paths ) {
$exclude_paths[] = '/cart/*';
return $exclude_paths;
}
);Soms wil je een URL uitsluiten van prerendering en toestaan dat deze wordt geprefetched. Bijvoorbeeld, een pagina met client-side JavaScript om de gebruikersstatus bij te werken zou waarschijnlijk niet geprerendered moeten worden, maar het zou redelijk zijn om te prefetchen.
Voor dit doel ontvangt het plsr_speculation_rules_href_exclude_paths filter de huidige modus ( prefetch of prerender) om voorwaardelijke uitsluitingen te bieden.
Laten we er bijvoorbeeld voor zorgen dat URL’s zoals https://wordpresssite.com/products/ niet geprerendered kunnen worden, terwijl ze wel geprefetched mogen worden.
<?php
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function ( array $exclude_paths, string $mode ): array {
if ( 'prerender' === $mode ) {
$exclude_paths[] = '/products/*';
}
return $exclude_paths;
}
);Het debuggen van speculation rules voor WordPress sites
Het debuggen van speculation rules kan lastig zijn omdat geprerenderde pagina’s in een aparte renderer worden weergegeven, zoals een verborgen achtergrondtabblad dat het huidige tabblad vervangt wanneer het wordt geactiveerd. Het Chrome team heeft veel werk verricht met de DevTools, waardoor je hiermee kunt debuggen.
Navigeer in Chrome DevTools naar het tabblad Application en scroll vervolgens naar beneden naar het tabblad Speculative loads. Dit geeft ontwikkelaars details over Speculatie, de vooraf gerenderde URL’s, de URL’s die mislukken en nog veel meer.
Hier zie je dat vijf links op de pagina kunnen worden geprerendered op basis van de URL’s die voldoen aan de regels die zijn ingesteld in de Speculative rules JSON, zoals hieronder te zien is. Merk op dat je niet alle URL’s hoeft op te sommen; de documentregels zorgen ervoor dat de browser deze oppikt van dezelfde origin links op de pagina.
De “Status” van sommige links wordt weergegeven als “Not triggered” – het prerenderproces voor deze links is nog niet gestart. Als we echter met de muis over de links op de pagina gaan, zien we de status veranderen naarmate elke URL wordt geprerendered.
Onthoud dat Chrome grenzen heeft gesteld aan prerenders, waaronder een maximum van twee prerenders voor moderate eagerness, dus nadat we met de muis over de derde link zijn gegaan, zien we de reden waarom die URL een fout heeft:
Het is ook mogelijk om de renderer die door de DevTools panels wordt gebruikt te wisselen met het vervolgkeuzemenu rechtsboven of door een URL te selecteren in het bovenste deel van het paneel en Inspect te selecteren:
Deze vervolgkeuzelijst (en de geselecteerde waarde) wordt gedeeld door alle andere panelen, zoals het Network panel, waar je kunt zien dat de pagina die wordt opgevraagd de geprerenderde pagina is:
Of het paneel Elements, waar je de inhoud van de pagina kunt zien:
Net zoals je geprerenderde pagina’s kunt debuggen, kun je ook pagina’s prefetchen. Voor de plugin “Speculative Loading” moet je Prefetch selecteren als Speculation Mode.
Wanneer je nu de pagina inspecteert met DevTools en naar het tabblad Speculative loads navigeert, zal de actie Prefetch zijn voor de verschillende URL’s en zullen de regels ook veranderen.
Als je naar het tabblad Network navigeert nadat je met de muis over een link bent gegaan, worden de geprefetchte bronnen als laatste weergegeven, zoals te zien is aan de kolom Type. Deze worden met de laagste prioriteit opgehaald, omdat ze voor toekomstige navigaties zijn en Chrome prioriteit geeft aan de bronnen van de huidige pagina.
Prestatievergelijking
Tot zover begrijp je wat de “Speculative Loading” plugin doet en hoe het werkt. Genoeg theorie; laten we de prestaties van twee identieke sites op dezelfde server (Kinsta’s WordPress Hosting) vergelijken.
Om dit te doen, heb ik twee WordPress sites gemaakt met het MyKinsta dashboard op hetzelfde datacenter (Iowa (US Central), dat wordt versterkt met behulp van Google’s C3D VM’s) en zonder enige andere plugin te installeren voor beide sites.
“Bare-site” is zonder de plugin, terwijl voor “Speculative-site” de “Speculative Loading” plugin is geïnstalleerd en geactiveerd op het WordPress dashboard.
Het is belangrijk om te weten dat de Speculative Rules API alleen de tijd verbetert die nodig is om de volgende pagina te laden waarop je gaat navigeren – je kunt dit niet beoordelen op basis van algemene tools voor websiteprestaties zoals Lighthouse.
We zouden de paginasnelheid testen door een pagina te laden vanaf een specifieke interne link op de twee websites en het Chrome DevTool’s Network tabblad te gebruiken wanneer je de site inspecteert om de laadtijd en andere informatie te bekijken.
Bij de “Bare-site” merk je dat het laden langer duurt omdat het hele laadproces as-you-go plaatsvindt en de DOM content achteraf wordt geladen:
Maar bij “Speculative-site” is de DOM inhoud al geladen via de Speculative API en in de cache geplaatst.
Het verschil tussen beide sites lijkt misschien erg klein. In dit geval is het verschil ongeveer 0,22 s, maar voor een grote site met meer inhoud begin je een significant verschil te zien.
Invloed van Speculation Rules API op analytics
Analytics is essentieel voor het bijhouden van websitegebruik via paginaweergaven en gebeurtenissen en het beoordelen van prestaties via Real User Monitoring (RUM). Het is belangrijk om te weten dat prerendering analytics kan beïnvloeden.
Als je bijvoorbeeld de Speculation Rules API gebruikt, kan het nodig zijn om extra code te gebruiken om analytics alleen te activeren als de vooraf gerenderde pagina’s daadwerkelijk worden geopend. Hoewel Google Analytics, Google Publisher Tag (GPT) en Google AdSense tracking uitstellen totdat een pagina actief is, doen niet alle aanbieders dit standaard.
Om hiermee om te gaan, kan een promise worden ingesteld om analytics alleen te initialiseren als de pagina wordt geactiveerd:
// Promise to activate analytics on page activation for prerendered pages
const whenActivated = new Promise((resolve) => {
if (document.prerendering) {
document.addEventListener('prerenderingchange', resolve);
} else {
resolve();
}
});
async function initAnalytics() {
await whenActivated;
// Initialize analytics
}
initAnalytics();Samenvatting
Dit artikel legde uit wat de Speculative Rules API is, hoe het werkt en hoe je het kunt gebruiken op een WordPress site. Het is een experimentele functie, maar wordt geleidelijk aan steeds meer gebruikt.
De speculation regels zijn dan ook nog steeds beperkt tot pagina’s binnen hetzelfde tabblad, maar er wordt aan gewerkt om deze beperkingen te verminderen.
Het is ook belangrijk om te weten dat een aanzienlijk deel van de prestaties van je site afhangt van de kwaliteit van je hosting. Bij Kinsta staan we bekend om het leveren van eersteklas WordPress Hosting met tientallen fantastische features.
Onze infrastructuur is volledig gecontaineriseerd en wordt uitsluitend aangedreven door het Google Cloud Platform op het Premium Tier netwerk van Google, waardoor we je kunnen voorzien van een grote selectie van de snelste dataservers, ongelooflijke prestaties, caching op serverniveau, dedicated resources en verbeterde beveiliging.
Lees wat onze klanten zeggen of neem contact met ons op voor meer informatie over onze managed hosting oplossing en hoe deze uitblinkt.
Wat zijn jouw gedachten over de Speculative Rules API en de introductie ervan in WordPress? Deel het hieronder in de reacties!
Laat een reactie achter