Verbeteringen aan de Speculatieregels-API

Barry Pollard

Het Chrome-team heeft gewerkt aan een aantal opwindende updates voor de Speculation Rules API die wordt gebruikt om de navigatieprestaties te verbeteren door toekomstige navigatie vooraf op te halen of zelfs vooraf weer te geven. Deze aanvullende verbeteringen zijn nu allemaal beschikbaar vanaf Chrome 122 (enkele functies zijn beschikbaar in eerdere versies).

Deze wijzigingen maken het prefetchen en vooraf renderen van pagina's aanzienlijk eenvoudiger te implementeren en minder verspillend, wat naar we hopen verdere adoptie zal bevorderen.

Extra functies

Als eerste volgt een uitleg van de nieuwe toevoegingen die we hebben toegevoegd aan de Speculation Rules API en hoe u deze kunt gebruiken. Hierna laten we u een demo zien, zodat u ze in actie kunt zien.

Documentregels

Voorheen werkte de Speculation Rules API door een lijst met URL's op te geven die vooraf moesten worden opgehaald of vooraf weergegeven:

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

De speculatieregels waren semi-dynamisch in die zin dat nieuwe scripts voor speculatieregels konden worden toegevoegd en oude scripts konden worden verwijderd om die speculaties te verwijderen (merk op dat het bijwerken van de urls lijst van een bestaand script voor speculatieregels geen verandering in speculaties teweegbrengt). De keuze van de URL's werd echter nog steeds aan de site overgelaten, hetzij door ze vanaf de server te verzenden op het moment dat de pagina werd aangevraagd, hetzij door deze lijst dynamisch te maken via JavaScript aan de clientzijde.

