Verbeteringen aan de Speculatieregels-API

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 kleine reeks 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 over een link beweegt (of tijdens 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 als je eagerness kiest, heeft Chrome limieten om overmatig gebruik van deze API te voorkomen:

eagerness Vooraf ophalen Voorweergave
immediate / eager 50 10
moderate / conservative 2 (FIFO) 2 (FIFO)
Speculatielimieten in Chrome

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 zullen relatieve URL's relatief zijn 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 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 de pagina /products mogelijk 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:

Schermafbeelding van een demosite die met een glitch is gemaakt en een aantal links bevat met het label fruit. DevTools is geopend en laat zien dat twee van de links (apple.html en orange.html) al succesvol zijn vooraf weergegeven.
Speculatieregels demo

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 foutopsporing voor speculatieregels bekijken voor meer informatie over het gebruik van DevTools voor het debuggen van speculatieregels.

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:

Schermafbeelding van een leespaneel voor WordPress-instellingen met instellingen voor speculatieregels. Er zijn twee opties: Speculatiemodus met de optie Prefetch of Prerender, en een Eagerness-instelling met conservatieve, gematigde of enthousiaste instellingen.
WordPress Speculatieregels-plug-in

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 .

Uxify

Uxify (voorheen onderdeel van 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 Uxify 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 heeft ook met het team samengewerkt aan een webinar voor de Speculation Rules API voor mensen die op zoek zijn 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

,

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 kleine reeks 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 over een link beweegt (of tijdens 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 als je eagerness kiest, heeft Chrome limieten om overmatig gebruik van deze API te voorkomen:

eagerness Vooraf ophalen Voorweergave
immediate / eager 50 10
moderate / conservative 2 (FIFO) 2 (FIFO)
Speculatielimieten in Chrome

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 zullen relatieve URL's relatief zijn 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 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 de pagina /products mogelijk 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:

Schermafbeelding van een demosite die met een glitch is gemaakt en een aantal links bevat met het label fruit. DevTools is geopend en laat zien dat twee van de links (apple.html en orange.html) al succesvol zijn vooraf weergegeven.
Speculatieregels demo

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 foutopsporing voor speculatieregels bekijken voor meer informatie over het gebruik van DevTools voor het debuggen van speculatieregels.

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:

Schermafbeelding van een leespaneel voor WordPress-instellingen met instellingen voor speculatieregels. Er zijn twee opties: Speculatiemodus met de optie Prefetch of Prerender, en een Eagerness-instelling met conservatieve, gematigde of enthousiaste instellingen.
WordPress Speculatieregels-plug-in

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 .

Uxify

Uxify (voorheen onderdeel van 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 Uxify 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 heeft ook met het team samengewerkt aan een webinar voor de Speculation Rules API voor mensen die op zoek zijn 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 speculatieregels API bieden, zijn we ook verheugd om te zien welke nieuwe kansen dit opent. View Transitions is een nieuwe API waarmee ontwikkelaars gemakkelijker overgangen tussen navigaties kunnen specificeren. Dit is momenteel beschikbaar voor applicaties met één pagina (SPA's), maar de versie met meerdere pagina's is aan de gang (en beschikbaar achter een vlag in Chrome). PRERENDER is een natuurlijke add-on voor die functie om ervoor te zorgen dat er geen vertraging is, wat anders de verbetering van de gebruikerservaring zou voorkomen die de overgang is bedoeld. We hebben al sites gezien die met deze combinatie experimenteren .

We kijken uit naar de verdere acceptatie van de speculatieregels API gedurende 2024 en houden u op de hoogte van verdere verbeteringen die we aan de API aanbrengen.

Dankbetuigingen

Miniatuur door Robbie op Unsplash

,

Het Chrome -team heeft gewerkt aan enkele opwindende updates voor de speculatieregels die API gebruikt om de navigatieprestaties te verbeteren door toekomstige navigaties te prefeteren of zelfs voor te zorgen. Deze extra verbeteringen zijn nu allemaal verkrijgbaar bij Chrome 122 (met enkele functies beschikbaar in eerdere versies).

Deze wijzigingen maken pagina's met prefetching en voorliggende pagina's aanzienlijk gemakkelijker te implementeren en minder verspillend, waarvan we hopen dat het verdere acceptatie zal aanmoedigen.

Aanvullende functies

Eerst is een uitleg van de nieuwe toevoegingen die we hebben toegevoegd aan de speculatieregels API en hoe deze te gebruiken. Hierna laten we je een demo zien, zodat je ze in actie kunt zien.

Documentregels

Eerder werkte de speculatieregels API door een lijst met URL's op te geven om te prefetch of Persender:

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

De speculatieregels waren semi-dynamisch omdat nieuwe speculatieregelscripts konden worden toegevoegd, en oude scripts verwijderd om die speculaties weg te gooien (merk op dat het bijwerken van de urls -lijst van een bestaand speculatieregelscript geen wijziging in speculaties veroorzaakt). Het liet echter nog steeds de keuze van URL's over aan de site, hetzij door ze te verzenden van de server op pagina-aanvraagtijd, of door deze lijst dynamisch te maken via client-side JavaScript.

Lijstregels blijven als een optie voor eenvoudigere use cases (waarbij de volgende navigatie afkomstig is van een kleine set van de voor de hand liggende), of meer geavanceerde use cases (waarbij de lijst met URL's dynamisch wordt berekend op basis van de heuristieken die de site -eigenaar wil gebruiken en vervolgens in de pagina worden ingevoegd).

Als alternatief zijn we verheugd om een ​​nieuwe optie te bieden voor automatische link vinden met behulp van documentregels . Dit werkt door URL's uit het document zelf te kopen 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 -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>

Hierdoor kan een enkele speculatieregelset worden gebruikt op de hele site, in plaats van specifieke per pagina te hebben, waardoor sites veel gemakkelijker zijn om speculatieregels te implementeren.

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

Gretigheid

Met elke vorm van speculatie is er een afweging tussen precisie en terugroeping en doorlooptijd. Alle links op pagina laden voor het laden van de pagina betekent dat u vrijwel zeker een link voor een link op een gebruiker klikt (ervan uitgaande dat ze op een link op dezelfde locatie op de pagina klikken), en met zoveel mogelijk doorlooptijd, maar met een potentieel grote verspilling van bandbreedte.

Aan de andere kant, alleen vooraangevend als een gebruiker op een link is geklikt, voorkomt afval, maar ten koste van een veel verminderde doorlooptijd. Dit betekent dat het onwaarschijnlijk is dat het voor- heeft voltooid voordat de browser naar die pagina schakelt.

Met de instelling van eagerness kunt u definiëren wanneer speculaties moeten worden uitgevoerd, waardoor u moet worden gescheiden wanneer u moet speculeren op welke URL's om speculaties uit te voeren. 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 worden waargenomen.
  • eager : dit gedraagt ​​zich momenteel identiek aan de immediate setting, maar in de toekomst willen we dit ergens tussen immediate en moderate plaatsen.
  • moderate : dit voert speculaties uit als u over een link voor 200 milliseconden zweeft (of op de pointerdown -gebeurtenis als dat eerder is, en op mobiel waar geen hover -evenement is).
  • conservative : dit speculeert op Pointer of Touch Down.

De eagerness voor list is immediate . De moderate en conservative opties kunnen worden gebruikt om list te beperken tot URL's waarmee een gebruiker met een specifieke lijst communiceert. Hoewel in veel gevallen document regels met een geschikte where voorwaarde geschikter zijn.

De eagerness voor document is conservative . Aangezien een document uit veel URL's kan bestaan, moet het gebruik van immediate of eager voor document met voorzichtigheid worden gebruikt (zie ook de sectie Chrome Limits Volgende).

Welke eagerness om te gebruiken afhankelijk is van uw site. Voor een zeer eenvoudige statische site kan speculeren meer gretig weinig kosten hebben en gunstig zijn voor gebruikers. Sites met meer complexe architecturen en zwaardere paginagetallasten kunnen er de voorkeur aan geven om afval te verminderen door minder vaak te speculeren totdat u een positiever signaal van intentie krijgt van gebruikers om afval te beperken.

De moderate optie is een middenweg, en veel sites kunnen profiteren van de volgende eenvoudige speculatieregel die alle links voor Hover of Pointerdown als een eenvoudige - YET -krachtige - implementatie van speculatieregels zou voordoen:

<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:

eagerness Prefeteren Voor-
immediate / eager 50 10
moderate / conservative 2 (FIFO) 2 (FIFO)
Speculatielimieten bij Chrome

De moderate en conservative instellingen - die afhankelijk zijn van gebruikersinteractie - werken op een eerste in, eerste (FIFO) manier . Na het bereiken van de limiet zal een nieuwe speculatie ervoor zorgen dat de oudste speculatie wordt geannuleerd en vervangen door de nieuwere om het geheugen te behouden.

Het feit dat moderate en conservative speculaties door gebruikers worden geactiveerd, stelt ons in staat om een ​​meer bescheiden drempel 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 niet mogelijk is voor de browser om te weten welke nodig is en wanneer ze nodig zijn.

Een speculatie die wordt geannuleerd door uit de FIFO-wachtrij te worden geduwd, kan opnieuw worden geactiveerd-bijvoorbeeld door die link opnieuw te zweven-waardoor die URL opnieuw wordt gespeculeerd. In dat geval zal de vorige speculatie waarschijnlijk ervoor hebben gezorgd dat de browser sommige bronnen in de HTTP -cache voor die URL heeft gecacheerd, dus het herhalen van de speculatie zou een veel verminderd netwerk moeten hebben en dus tijdkosten.

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

Chrome zal ook voorkomen dat speculaties worden gebruikt in bepaalde voorwaarden, waaronder:

  • Save-data .
  • Energiebesparing .
  • Geheugenbeperkingen.
  • Wanneer de instelling "Voorlaadpagina's" wordt uitgeschakeld (die ook expliciet wordt uitgeschakeld door chromen extensies zoals Ublock Origin).
  • Pagina's geopend op achtergrondtabbladen.

Al deze voorwaarden zijn bedoeld om de impact van over-speculatie te verminderen wanneer het 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 daarom 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 met behulp van een Speculation-Rules HTTP-header, in plaats van deze rechtstreeks op te nemen in de HTML van het document. Dit maakt een gemakkelijkere implementatie door CDN's mogelijk zonder dat de documentinhoud zelf moet worden gewijzigd.

De HTTP-header Speculation-Rules wordt geretourneerd met het document en wijst op 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 doorgeven.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Als u relatieve URL's wilt gebruiken, wilt u misschien de toets "relative_to": "document" opnemen in uw speculatieregels. Anders zijn relatieve URL's relatief de speculatieregels JSON -bestands URL. Dit kan met name handig zijn als u sommige-of alle-Same-Origin-links moet selecteren.

Beter hergebruik van cache

We hebben een aantal verbeteringen aangebracht aan het cachen in Chrome, zodat een document voor het preventeren (of zelfs voorzitting) een document zal opslaan en hergebruiken in de HTTP -cache. Dit betekent dat speculeren nog steeds toekomstige voordelen kan hebben, zelfs als die speculatie niet wordt gebruikt.

Dit maakt ook opnieuw gespeculeerd (bijvoorbeeld voor documentregels met een moderate instelling van de gretigheid) aanzienlijk goedkoper, omdat Chrome de HTTP-cache zal gebruiken voor cachebare bronnen.

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

Ondersteuning No-Vary-Search

Bij het prefetcheren of voorgaan 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 client.

UTM -parameters worden bijvoorbeeld gebruikt door Google Analytics voor campagnemeting, maar resulteren meestal niet in verschillende pagina's die vanaf de server worden afgeleverd. Dit betekent dat page1.html?utm_content=123 en page1.html?utm_content=456 dezelfde pagina van de server levert, zodat dezelfde pagina kan worden hergebruikt vanuit de cache.

Evenzo kunnen toepassingen andere URL -parameters gebruiken die alleen de clientzijde worden behandeld.

Met het voorstel zonder zoekopdracht kan een server parameters opgeven die niet resulteren in een verschil met de geleverde bron en daarom een ​​browser toestaan ​​eerder in cache-versies van een document te hergebruiken die alleen verschillen door deze parameters. OPMERKING: Momenteel wordt dit alleen ondersteund in Chrome (en op chroom gebaseerde browsers) voor prefetch-navigatiespeculaties.

Speculatieregels ondersteunen met behulp van expects_no_vary_search om aan te geven waar naar verwachting een HTTP-koptekst No-Vary-Search wordt geretourneerd. Dit kan helpen om onnodige downloads verder te 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 initiële pagina HTML /products hetzelfde voor zowel product -ID's 123 als 124 . De pagina-inhoud verschilt uiteindelijk echter op basis van de rendering van client-side met behulp van JavaScript om productgegevens op te halen met behulp van de id zoekparameter. Dus we stellen die URL gretig vooraf en het zou een No-Vary-Search HTTP-koptekst moeten retourneren die de pagina aantoont, kan worden gebruikt voor elke id zoekparam.

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

Demo

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

Screenshot van een demo -site die is gemaakt in Glitch met een aantal links die met fruit zijn gelabeld. DevTools is open en laat zien dat twee van de links (Apple.html en Orange.html) al met succes worden voorgelegd.
Speculatieregels demo

Open Devtools, klik op het toepassingspaneel . Klik vervolgens in het gedeelte Background Services op Speculatieve belastingen en vervolgens op het deelvenster Speculaties en sorteer op de kolom Status .

Terwijl je over de vruchten zweeft, zie je de pagina's voor het voordeel. Als u erop klikt, wordt een veel snellere LCP -tijd weergegeven dan een van de recepten, die niet worden voorgesteld. Deze demo wordt ook uitgelegd in de volgende video :

U kunt ook de vorige blogberichtpost van de Debugging Speculation Rules bekijken voor meer informatie over het gebruik van DevTools om speculatieregels te debuggen.

Platformondersteuning voor speculatieregels

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

We werken ook hard om de API te standaardiseren via de Web Incubator Community Group (WICG) om andere browsers ook deze opwindende API te laten implementeren als ze dat kiezen.

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 één klik van documentregels ondersteuning voor elke WordPress-site mogelijk. Deze plug -in is ook beschikbaar om te installeren via de WordPress Performance Lab -plug -in, die u ook moet overwegen te installeren, omdat deze u up -to -date houdt op gerelateerde prestatie -plug -ins van het team.

Twee groepen instellingen zijn beschikbaar: de speculatiemodus en de gretigheidsinstelling :

Screenshot van een WordPress -instellingen leespaneel met speculatieregelsinstellingen. Er zijn twee opties: Speculatiemodus met optie om te prefeteren of voor te stellen, en een gretigheidsinstelling met conservatieve, gematigde of enthousiaste instellingen.
WordPress Speculation Rules plug -in

Voor meer gecompliceerde instellingen - bijvoorbeeld om bepaalde URL's uit te sluiten die worden vooraf bepaald of voorgesteld - lees de documentatie .

Akamai

Akamai is een van 's werelds toonaangevende CDN -providers en ze experimenteren al enige tijd actief met de speculatieregels API. Akamai heeft documentatie vrijgegeven over hoe klanten deze API in hun CDN -instellingen kunnen inschakelen. Ze hebben eerder ook de indrukwekkende resultaten gedeeld met deze nieuwe API .

Uxify

Uxify (voorheen onderdeel van Nitropack) is een oplossing voor prestatie -optimalisatie die hun aangepaste navigatie AI gebruikt om te voorspellen welke pagina's ze moeten toevoegen aan speculatieregels, die tot doel hebben een langere doorlooptijd te bieden dan een link te schommelen, maar zonder de verspilling van onnodig speculatie op alle waargenomen links. Zie de Uxify Speculation Rules API -documentatie voor meer informatie. Deze innovatieve oplossing laat zien dat er nog steeds genoeg is voor de oudere lijstregels die kunnen worden aangeboden in combinatie met site-specifieke inzichten.

Het Chrome -team werkte ook samen met het team op een webinar voor de speculatieregels API voor diegenen die op zoek zijn naar meer informatie, inclusief een goede discussie over de overwegingen die nodig zijn tussen vroeg en vaak speculeren, evenals laat en minder vaak.

Astro

Astro voegde voorstaande pagina's toe met behulp van de speculatieregels API in 4.2 op een experimentele basis, waardoor ontwikkelaars met Astro deze functie gemakkelijk kunnen mogelijk maken, terwijl ze terugvallen op een standaardprefetch voor browsers die de speculatieregels API niet ondersteunen. Lees hun klant PRERENDER -documentatie voor meer informatie.

Conclusie

Deze toevoegingen aan de speculatieregels API zorgen voor een veel eenvoudiger gebruik van deze opwindende nieuwe prestatie -functie voor sites, met minder risico om middelen te verspillen met ongebruikte speculaties. Het is opwindend om platforms al in deze API te zien leunen. We hopen in 2024 een bredere acceptatie van deze API te zien, en uiteindelijk betere prestaties om gebruikers te beëindigen.

Naast de prestatiewinst die de speculatieregels API bieden, zijn we ook verheugd om te zien welke nieuwe kansen dit opent. View Transitions is een nieuwe API waarmee ontwikkelaars gemakkelijker overgangen tussen navigaties kunnen specificeren. Dit is momenteel beschikbaar voor applicaties met één pagina (SPA's), maar de versie met meerdere pagina's is aan de gang (en beschikbaar achter een vlag in Chrome). PRERENDER is een natuurlijke add-on voor die functie om ervoor te zorgen dat er geen vertraging is, wat anders de verbetering van de gebruikerservaring zou voorkomen die de overgang is bedoeld. We hebben al sites gezien die met deze combinatie experimenteren .

We kijken uit naar de verdere acceptatie van de speculatieregels API gedurende 2024 en houden u op de hoogte van verdere verbeteringen die we aan de API aanbrengen.

Dankbetuigingen

Miniatuur door Robbie op Unsplash

,

Het Chrome -team heeft gewerkt aan enkele opwindende updates voor de speculatieregels die API gebruikt om de navigatieprestaties te verbeteren door toekomstige navigaties te prefeteren of zelfs voor te zorgen. Deze extra verbeteringen zijn nu allemaal verkrijgbaar bij Chrome 122 (met enkele functies beschikbaar in eerdere versies).

Deze wijzigingen maken pagina's met prefetching en voorliggende pagina's aanzienlijk gemakkelijker te implementeren en minder verspillend, waarvan we hopen dat het verdere acceptatie zal aanmoedigen.

Aanvullende functies

Eerst is een uitleg van de nieuwe toevoegingen die we hebben toegevoegd aan de speculatieregels API en hoe deze te gebruiken. Hierna laten we je een demo zien, zodat je ze in actie kunt zien.

Documentregels

Eerder werkte de speculatieregels API door een lijst met URL's op te geven om te prefetch of Persender:

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

De speculatieregels waren semi-dynamisch omdat nieuwe speculatieregelscripts konden worden toegevoegd, en oude scripts verwijderd om die speculaties weg te gooien (merk op dat het bijwerken van de urls -lijst van een bestaand speculatieregelscript geen wijziging in speculaties veroorzaakt). Het liet echter nog steeds de keuze van URL's over aan de site, hetzij door ze te verzenden van de server op pagina-aanvraagtijd, of door deze lijst dynamisch te maken via client-side JavaScript.

Lijstregels blijven als een optie voor eenvoudigere use cases (waarbij de volgende navigatie afkomstig is van een kleine set van de voor de hand liggende), of meer geavanceerde use cases (waarbij de lijst met URL's dynamisch wordt berekend op basis van de heuristieken die de site -eigenaar wil gebruiken en vervolgens in de pagina worden ingevoegd).

Als alternatief zijn we verheugd om een ​​nieuwe optie te bieden voor automatische link vinden met behulp van documentregels . Dit werkt door URL's uit het document zelf te kopen 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 -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>

Hierdoor kan een enkele speculatieregelset worden gebruikt op de hele site, in plaats van specifieke per pagina te hebben, waardoor sites veel gemakkelijker zijn om speculatieregels te implementeren.

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

Gretigheid

Met elke vorm van speculatie is er een afweging tussen precisie en terugroeping en doorlooptijd. Alle links op pagina laden voor het laden van de pagina betekent dat u vrijwel zeker een link voor een link op een gebruiker klikt (ervan uitgaande dat ze op een link op dezelfde locatie op de pagina klikken), en met zoveel mogelijk doorlooptijd, maar met een potentieel grote verspilling van bandbreedte.

Aan de andere kant, alleen vooraangevend als een gebruiker op een link is geklikt, voorkomt afval, maar ten koste van een veel verminderde doorlooptijd. Dit betekent dat het onwaarschijnlijk is dat het voor- heeft voltooid voordat de browser naar die pagina schakelt.

Met de instelling van eagerness kunt u definiëren wanneer speculaties moeten worden uitgevoerd, waardoor u moet worden gescheiden wanneer u moet speculeren op welke URL's om speculaties uit te voeren. 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 worden waargenomen.
  • eager : dit gedraagt ​​zich momenteel identiek aan de immediate setting, maar in de toekomst willen we dit ergens tussen immediate en moderate plaatsen.
  • moderate : dit voert speculaties uit als u over een link voor 200 milliseconden zweeft (of op de pointerdown -gebeurtenis als dat eerder is, en op mobiel waar geen hover -evenement is).
  • conservative : dit speculeert op Pointer of Touch Down.

De eagerness voor list is immediate . De moderate en conservative opties kunnen worden gebruikt om list te beperken tot URL's waarmee een gebruiker met een specifieke lijst communiceert. Hoewel in veel gevallen document regels met een geschikte where voorwaarde geschikter zijn.

De eagerness voor document is conservative . Aangezien een document uit veel URL's kan bestaan, moet het gebruik van immediate of eager voor document met voorzichtigheid worden gebruikt (zie ook de sectie Chrome Limits Volgende).

Welke eagerness om te gebruiken afhankelijk is van uw site. Voor een zeer eenvoudige statische site kan speculeren meer gretig weinig kosten hebben en gunstig zijn voor gebruikers. Sites met meer complexe architecturen en zwaardere paginagetallasten kunnen er de voorkeur aan geven om afval te verminderen door minder vaak te speculeren totdat u een positiever signaal van intentie krijgt van gebruikers om afval te beperken.

De moderate optie is een middenweg, en veel sites kunnen profiteren van de volgende eenvoudige speculatieregel die alle links voor Hover of Pointerdown als een eenvoudige - YET -krachtige - implementatie van speculatieregels zou voordoen:

<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:

eagerness Prefeteren Voor-
immediate / eager 50 10
moderate / conservative 2 (FIFO) 2 (FIFO)
Speculatielimieten bij Chrome

De moderate en conservative instellingen - die afhankelijk zijn van gebruikersinteractie - werken op een eerste in, eerste (FIFO) manier . Na het bereiken van de limiet zal een nieuwe speculatie ervoor zorgen dat de oudste speculatie wordt geannuleerd en vervangen door de nieuwere om het geheugen te behouden.

Het feit dat moderate en conservative speculaties door gebruikers worden geactiveerd, stelt ons in staat om een ​​meer bescheiden drempel 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 niet mogelijk is voor de browser om te weten welke nodig is en wanneer ze nodig zijn.

Een speculatie die wordt geannuleerd door uit de FIFO-wachtrij te worden geduwd, kan opnieuw worden geactiveerd-bijvoorbeeld door die link opnieuw te zweven-waardoor die URL opnieuw wordt gespeculeerd. In dat geval zal de vorige speculatie waarschijnlijk ervoor hebben gezorgd dat de browser sommige bronnen in de HTTP -cache voor die URL heeft gecacheerd, dus het herhalen van de speculatie zou een veel verminderd netwerk moeten hebben en dus tijdkosten.

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

Chrome zal ook voorkomen dat speculaties worden gebruikt in bepaalde voorwaarden, waaronder:

  • Save-data .
  • Energiebesparing .
  • Geheugenbeperkingen.
  • Wanneer de instelling "Voorlaadpagina's" wordt uitgeschakeld (die ook expliciet wordt uitgeschakeld door chromen extensies zoals Ublock Origin).
  • Pagina's geopend op achtergrondtabbladen.

Al deze voorwaarden zijn bedoeld om de impact van over-speculatie te verminderen wanneer het 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 daarom 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 met behulp van een Speculation-Rules HTTP-header, in plaats van deze rechtstreeks op te nemen in de HTML van het document. Dit maakt een gemakkelijkere implementatie door CDN's mogelijk zonder dat de documentinhoud zelf moet worden gewijzigd.

De HTTP-header Speculation-Rules wordt geretourneerd met het document en wijst op 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 doorgeven.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Als u relatieve URL's wilt gebruiken, wilt u misschien de toets "relative_to": "document" opnemen in uw speculatieregels. Anders zijn relatieve URL's relatief de speculatieregels JSON -bestands URL. Dit kan met name handig zijn als u sommige-of alle-Same-Origin-links moet selecteren.

Beter hergebruik van cache

We hebben een aantal verbeteringen aangebracht aan het cachen in Chrome, zodat een document voor het preventeren (of zelfs voorzitting) een document zal opslaan en hergebruiken in de HTTP -cache. Dit betekent dat speculeren nog steeds toekomstige voordelen kan hebben, zelfs als die speculatie niet wordt gebruikt.

Dit maakt ook opnieuw gespeculeerd (bijvoorbeeld voor documentregels met een moderate instelling van de gretigheid) aanzienlijk goedkoper, omdat Chrome de HTTP-cache zal gebruiken voor cachebare bronnen.

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

Ondersteuning No-Vary-Search

Bij het prefetcheren of voorgaan 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 client.

UTM -parameters worden bijvoorbeeld gebruikt door Google Analytics voor campagnemeting, maar resulteren meestal niet in verschillende pagina's die vanaf de server worden afgeleverd. Dit betekent dat page1.html?utm_content=123 en page1.html?utm_content=456 dezelfde pagina van de server levert, zodat dezelfde pagina kan worden hergebruikt vanuit de cache.

Evenzo kunnen toepassingen andere URL -parameters gebruiken die alleen de clientzijde worden behandeld.

Met het voorstel zonder zoekopdracht kan een server parameters opgeven die niet resulteren in een verschil met de geleverde bron en daarom een ​​browser toestaan ​​eerder in cache-versies van een document te hergebruiken die alleen verschillen door deze parameters. OPMERKING: Momenteel wordt dit alleen ondersteund in Chrome (en op chroom gebaseerde browsers) voor prefetch-navigatiespeculaties.

Speculatieregels ondersteunen met behulp van expects_no_vary_search om aan te geven waar naar verwachting een HTTP-koptekst No-Vary-Search wordt geretourneerd. Dit kan helpen om onnodige downloads verder te 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 initiële pagina HTML /products hetzelfde voor zowel product -ID's 123 als 124 . De pagina-inhoud verschilt uiteindelijk echter op basis van de rendering van client-side met behulp van JavaScript om productgegevens op te halen met behulp van de id zoekparameter. Dus we stellen die URL gretig vooraf en het zou een No-Vary-Search HTTP-koptekst moeten retourneren die de pagina aantoont, kan worden gebruikt voor elke id zoekparam.

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

Demo

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

Screenshot van een demo -site die is gemaakt in Glitch met een aantal links die met fruit zijn gelabeld. DevTools is open en laat zien dat twee van de links (Apple.html en Orange.html) al met succes worden voorgelegd.
Speculatieregels demo

Open Devtools, klik op het toepassingspaneel . Klik vervolgens in het gedeelte Background Services op Speculatieve belastingen en vervolgens op het deelvenster Speculaties en sorteer op de kolom Status .

Terwijl je over de vruchten zweeft, zie je de pagina's voor het voordeel. Als u erop klikt, wordt een veel snellere LCP -tijd weergegeven dan een van de recepten, die niet worden voorgesteld. Deze demo wordt ook uitgelegd in de volgende video :

U kunt ook de vorige blogberichtpost van de Debugging Speculation Rules bekijken voor meer informatie over het gebruik van DevTools om speculatieregels te debuggen.

Platformondersteuning voor speculatieregels

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

We werken ook hard om de API te standaardiseren via de Web Incubator Community Group (WICG) om andere browsers ook deze opwindende API te laten implementeren als ze dat kiezen.

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 één klik van documentregels ondersteuning voor elke WordPress-site mogelijk. Deze plug -in is ook beschikbaar om te installeren via de WordPress Performance Lab -plug -in, die u ook moet overwegen te installeren, omdat deze u up -to -date houdt op gerelateerde prestatie -plug -ins van het team.

Twee groepen instellingen zijn beschikbaar: de speculatiemodus en de gretigheidsinstelling :

Screenshot van een WordPress -instellingen leespaneel met speculatieregelsinstellingen. Er zijn twee opties: Speculatiemodus met optie om te prefeteren of voor te stellen, en een gretigheidsinstelling met conservatieve, gematigde of enthousiaste instellingen.
WordPress Speculation Rules plug -in

Voor meer gecompliceerde instellingen - bijvoorbeeld om bepaalde URL's uit te sluiten die worden vooraf bepaald of voorgesteld - lees de documentatie .

Akamai

Akamai is een van 's werelds toonaangevende CDN -providers en ze experimenteren al enige tijd actief met de speculatieregels API. Akamai heeft documentatie vrijgegeven over hoe klanten deze API in hun CDN -instellingen kunnen inschakelen. Ze hebben eerder ook de indrukwekkende resultaten gedeeld met deze nieuwe API .

Uxify

Uxify (voorheen onderdeel van Nitropack) is een oplossing voor prestatie -optimalisatie die hun aangepaste navigatie AI gebruikt om te voorspellen welke pagina's ze moeten toevoegen aan speculatieregels, die tot doel hebben een langere doorlooptijd te bieden dan een link te schommelen, maar zonder de verspilling van onnodig speculatie op alle waargenomen links. Zie de Uxify Speculation Rules API -documentatie voor meer informatie. Deze innovatieve oplossing laat zien dat er nog steeds genoeg is voor de oudere lijstregels die kunnen worden aangeboden in combinatie met site-specifieke inzichten.

Het Chrome -team werkte ook samen met het team op een webinar voor de speculatieregels API voor diegenen die op zoek zijn naar meer informatie, inclusief een goede discussie over de overwegingen die nodig zijn tussen vroeg en vaak speculeren, evenals laat en minder vaak.

Astro

Astro added prerendering pages using the Speculation Rules API in 4.2 on an experimental basis, allowing developers using Astro to enable this feature with ease, while falling back to a standard prefetch for browsers that do not support the Speculation Rules API. Read their client prerender documentation for more information.

Conclusie

These additions to the Speculation Rules API allow for a much simpler use of this exciting new performance feature for sites, with less risk of wasting resources with unused speculations. It is exciting to see platforms already lean into this API. We hope to see wider adoption of this API in 2024, and ultimately better performance to end users as a result.

In addition to the performance gains the Speculation Rules API provides, we're also excited to see what new opportunities this opens up. View Transitions is a new API that allows developers to specify transitions between navigations more easily. This is currently available for Single Page Applications (SPAs), but the multi-page version is in progress (and available behind a flag in Chrome). Prerender is a natural add-on to that feature to ensure there is no delay, which would otherwise prevent the user experience improvement the transition is intended to provide. We have already seen sites experimenting with this combination .

We look forward to further adoption of the Speculation Rules API throughout 2024, and will keep you updated on any further improvements we make to the API.

Dankbetuigingen

Thumbnail by Robbie Down on Unsplash