Pagina's die direct laden met Speculation Rules
Leer hoe je de Core Web Vitals verbetert door pagina's direct te laten laden met de nieuwe Speculation Rules API
Verbeter direct de Core Web Vitals met de 'Speculation Rules API'
Heb je je ooit afgevraagd waarom sommige pagina's direct lijken te laden? Dat komt waarschijnlijk doordat die pagina Speculation Rules heeft geïmplementeerd!
De Speculation Rules API verhoogt de snelheid van toekomstige paginaladingen in multi-page applications (MPA's) door ze te `prefetch`-en of zelfs te `prerender`-en. Ontwikkelaars kunnen `speculation rules` configureren om de browser te adviseren documenten te `prefetch`-en of te `prerender`-en voor snellere (of directe) paginaladingen. `Speculation rules` vervangen oudere technieken zoals `<link rel="prefetch">` voor het `prefetch`-en van resources of de verouderde, Chrome-specifieke feature `<link rel="prerender">`.
`Speculation rules` werken op documentniveau, wat het geschikt maakt voor MPA's die volledige paginanavigaties gebruiken. Single-page applications (SPA's) die voornamelijk API-calls of gedeeltelijke content-updates gebruiken, profiteren minder van deze API voor hun interne route-wijzigingen. Echter, `Speculation Rules` kunnen SPA's alsnog helpen door de initiële staat van de applicatie vanaf een landingspagina te `prerender`-en, wat de initiële laadtijd kan compenseren.
Speculation rules QuickStart
Weet je al wat de `speculation rules` zijn? Geweldig! Hier zijn enkele kant-en-klare snippets waarmee je direct aan de slag kunt. Kies de juiste snippet voor jouw situatie en plaats deze in de <head> van je pagina (je kunt preload naar prefetch veranderen en/of de eagerness aanpassen)!
<!--
WordPress speculation rules door corewebvitals.io
prefetches alle interne links
slaat links over die overeenkomen met wp-login, wp-admin, wp content
slaat links over met het nofollow-attribuut
slaat links over met een query string zoals: /search?q=welcome
->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"and": [{ "href_matches": "\/*"},{ "not": { "href_matches": [ "\/wp-login.php", "\/wp-admin\/*", "\/*\\?*", "\/wp-content\/*", ] }
},{ "not": { "selector_matches": "a[rel~=\"nofollow\"]" }
}]
},
"eagerness": "moderate"
}]
}
</script> <!-- Door data-preload getriggerde speculation rules door corewebvitals.io -->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"selector_matches": "a[data-preload]"
},
"eagerness": "moderate"
}]
}
</script> Tip: als je snel je eigen `speculation rules` wilt bouwen, probeer dan de speculation rules generator
Voordelen van Speculation Rules
Verbeterde `user Experience` (UX): Door content te voorspellen en voor-te-laden, zorgen `Speculation Rules` voor bijna directe paginaladingen, waardoor navigatie voor gebruikers naadloos aanvoelt. Dit evenaart de prestaties van single-page applications, zelfs voor traditionele multi-page websites, zonder de complexiteit en afhankelijkheid van `JavaScript`. Snellere laadtijden betekenen een betere browse-ervaring, wat waarschijnlijk de gebruikersbetrokkenheid verhoogt en bounce rates verlaagt.
`SEO`-voordelen: Omdat een verbeterde paginasnelheid een directe rankingfactor is en een betere `Time to First Byte` resulteert in een betere `Largest Contentful Paint`, zal het implementeren van `speculation rules` de `Core Web Vitals` gegarandeerd verbeteren en je die pagespeed-bonus opleveren.
Verminderde complexiteit: Bijna directe paginaladingen waren voorheen mogelijk door een SPA te gebruiken of door aangepaste `prefetch`-logica voor MPA's te schrijven.
Voor veel use cases is het nadeel van een SPA de initiële opstarttijd, die aanzienlijk kan zijn omdat ze sterk afhankelijk zijn van `JavaScript` en de complexiteit hoger is in vergelijking met een MPA. `Speculation rules` hebben deze problemen niet. Dit maakt snel laden haalbaar voor een breder scala aan websites, met name content-gerichte.
De API vereenvoudigt ook het proces van het beslissen welke pagina's te `prerender`-en door een groot deel van de logica aan de browser te delegeren. Dit is een enorme verbetering ten opzichte van eerdere methoden die afhankelijk waren van `JavaScript` om deze controles uit te voeren en pagina's te injecteren voor het voorladen. Browsers kunnen native rekening houden met de context van de gebruiker, zoals weinig geheugen op mobiele apparaten of de batterijbesparingsmodus, bij de beslissing om te `prerender`-en. Deze dynamische aanpassing helpt gebruikersresources te besparen en zorgt voor een soepelere ervaring, zelfs onder beperkingen.
Andere voordelen: De `Speculation-Rules` HTTP-header maakt een eenvoudigere implementatie via Content Delivery Networks (CDN's) mogelijk, waardoor het niet nodig is de documentinhoud direct aan te passen. Granulaire controle met 'Document Rules' stelt ontwikkelaars in staat om precieze voorwaarden te definiëren voor `prefetching` of `prerendering` op basis van URL-patronen of CSS-selectors. Dit vermindert handmatige URL-specificatie en maakt site-brede `speculation rulesets` mogelijk. De 'eagerness'-instelling biedt fijnmazige controle over wanneer speculatie plaatsvindt, waardoor de snelheid van het voorladen wordt afgewogen tegen het resourceverbruik. Dit helpt onnodig voorladen te verminderen en resourceverspilling te voorkomen.
Mechanismen van Speculation Rules
`Speculation rules` worden gedefinieerd met een JSON-structuur en kunnen op twee manieren worden geïmplementeerd:
- Inline Script: Voeg de JSON toe binnen een `<script type="speculationrules">`-tag, hetzij in de `<head>` of `<body>` van het hoofd-HTML-document.
- HTTP Header: Lever de `rules` aan via de `Speculation-Rules` HTTP-header in de `response` van het document. Deze header verwijst naar een JSON-bestand met de `rules`, wat een eenvoudigere CDN-implementatie mogelijk maakt zonder de HTML-content direct te hoeven aanpassen.
De JSON-structuur gebruikt '`prefetch`'- en '`prerender`'-arrays om `rules` voor elk speculatief laadtype te bevatten. Elke `rule` kan verschillende bronnen gebruiken: een lijst met `urls` of `document rules`.
- `urls` (een lijst met urls) Een array van URL's om te `prefetch`-en of te `prerender`-en.
- `where` (document rules) Een object dat voorwaarden gebruikt om te bepalen welke links op de pagina moeten worden `ge-prefetch-ed` of `ge-prerender-ed`.
Elke `rule` wordt gedefinieerd als een object dat eigenschappen bevat zoals:
- `requires` Een array van strings om beperkingen voor speculaties in te stellen. Momenteel is de enige geldige string 'anonymous-client-ip-when-cross-origin', wat aangeeft dat een cross-origin `prefetch` het IP-adres van de client moet anonimiseren.
- `target_hint` Een string die een hint geeft over de naam van het navigeerbare doel, waardoor de user agent het laadproces kan optimaliseren. Het heeft geen normatieve implicaties buiten het feit dat het een hint is.
- `referrer_policy` Een `referrer policy` die moet worden toegepast op `ge-prefetch-te` of `ge-prerender-de` URL's.
- `relative_to` (Alleen voor 'list' bron) Specificeert of de URL's in de '`urls`'-array relatief zijn aan de basis-URL van het document ('document') of de locatie van het `speculation rules` JSON-bestand ('ruleset').
- `eagerness` Bepaalt hoe agressief de browser moet `prefetch`-en of `prerender`-en. De beschikbare instellingen zijn 'immediate', 'eager', 'moderate', en 'conservative', elk met verschillende triggers.
- `expects_no_vary_search` Een string die wordt gebruikt als hint voor de variantie van de URL-zoekopdracht, waardoor ontwikkelaars kunnen aangeven of de gespeculeerde URL naar verwachting een andere `response` zal hebben op basis van de zoekparameters.
Ten slotte heeft elke `rule` een `eagerness`-instelling waarmee je kunt bepalen wanneer speculaties moeten worden uitgevoerd, waardoor het 'wanneer' van het speculeren wordt gescheiden van 'welke' URL's er moeten worden gespeculeerd. De `eagerness`-instelling is beschikbaar voor zowel `list`- als `document`-source `rules` en heeft vier instellingen: `immediate`, `eager`, `moderate` en `conservative`.
- `immediate`: Wordt gebruikt om zo snel mogelijk te speculeren, zodra de `speculation rules` worden waargenomen.
- `eager`: Gedraagt zich momenteel identiek aan de `immediate`-instelling, maar zal in de toekomst ergens tussen `immediate` en `moderate` worden geplaatst.
- `moderate`: Voert speculaties uit als je 200 milliseconden over een link zweeft (of bij de `pointerdown`-event als dat eerder is, en op mobiel waar geen hover-event is).
- `conservative`: Speculeert bij `pointer` of `touch down`.
Prefetch of Prerender
De Speculation Rules API ondersteunt twee primaire vormen van speculatief laden: `prefetching` en `prerendering`. Hoewel beide technieken kunnen resulteren in snellere paginaladingen, verschillen ze in complexiteit en resourceverbruik.
- `Prefetching` is de 'lichtere vorm' van speculatief laden. Het downloadt en cachet de `HTML` van de doel-URL zonder de pagina of de subresources te renderen. Deze aanpak verbetert voornamelijk de `Time To First Byte`. Een verbeterde `Time to First Byte` leidt tot betere `paint`-metrics zoals de `Largest Contentful Paint` en `First Contentful Paint`.
- `Prerendering` doet veel meer dan alleen de `HTML` downloaden. Het downloadt de `HTML`, alle subresources en rendert de volledige pagina in een verborgen, onzichtbare tab. Bij navigatie naar deze pagina resulteert dit in een bijna onmiddellijke weergave. Deze techniek verbetert de `Largest Contentful Paint` op meer manieren dan alleen door het verbeteren van de `Time to First Byte`; het downloadt en rendert ook het `LCP`-element. `Prerendering` kan ook de `Cumulative Layout Shift` elimineren omdat de afmetingen van resources al bekend zijn na het `prerendering`-proces.
Dus wat is beter? `Prerendering` of `Prefetching`? Dat hangt af van de pagina en de 'gemiddelde bezoeker'. Hoewel `prerendering` sneller kan zijn, gebruikt het van nature ook veel meer resources, zowel aan de client- als aan de serverkant. De keuze voor `prerendering` of `prefetching` hangt af van:
- De apparaatcapaciteiten van de gebruiker: `Prerendering` is misschien niet de beste keuze als een hoog percentage bezoekers op apparaten met beperkt geheugen zit.
- Specificiteit van de `prerender`- of `prefetch`-regel. 'Sommige links worden waarschijnlijker aangeklikt en sommige pagina's hebben een hogere kans op conversie'. Die pagina's zijn perfecte kandidaten voor een `prerender`-regel. Andere pagina's zijn wellicht geschikter voor `prefetch`.
CoreWebVitals.io waarschuwt voor overmatig `prerendering` vanwege de resource-eisen, met name op mobiele apparaten of langzamere verbindingen. De potentiële voordelen van `prerendering` moeten worden afgewogen tegen het risico van prestatievermindering en resourceverspilling.
De juiste 'Eagerness' instellen - de balans vinden
Welke `eagerness`-instelling je moet gebruiken, hangt af van je site. Voor een zeer eenvoudige, statische site kan agressiever speculeren weinig kosten en voordelig zijn voor gebruikers. Sites met complexere architecturen en zwaardere `page payloads` geven er misschien de voorkeur aan om verspilling te verminderen door minder vaak te speculeren, totdat je een positiever signaal van gebruikersintentie krijgt om verspilling te beperken.
De `eagerness`-instelling in de Speculation Rules API beïnvloedt wanneer een browser content moet `prefetch`-en of `prerender`-en op basis van voorspelde gebruikersnavigatie. Deze instelling biedt een afweging tussen het maximaliseren van de voordelen van voorladen en het minimaliseren van resourceverspilling.
De standaard `eagerness` voor `list rules` is `immediate`. De `moderate`- en `conservative`-opties kunnen worden gebruikt om `list rules` te beperken tot URL's waarmee een gebruiker interactie heeft binnen een specifieke lijst. In veel gevallen kunnen `document rules` met een geschikte `where`-voorwaarde geschikter zijn.
De standaard `eagerness` voor `document rules` is `conservative`. Aangezien een document uit veel URL's kan bestaan, moet het gebruik van `immediate` of `eager` voor `document rules` met voorzichtigheid worden toegepast.
De keuze van `eagerness` hangt af van de structuur van de website, de gedragspatronen van de gebruiker en de inschatting van de ontwikkelaar van het potentiële resourceverbruik versus de voordelen voor de `user experience`. Een eenvoudige, statische site kan bijvoorbeeld profiteren van een '`eager`'-instelling, wat leidt tot snellere laadtijden. Omgekeerd kunnen websites met complexe architecturen en veeleisende `page payloads` kiezen voor een minder agressieve '`moderate`'- of '`conservative`'-aanpak om het resourcegebruik te beperken totdat er een duidelijkere gebruikersintentie wordt gedetecteerd.
Bij het configureren van `eagerness` moeten ontwikkelaars rekening houden met de `user experience`, resourcekosten en browserbeperkingen. Over-speculatie kan de bandbreedte, het geheugen en de CPU van de gebruiker belasten, wat de prestaties kan verminderen, vooral op beperkte netwerken of apparaten. Chrome legt limieten op voor het aantal gelijktijdige `ge-prefetch-te` en `ge-prerender-de` pagina's om overmatig gebruik te beperken. Bovendien kunnen factoren zoals door de gebruiker geconfigureerde Data Saver-modi, een lage batterijstatus of browserextensies de `speculation rules` overschrijven, waarbij resourcebehoud voorrang krijgt.
Controleer en debug `speculation rules`
Om te controleren of er `speculation rules` op een pagina zijn, open je Chrome DevTools, ga je naar het Application-paneel en navigeer je naar Background Services > Speculative Loads > Speculations. (open het Speculations-venster voordat je de pagina laadt die je wilt debuggen) Dit paneel geeft informatie over:
- Het aantal succesvolle speculaties.
- Individuele URL's die worden `ge-prerender-ed` of `ge-prefetch-ed`.
- De status van elke speculatie.
De Network-track in het Performance-paneel toont de netwerkactiviteit met betrekking tot `ge-prerender-de` resources zonder dat je de DevTools-context hoeft te wisselen. Daarnaast kun je de DevTools-context overschakelen naar een `ge-prerender-de` pagina om deze te inspecteren als een normale pagina.
Monitoren en analyseren van Speculation Rules
- `Real User Monitoring` (RUM): Gebruik RUM-tools om de daadwerkelijke `user experience` te meten. Observeer metrics zoals de `Largest Contentful Paint` (`LCP`) om de impact van `speculation rules` op paginalaadtijden te beoordelen. Zoek naar verbeteringen in de `LCP` voor `ge-prerender-de` pagina's in vergelijking met niet-`ge-prerender-de` pagina's.
- A/B Testing: Voer A/B-tests uit om verschillende configuraties van `speculation rules` te vergelijken en de meest optimale opzet voor jouw specifieke website en gebruikers te identificeren.
Overwegingen - de nadelen
Resourceverbruik: Overmatig gebruik van speculatie kan een negatieve impact hebben op bandbreedte-, geheugen- en CPU-gebruik.
Browsercompatibiliteit: Niet alle browsers ondersteunen de Speculation Rules API volledig, dus controleer de browsercompatibiliteit vóór de implementatie.
Privacy: Ontwikkelaars moeten zich ervan bewust zijn hoe `speculation rules` surfpatronen van gebruikers kunnen onthullen en passende privacymaatregelen implementeren.
De Speculation Rules API biedt een krachtige aanpak om de prestaties en `user experience` van webapplicaties te verbeteren. Door de werking, voordelen en overwegingen te begrijpen, kunnen ontwikkelaars deze API inzetten om snellere en boeiendere websites te bouwen.
Speculation Rules WordPress Code
Het WordPress Core Performance-team heeft een Speculation Rules-plugin gemaakt die met één klik ondersteuning voor `document rules` toevoegt aan elke WordPress-site. De plugin biedt twee groepen instellingen:
- `Speculation Mode`: Kies tussen `prefetch` en `prerender`. `Prerendering` zal resulteren in snellere laadtijden dan `prefetching`. Echter, `prefetching` kan een veiligere keuze zijn voor interactieve content.
- `Eagerness`: Kies tussen `conservative` (meestal bij een klik), `moderate` (meestal bij hover), of `eager` (bij de geringste aanwijzing). De `eagerness`-instelling bepaalt hoe snel speculatieve laadacties worden getriggerd.