Lijstregels blijven een optie voor eenvoudiger gebruiksscenario's (waarbij de volgende navigatie afkomstig is uit een klein aantal voor de hand liggende), of meer geavanceerde gebruiksscenario's (waarbij de lijst met URL's dynamisch wordt berekend op basis van de heuristieken die de site-eigenaar wil gebruiken, en vervolgens ingevoegd in de pagina).

Als alternatief bieden we graag een nieuwe optie aan voor het automatisch zoeken naar links met behulp van documentregels . Dit werkt door URL's uit het document zelf te halen op basis van een where voorwaarde. Dit kan gebaseerd zijn op de links zelf:

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

CSS-selectors kunnen ook worden gebruikt als alternatief, of in combinatie met href-matches, 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>

Hierdoor kan één enkele speculatieregelset voor de hele site worden gebruikt, in plaats van specifieke regels per pagina, waardoor het voor sites veel gemakkelijker wordt om speculatieregels in te voeren.

Natuurlijk zou het vooraf weergeven van alle links op een pagina zeker verspilling zijn, dus met deze nieuwe mogelijkheid hebben we een eagerness geïntroduceerd.

Gretigheid

Bij elke vorm van speculatie is er een afweging tussen precisie en terugroepactie , en doorlooptijd. Het vooraf renderen van alle links bij het laden van de pagina betekent dat u vrijwel zeker een link prerendeert waarop een gebruiker klikt (ervan uitgaande dat hij op een link van dezelfde site op de pagina klikt), en met zo veel mogelijk doorlooptijd, maar met een potentieel enorme verspilling van bandbreedte .

Aan de andere kant voorkomt het vooraf renderen zodra een gebruiker op een link heeft geklikt verspilling, maar dit gaat ten koste van een veel kortere doorlooptijd. Dit betekent dat het onwaarschijnlijk is dat de pre-rendering is voltooid voordat de browser naar die pagina overschakelt.

Met de eagerness kunt u definiëren wanneer speculaties moeten plaatsvinden, waarbij u kunt scheiden wanneer u moet speculeren vanaf welke URL's u speculaties wilt uitvoeren. De instelling eagerness is beschikbaar voor zowel list als document en heeft vier instellingen, waarvoor Chrome de volgende heuristieken heeft:

• immediate : Dit wordt gebruikt om zo snel mogelijk te speculeren, dat wil zeggen zodra de speculatieregels in acht worden genomen.
• eager : Dit gedraagt ​​zich momenteel identiek aan de immediate omgeving, maar in de toekomst willen we dit ergens tussen immediate en moderate plaatsen.
• moderate : dit voert speculaties uit als u 200 milliseconden boven een link zweeft (of bij de pointerdown -gebeurtenis als dat eerder is, en op mobiel waar er geen hover -gebeurtenis is).
• conservative : dit speculeert op de aanwijzer of de landing.

De standaard eagerness voor list is immediate . De moderate en conservative opties kunnen worden gebruikt om list te beperken tot URL's waarmee een gebruiker interactie heeft met een specifieke lijst. Hoewel het in veel gevallen beter is om regels document met een toepasselijke where .

De standaard eagerness voor document is conservative . Aangezien een document uit veel URL's kan bestaan, moet het gebruik van immediate of eager document met voorzichtigheid worden gebruikt (zie ook het gedeelte Chrome-limieten hieronder).

Welke eagerness u moet gebruiken, hangt af van uw site. Voor een zeer eenvoudige statische site kan gretiger speculeren weinig kosten met zich meebrengen en gunstig zijn voor de gebruikers. Sites met complexere architecturen en zwaardere paginaladingen geven er misschien de voorkeur aan om de verspilling te verminderen door minder vaak te speculeren totdat u een positiever signaal krijgt van de gebruikers om de verspilling te beperken.

De moderate optie is een middenweg, en veel sites zouden kunnen profiteren van de volgende eenvoudige speculatieregel die alle links bij hover of pointerdown vooraf zou weergeven als een fundamentele – maar krachtige – implementatie van speculatieregels:

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

Chrome-limieten

Zelfs met de keuze van eagerness heeft Chrome limieten om overmatig gebruik van deze API te voorkomen:

De moderate en conservative instellingen, die afhankelijk zijn van gebruikersinteractie, werken op een First In, First Out (FIFO) manier . Nadat de limiet is bereikt, zal een nieuwe speculatie ervoor zorgen dat de oudste speculatie wordt geannuleerd en vervangen door de nieuwere om geheugen te besparen.

Het feit dat moderate en conservative speculaties door gebruikers worden veroorzaakt, stelt ons in staat een bescheidener drempelwaarde van 2 te gebruiken om geheugen te besparen. De immediate en eager instellingen worden niet geactiveerd door een gebruikersactie en hebben dus een hogere limiet omdat het voor de browser niet mogelijk is om te weten welke nodig zijn en wanneer ze nodig zijn.

Een speculatie die wordt geannuleerd doordat deze uit de FIFO-wachtrij wordt geduwd, kan opnieuw worden geactiveerd (bijvoorbeeld door opnieuw over die link te bewegen), wat ertoe zal leiden dat die URL opnieuw wordt gespeculeerd. In dat geval zal de eerdere speculatie er waarschijnlijk toe hebben geleid dat de browser een aantal bronnen in de HTTP-cache voor die URL in de cache heeft opgeslagen, dus het herhalen van de speculatie zou veel minder netwerk- en dus tijdskosten met zich mee moeten brengen.

De immediate en eager grenzen zijn ook dynamisch. Het verwijderen van een scriptelement voor speculatieregels met behulp van deze gretigheidsniveaus zal capaciteit creëren door de verwijderde speculaties te annuleren. Deze URL's kunnen ook opnieuw worden gespecificeerd als ze zijn opgenomen in een nieuw URL-script en de limiet niet is bereikt.

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

• Gegevens opslaan .
• Energiebesparing .
• Geheugenbeperkingen.
• Wanneer de instelling 'Pagina's vooraf laden' is uitgeschakeld (wat ook expliciet wordt uitgeschakeld door Chrome-extensies zoals uBlock Origin).
• Pagina's geopend in achtergrondtabbladen.

Al deze voorwaarden zijn bedoeld om de impact van overspeculatie te verminderen wanneer dit schadelijk zou zijn voor gebruikers.

Optionele source

Chrome 122 maakt de source optioneel, omdat deze kan worden afgeleid uit de aanwezigheid van de url of where -sleutels. Deze twee speculatieregels zijn dus identiek:

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

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

Speculation-Rules HTTP-header

Speculatieregels kunnen ook worden geleverd door een Speculation-Rules HTTP-header te gebruiken, in plaats van ze rechtstreeks in de HTML van het document op te nemen. Dit maakt eenvoudigere implementatie door CDN's mogelijk zonder dat de documentinhoud zelf hoeft te worden gewijzigd.

De Speculation-Rules HTTP-header wordt met het document geretourneerd 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 u relatieve URL's wilt gebruiken, wilt u wellicht de sleutel "relative_to": "document" opnemen in uw speculatieregels. Anders zijn relatieve URL's relatief volgens de speculatieregels voor de URL van het JSON-bestand. Dit kan met name handig zijn als u enkele (of alle) links met dezelfde oorsprong moet selecteren.

Beter hergebruik van de cache

We hebben een aantal verbeteringen aangebracht aan de caching in Chrome, zodat bij het vooraf ophalen (of zelfs vooraf renderen) van een document bronnen in de HTTP-cache worden opgeslagen en hergebruikt. Dit betekent dat speculeren nog steeds toekomstige voordelen kan hebben, zelfs als die speculatie niet wordt gebruikt.

Dit maakt het herspeculeren (bijvoorbeeld voor documentregels met een moderate gretigheidsinstelling) ook aanzienlijk goedkoper, omdat Chrome de HTTP-cache zal gebruiken voor cachebare bronnen.

We ondersteunen ook het nieuwe No-Vary-Search voorstel om het hergebruik van caches verder te verbeteren.

Ondersteuning No-Vary-Search

Bij het vooraf ophalen of vooraf weergeven van een pagina kunnen bepaalde URL-parameters (technisch bekend als zoekparameters ) onbelangrijk zijn voor de pagina die daadwerkelijk door de server wordt geleverd, en alleen worden gebruikt door JavaScript aan de clientzijde.

UTM-parameters worden bijvoorbeeld door Google Analytics gebruikt voor het meten van campagnes, maar resulteren doorgaans niet in het leveren van verschillende pagina's vanaf de server. Dit betekent dat page1.html?utm_content=123 en page1.html?utm_content=456 dezelfde pagina vanaf de server leveren, zodat dezelfde pagina vanuit de cache opnieuw kan worden gebruikt.

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

Met het No-Vary-Search- voorstel kan een server parameters specificeren die niet resulteren in een verschil met de geleverde bron, en daardoor kan een browser eerder in de cache opgeslagen versies van een document hergebruiken die alleen door deze parameters verschillen. Let op: momenteel wordt dit alleen ondersteund in Chrome (en Chromium-gebaseerde browsers) voor prefetch-navigatiespeculaties.

Speculatieregels ondersteunen het gebruik van expects_no_vary_search om aan te geven waar een No-Vary-Search HTTP-header naar verwachting zal worden geretourneerd. Als u dit wel doet, kunt u onnodige downloads verder voorkomen.

<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 HTML van de beginpagina /products hetzelfde voor zowel product-ID's 123 als 124 . De pagina-inhoud verschilt uiteindelijk echter op basis van weergave aan de clientzijde met behulp van JavaScript om productgegevens op te halen met behulp van de id zoekparameter. Dus halen we die URL gretig vooraf op en deze zou een No-Vary-Search HTTP-header moeten retourneren die aangeeft dat de pagina kan worden gebruikt voor elke id zoekparameter.

Als de gebruiker echter op een van de links klikt voordat de prefetch is voltooid, heeft de browser mogelijk de /products -pagina niet ontvangen. In dit geval weet de browser niet of deze de HTTP-header No-Vary-Search zal bevatten. De browser heeft dan de keuze om de link opnieuw op te halen, of te wachten tot de prefetch is voltooid om te zien of deze een No-Vary-Search HTTP-header bevat. Met de instelling expects_no_vary_search weet de browser dat de paginareactie naar verwachting een HTTP-header No-Vary-Search bevat, en kan de browser wachten tot die prefetch is voltooid.

Demo

We hebben een demo gemaakt op https://speculative-rules.glitch.me/common-fruits.html die kan worden gebruikt om documentregels met een moderate gretigheid in actie te zien:

Open DevTools, klik op het toepassingspaneel . Klik vervolgens in de sectie Achtergrondservices op Speculatieve ladingen en vervolgens op het deelvenster Speculaties , en sorteer op de kolom Status .

Terwijl u over de vruchten zweeft, ziet u dat de pagina's vooraf worden weergegeven. Als u erop klikt, wordt een veel snellere LCP-tijd weergegeven dan bij een van de recepten, die niet vooraf zijn weergegeven. Deze demo wordt ook uitgelegd in de volgende video :

U kunt ook de vorige blogpost over foutopsporingsregels voor speculatieregels bekijken voor meer informatie over hoe u DevTools kunt gebruiken om fouten in speculatieregels op te sporen.

Platformondersteuning voor speculatieregels

Hoewel speculatieregels relatief eenvoudig te implementeren zijn door de regels in een <script type="speculationrules"> element te injecteren, kan platformondersteuning dit met één klik doen. We hebben met verschillende platforms en partners samengewerkt om het gemakkelijker te maken speculatieregels uit te rollen.

We werken er ook hard aan om de API te standaardiseren via de Web Incubator Community Group (WICG) zodat andere browsers deze opwindende API ook kunnen implementeren als ze dat willen.

WordPress

Het WordPress Core Performance-team (inclusief ontwikkelaars van Google) heeft een plug-in voor speculatieregels gemaakt. Deze plug-in maakt een eenvoudige toevoeging van documentregels met één klik mogelijk aan elke WordPress-site. Deze plug-in kan ook worden geïnstalleerd via de WordPress Performance Lab- plug-in, die u ook zou moeten overwegen om te installeren, omdat deze u op de hoogte houdt van gerelateerde prestatie-plug-ins van het team.

Er zijn twee groepen instellingen beschikbaar: de Speculatiemodus en de Eagerness -instelling:

Voor meer gecompliceerde instellingen, bijvoorbeeld om bepaalde URL's uit te sluiten van vooraf ophalen of vooraf weergeven, leest u de documentatie .

Akamai

Akamai is een van 's werelds toonaangevende CDN-providers en experimenteert al een tijdje actief met de Speculation Rules API. Akamai heeft documentatie vrijgegeven over hoe klanten deze API kunnen inschakelen in hun CDN-instellingen. Ze hebben ook eerder de indrukwekkende resultaten gedeeld die mogelijk zijn met deze nieuwe API .

NitroPack

NitroPack is een oplossing voor prestatie-optimalisatie die hun aangepaste navigatie-AI gebruikt om te voorspellen welke pagina's moeten worden toegevoegd aan speculatieregels, met als doel een langere doorlooptijd te bieden dan het zweven over een link, maar zonder de verspilling van onnodig speculeren op alle waargenomen links. Zie de Nitropack Speculation Rules API-documentatie voor meer informatie. Deze innovatieve oplossing laat zien dat de oudere lijstregels nog steeds veel te bieden hebben, in combinatie met sitespecifieke inzichten.

Het Chrome-team werkte ook samen met NitroPack aan een webinar voor de Speculation Rules API voor wie op zoek was naar meer informatie, inclusief een goede discussie over de afwegingen die nodig zijn tussen vroeg en vaak speculeren, maar ook laat en minder vaak.

Astro

Astro heeft in 4.2 op experimentele basis prerendering-pagina's toegevoegd met behulp van de Speculation Rules API , waardoor ontwikkelaars die Astro gebruiken deze functie gemakkelijk kunnen inschakelen, terwijl ze terugvallen op een standaard prefetch voor browsers die de Speculation Rules API niet ondersteunen. Lees hun client prerender-documentatie voor meer informatie.

Conclusie

Deze toevoegingen aan de Speculation Rules API zorgen voor een veel eenvoudiger gebruik van deze opwindende nieuwe prestatiefunctie voor sites, met minder risico op verspilling van middelen door ongebruikte speculaties. Het is opwindend om te zien dat platforms al gebruik maken van deze API. We hopen op een bredere adoptie van deze API in 2024, en uiteindelijk op betere prestaties voor de eindgebruikers.

Naast de prestatiewinst die de Speculation Rules API biedt, zijn we ook benieuwd welke nieuwe mogelijkheden dit biedt. View Transitions is een nieuwe API waarmee ontwikkelaars gemakkelijker overgangen tussen navigaties kunnen specificeren. Dit is momenteel beschikbaar voor Single Page Applications (SPA's), maar de versie met meerdere pagina's is in ontwikkeling (en beschikbaar achter een vlag in Chrome). Prerender is een natuurlijke aanvulling op die functie om ervoor te zorgen dat er geen vertraging optreedt, die anders de verbetering van de gebruikerservaring zou verhinderen die de transitie moet bieden. We hebben al sites zien experimenteren met deze combinatie .

We kijken uit naar de verdere acceptatie van de Speculation Rules API in 2024 en houden u op de hoogte van eventuele verdere verbeteringen die we aan de API aanbrengen.

Dankbetuigingen

Miniatuur van Robbie Down op Unsplash