Geef pagina's vooraf weer in Chrome voor directe paginanavigatie

Browser Support

  • Chroom: 109.
  • Rand: 109.
  • Firefox: niet ondersteund.
  • Safari: niet ondersteund.

Source

Het Chrome-team heeft de volledige pre-rendering van toekomstige pagina's waar een gebruiker waarschijnlijk naartoe zal navigeren teruggebracht.

Een korte geschiedenis van prerendereren

In het verleden ondersteunde Chrome de <link rel="prerender" href="/next-page"> bronhint, maar deze werd buiten Chrome niet breed ondersteund en het was geen erg expressieve API.

Deze verouderde pre-rendering met behulp van de link rel=prerender -hint werd verouderd ten gunste van NoState Prefetch , die in plaats daarvan de bronnen ophaalde die nodig waren voor de toekomstige pagina, maar de pagina niet volledig vooraf renderde en ook geen JavaScript uitvoerde. NoState Prefetch helpt de paginaprestaties te verbeteren door het laden van bronnen te verbeteren, maar levert geen onmiddellijke paginalading op zoals een volledige prerender dat zou doen.

Het Chrome-team heeft nu volledige pre-rendering opnieuw geïntroduceerd in Chrome. Om complicaties met bestaand gebruik te voorkomen en om toekomstige uitbreiding van prerendering mogelijk te maken, zal dit nieuwe prerender-mechanisme geen gebruik maken van de syntaxis <link rel="prerender"...> , die van kracht blijft voor NoState Prefetch, met de bedoeling dit op een bepaald moment in de toekomst stop te zetten.

Hoe wordt een pagina vooraf weergegeven?

Een pagina kan op vier manieren vooraf worden weergegeven, die er allemaal op gericht zijn de navigatie sneller te maken:

  1. Wanneer u een URL in de Chrome-adresbalk typt (ook wel 'de omnibox' genoemd), kan Chrome de pagina automatisch vooraf voor u weergeven, als er een groot vertrouwen in is dat u die pagina zult bezoeken, op basis van uw eerdere browsegeschiedenis.
  2. Wanneer u de bladwijzerbalk gebruikt, kan Chrome de pagina automatisch vooraf weergeven door de aanwijzer op een van de bladwijzerknoppen te houden.
  3. Wanneer u een zoekterm in de adresbalk van Chrome typt, kan Chrome de pagina met zoekresultaten automatisch vooraf weergeven, wanneer de zoekmachine hierom opdracht geeft.
  4. Sites kunnen de Speculation Rules API gebruiken om Chrome programmatisch te vertellen welke pagina's vooraf moeten worden weergegeven. Dit vervangt wat <link rel="prerender"...> vroeger deed en stelt sites in staat proactief een pagina vooraf weer te geven op basis van speculatieregels op de pagina. Deze kunnen statisch op de pagina's aanwezig zijn, of dynamisch worden geïnjecteerd door JavaScript, zoals de pagina-eigenaar dat nodig acht.

In elk van deze gevallen gedraagt ​​een pre-render zich alsof de pagina is geopend op een onzichtbaar achtergrondtabblad, en wordt vervolgens "geactiveerd" door het voorgrondtabblad te vervangen door die vooraf gerenderde pagina. Als een pagina wordt geactiveerd voordat deze volledig is vooraf weergegeven, wordt de huidige status op de voorgrond gezet en blijft deze laden, wat betekent dat u nog steeds een goede voorsprong kunt nemen.

Omdat de vooraf weergegeven pagina in een verborgen status wordt geopend, worden een aantal API's die opdringerig gedrag veroorzaken (bijvoorbeeld prompts) in deze status niet geactiveerd, maar in plaats daarvan uitgesteld totdat de pagina wordt geactiveerd. In het kleine aantal gevallen waarin dit nog niet mogelijk is, wordt de prerender geannuleerd. Het Chrome-team werkt aan het blootleggen van redenen voor het annuleren van pre-rendering als een API, en verbetert ook de mogelijkheden van DevTools om het identificeren van dergelijke edge-cases eenvoudiger te maken.

Impact van pre-rendering

Met pre-rendering kan de pagina vrijwel onmiddellijk worden geladen, zoals weergegeven in de volgende video:

Voorbeeldimpact van prerendering.

De voorbeeldsite is al een snelle site, maar zelfs hiermee kun je zien hoe prerendering de gebruikerservaring verbetert. Dit kan daarom ook een directe impact hebben op de Core Web Vitals van een site, met bijna nul LCP, verminderde CLS (aangezien elke belasting van CLS plaatsvindt vóór de eerste weergave) en verbeterde INP (aangezien de belasting moet zijn voltooid voordat de gebruiker interactie heeft).

Zelfs wanneer een pagina wordt geactiveerd voordat deze volledig is geladen, zou een voorsprong bij het laden van de pagina de laadervaring moeten verbeteren. Wanneer een link wordt geactiveerd terwijl de pre-rendering nog bezig is, wordt de pre-renderingpagina naar het hoofdframe verplaatst en verder geladen.

Pre-rendering gebruikt echter extra geheugen en netwerkbandbreedte. Zorg ervoor dat u niet te veel pre-rendering uitvoert, wat ten koste gaat van de gebruikersbronnen. Voer alleen een pre-weergave uit als de kans groot is dat naar de pagina wordt genavigeerd.

Zie het gedeelte Prestaties meten voor meer informatie over hoe u de daadwerkelijke prestatie-impact in uw analyses kunt meten.

Bekijk de adresbalkvoorspellingen van Chrome

Voor het eerste gebruik kunt u de voorspellingen van Chrome voor URL's bekijken op de chrome://predictors -pagina:

De Chrome Predictors-pagina is gefilterd om lage (grijs), gemiddelde (amber) en hoge (groene) voorspellingen weer te geven op basis van de ingevoerde tekst.
Chrome Predictors-pagina.

Groene lijnen geven aan dat er voldoende vertrouwen is om pre-rendering te activeren. In dit voorbeeld geeft het typen van "s" een redelijk vertrouwen (oranje), maar zodra u "sh" typt, heeft Chrome voldoende vertrouwen dat u vrijwel altijd naar https://sheets.google.com navigeert.

Deze schermafbeelding is gemaakt tijdens een relatief nieuwe Chrome-installatie en filtert voorspellingen van nul betrouwbaarheid eruit, maar als je je eigen voorspellers bekijkt, zul je waarschijnlijk aanzienlijk meer vermeldingen zien, en mogelijk meer tekens die nodig zijn om een ​​voldoende hoog betrouwbaarheidsniveau te bereiken.

Deze voorspellers zijn ook de drijvende kracht achter de voorgestelde opties in de adresbalk die u wellicht heeft opgemerkt:

De Chrome-adresbalk 'Typeahead'-functie
Adresbalk 'Typeahead'-functie.

Chrome werkt zijn voorspellers voortdurend bij op basis van uw typen en selecties.

  • Voor een betrouwbaarheidsniveau van meer dan 50% (weergegeven in oranje) maakt Chrome proactief vooraf verbinding met het domein, maar geeft de pagina niet vooraf weer.
  • Bij een betrouwbaarheidsniveau van meer dan 80% (groen weergegeven) geeft Chrome de URL vooraf weer.

De Speculatieregels-API

Voor de Prerender-optie Speculation Rules API kunnen webontwikkelaars JSON-instructies op hun pagina's invoegen om de browser te informeren over welke URL's vooraf moeten worden weergegeven:

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

Of door documentregels (beschikbaar vanuit Chrome 121), die links in het document vooraf renderen op basis van href -selectors (gebaseerd op de URL Pattern API ) of CSS-selectors:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

Het Chrome-team heeft een Codelab voor speculatieregels opgesteld waarmee u stapsgewijs wordt begeleid bij het toevoegen van speculatieregels aan een site.

Gretigheid

Browser Support

  • Chroom: 121.
  • Rand: 121.
  • Firefox: niet ondersteund.
  • Safari: niet ondersteund.

Er wordt een eagerness gebruikt om aan te geven wanneer de speculaties moeten vuren, wat vooral handig is voor documentregels:

  • immediate : Dit wordt gebruikt om zo snel mogelijk te speculeren, dat wil zeggen zodra de speculatieregels in acht worden genomen.
  • eager : Dit gedraagt ​​zich 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 de aanwijzer gedurende 200 milliseconden boven een link houdt (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 lichtgewicht, 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 speculatieregel die een link vooraf zou weergeven wanneer de aanwijzer 200 milliseconden boven de link wordt gehouden of tijdens de pointerdown-gebeurtenis als een fundamentele, maar krachtige, implementatie van speculatieregels:

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

Vooraf ophalen

Speculatieregels kunnen ook worden gebruikt om pagina's alleen vooraf op te halen, zonder een volledige pre-render. Dit kan vaak een goede eerste stap zijn op weg naar pre-rendering:

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

Chrome-limieten

Chrome heeft limieten ingesteld om overmatig gebruik van de Speculation Rules API te voorkomen:

gretigheid 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. Een geannuleerde speculatie kan opnieuw worden geactiveerd, bijvoorbeeld door opnieuw over die link te bewegen, wat ertoe zal leiden dat die URL opnieuw wordt gespeculeerd, waardoor de oudste speculatie wordt verdreven. In dit geval zal de eerdere speculatie alle cachebare bronnen in de HTTP-cache voor die URL in de cache hebben opgeslagen, dus nog een keer speculeren zou lagere kosten moeten hebben. Dit is de reden waarom de limiet is ingesteld op de bescheiden drempel van 2. Statische lijstregels worden niet geactiveerd door een gebruikersactie en hebben dus een hogere limiet omdat de browser niet kan weten welke regels nodig zijn en wanneer ze nodig zijn.

De immediate en eager limieten zijn ook dynamisch, dus het verwijderen van een list -URL-scriptelement zal capaciteit creëren door de verwijderde speculaties te annuleren.

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

  • Gegevens opslaan .
  • Energiebesparing indien ingeschakeld en bij lage batterijspanning.
  • 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.

Chrome geeft ook geen cross-origin iframes weer op vooraf weergegeven pagina's totdat deze zijn geactiveerd.

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

Hoe u speculatieregels op een pagina kunt opnemen

Speculatieregels kunnen statisch worden opgenomen in de HTML van de pagina of dynamisch door JavaScript in de pagina worden ingevoegd:

  • Statisch opgenomen speculatieregels : een nieuwsmediasite of een blog kan bijvoorbeeld het nieuwste artikel vooraf weergeven, als dat vaak de volgende navigatie is voor een groot deel van de gebruikers. Als alternatief kunnen documentregels met een moderate of conservative worden gebruikt om te speculeren terwijl gebruikers met links omgaan.
  • Dynamisch ingevoegde speculatieregels : deze kunnen gebaseerd zijn op applicatielogica, gepersonaliseerd voor de gebruiker of gebaseerd op andere heuristieken.

Degenen die de voorkeur geven aan dynamische invoeging op basis van acties zoals er met de muis overheen gaan of op een link klikken (zoals veel bibliotheken in het verleden hebben gedaan met <link rel=prefetch> worden aangeraden om naar documentregels te kijken, omdat deze de browser in staat stellen veel van uw gebruiksscenario's af te handelen.

Speculatieregels kunnen worden toegevoegd in de <head> of de <body> van het hoofdframe. Op speculatieregels in subframes wordt niet gereageerd, en op speculatieregels op vooraf weergegeven pagina's wordt pas actie ondernomen zodra die pagina is geactiveerd.

De Speculation-Rules HTTP-header

Browser Support

  • Chroom: 121.
  • Rand: 121.
  • Firefox: niet ondersteund.
  • Safari: niet ondersteund.

Source

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 ten opzichte van de URL van het JSON-bestand volgens de speculatieregels. Dit kan met name handig zijn als u enkele (of alle) links met dezelfde oorsprong moet selecteren.

Speculatieregels en SPA's

Speculatieregels worden alleen ondersteund voor navigatie op volledige pagina's die door de browser wordt beheerd, en niet voor Single Page Apps (SPA) of app-shellpagina 's. Deze architectuur maakt geen gebruik van documentophaalacties, maar maakt in plaats daarvan API- of gedeeltelijke ophaalacties van gegevens of pagina's, die vervolgens worden verwerkt en gepresenteerd op de huidige pagina. De gegevens die nodig zijn voor deze zogenaamde "zachte navigatie" kunnen door de app vooraf worden opgehaald buiten de speculatieregels om, maar ze kunnen niet vooraf worden weergegeven.

Speculatieregels kunnen worden gebruikt om de applicatie zelf vooraf weer te geven vanaf een vorige pagina. Dit kan een deel van de extra initiële laadkosten die sommige SPA's hebben, helpen compenseren. Routewijzigingen binnen de app kunnen echter niet vooraf worden weergegeven.

Debug speculatieregels

Zie het speciale bericht over het debuggen van speculatieregels voor nieuwe Chrome DevTools-functies om te helpen bij het bekijken en debuggen van deze nieuwe API.

Meerdere speculatieregels

Er kunnen ook meerdere speculatieregels aan dezelfde pagina worden toegevoegd, en deze worden toegevoegd aan de bestaande regels. Daarom resulteren de volgende verschillende manieren allemaal in pre-rendering van zowel one.html als two.html :

Lijst met URL's:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

Meerdere speculationrules -scripts:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Meerdere lijsten binnen één set speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Browser Support

  • Chroom: 127.
  • Rand: 127.
  • Firefox: niet ondersteund.
  • Safari: niet ondersteund.

Source

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 campagnemetingen, maar resulteren meestal 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. Dit wordt ondersteund in Chrome (en op Chromium gebaseerde browsers) voor navigatiespeculaties voor zowel prefetch als prerender.

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 doet, kunt u onnodige downloads verder voorkomen voordat de reacties worden gezien.

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

Je kunt ook meerdere parameters toevoegen aan expects_no_vary_search met een spatie ertussen (aangezien No-Vary-Search een gestructureerde HTTP-header is):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

Speculatieregels beperken beperkingen en toekomstige verbeteringen

Speculatieregels zijn beperkt tot pagina's die op hetzelfde tabblad worden geopend, maar we werken eraan om die beperking te verminderen .

Standaard zijn speculaties beperkt tot pagina's van dezelfde oorsprong. Speculatie op cross-origin-pagina's van dezelfde site ( https://a.example.com kan bijvoorbeeld een pagina op https://b.example.com vooraf weergeven). Om dit te gebruiken moet de gespecificeerde pagina ( https://b.example.com in dit voorbeeld) zich aanmelden door een Supports-Loading-Mode: credentialed-prerender HTTP-header op te nemen, anders annuleert Chrome de speculatie.

Toekomstige versies kunnen pre-rendering ook toestaan ​​voor cross-origin-pagina's die niet dezelfde site zijn, zolang er geen cookies bestaan ​​voor de vooraf weergegeven pagina en de vooraf weergegeven pagina zich aanmeldt met een soortgelijke Supports-Loading-Mode: uncredentialed-prerender HTTP-header.

Speculatieregels ondersteunen al cross-origin-prefetches, maar ook hier alleen als er geen cookies voor het cross-origin-domein bestaan. Als er cookies bestaan ​​van de gebruiker die die site eerder heeft bezocht, wordt de speculatie niet geactiveerd en wordt er een fout in DevTools weergegeven.

Gezien deze huidige beperkingen is een patroon dat uw gebruikerservaringen voor zowel interne links als externe links waar mogelijk kan verbeteren, het vooraf weergeven van URL's van dezelfde oorsprong en het vooraf ophalen van cross-origin URL's:

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

De beperking om cross-origin speculaties voor cross-origin links standaard te voorkomen is noodzakelijk voor de veiligheid. Het is een verbetering ten opzichte van <link rel="prefetch"> voor cross-origin-bestemmingen die ook geen cookies verzenden, maar toch de prefetch proberen - wat zal resulteren in een verspilde prefetch die opnieuw moet worden verzonden of, erger nog, het onjuist laden van de pagina.

Speculatieregels worden niet ondersteund voor prefetch voor pagina's die worden beheerd door servicemedewerkers. We werken eraan om deze ondersteuning toe te voegen. Volg dit probleem met de ondersteuningsservicemedewerker voor updates. Prerender wordt ondersteund voor door servicemedewerkers beheerde pagina's.

Detecteer API-ondersteuning voor speculatieregels

U kunt ondersteuning bieden voor het detecteren van speculatieregels-API met standaard HTML-controles:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

Voeg speculatieregels dynamisch toe via JavaScript

Dit is een voorbeeld van het toevoegen van een prerender -speculatieregel met JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Op deze prerender-demopagina kunt u een demo bekijken van pre-rendering van de Speculation Rules API, met behulp van JavaScript-invoeging.

Als u een <script type = "speculationrules"> element rechtstreeks in de DOM invoegt met behulp van innerHTML , worden de speculatieregels om veiligheidsredenen niet geregistreerd en moet dit worden toegevoegd zoals eerder weergegeven. Inhoud die dynamisch wordt ingevoegd met behulp van innerHTML en die nieuwe links bevat, wordt echter opgepikt door bestaande regels op de pagina.

Op dezelfde manier registreert het rechtstreeks bewerken van het Elementen -paneel in Chrome DevTools om het <script type = "speculationrules"> element toe te voegen de speculatieregels niet en in plaats daarvan moet het script om dit dynamisch toe te voegen aan de DOM worden uitgevoerd vanuit de console om de regels in te voegen.

Voeg speculatieregels toe via een tagmanager

Als u speculatieregels wilt toevoegen met behulp van een tagmanager zoals Google Tag Manager (GTM), moeten deze worden ingevoegd via JavaScript, in plaats van het <script type = "speculationrules"> element rechtstreeks via GTM toe te voegen, om dezelfde redenen als eerder vermeld:

Aangepaste HTML-tagconfiguratie in Google Tag Manager
Speculatieregels toevoegen via Google Tag Manager.

Let op: in dit voorbeeld wordt var gebruikt, omdat GTM const niet ondersteunt.

Annuleer speculatieregels

Het verwijderen van speculatieregels zal ertoe leiden dat de pre-render wordt geannuleerd, maar tegen de tijd dat dit is gebeurd, zullen de middelen waarschijnlijk al zijn besteed om de pre-render te initiëren. Het wordt dus aanbevolen om niet vooraf te renderen als de kans groot is dat de pre-render moet worden geannuleerd.

Speculatieregels en inhoudbeveiligingsbeleid

Omdat speculatieregels een <script> -element gebruiken, ook al bevatten ze alleen JSON, moeten ze worden opgenomen in het script-src Content-Security-Policy als de site dit gebruikt, met behulp van een hash of nonce.

Er kunnen nieuwe inline-speculation-rules worden toegevoegd aan script-src waardoor <script type="speculationrules"> elementen die zijn geïnjecteerd vanuit hash- of nonced-scripts worden ondersteund. Dit ondersteunt geen regels die zijn opgenomen in de initiële HTML, dus regels moeten door JavaScript worden geïnjecteerd voor sites die een strikte CSP gebruiken.

Detecteer en schakel pre-rendering uit

Prerender is doorgaans een positieve ervaring voor gebruikers, omdat het een snelle weergave van pagina's mogelijk maakt, vaak direct. Dit komt zowel de gebruiker als de site-eigenaar ten goede, aangezien vooraf weergegeven pagina's een betere gebruikerservaring mogelijk maken die anders moeilijk te bereiken zou zijn.

Er kunnen echter gevallen zijn waarin u niet wilt dat pagina's vooraf worden weergegeven , bijvoorbeeld wanneer pagina's van status veranderen, hetzij op basis van het initiële verzoek, hetzij op basis van de uitvoering van JavaScript op de pagina.

Schakel pre-rendering in Chrome in en uit

Prerender is alleen ingeschakeld voor Chrome-gebruikers met de instelling 'Pagina's vooraf laden' in chrome://settings/performance/ . Bovendien is prerender ook uitgeschakeld op apparaten met weinig geheugen of als het besturingssysteem in de modus Gegevens opslaan of Energiebesparing staat. Zie het gedeelte Chrome-limieten .

Detecteer en schakel pre-rendering aan de serverzijde uit

Vooraf gegenereerde pagina's worden verzonden met de Sec-Purpose HTTP-header:

Sec-Purpose: prefetch;prerender

Voor vooraf opgehaalde pagina's die de Speculation Rules API gebruiken, is deze header ingesteld op alleen prefetch :

Sec-Purpose: prefetch

Servers kunnen reageren op basis van deze header, speculatieverzoeken registreren, andere inhoud retourneren of voorkomen dat er een pre-render plaatsvindt. Als er een definitieve responscode zonder resultaat wordt geretourneerd (dat wil zeggen, niet in het bereik 200-299 na omleidingen), wordt de pagina niet vooraf weergegeven en wordt elke prefetch-pagina verwijderd. Houd er ook rekening mee dat de antwoorden 204 en 205 bovendien niet geldig zijn voor prerendering , maar wel voor prefetch.

Als u niet wilt dat een bepaalde pagina vooraf wordt weergegeven, is het retourneren van een niet-2XX-antwoordcode (zoals 503) de beste manier om ervoor te zorgen dat dit niet gebeurt. Om de beste ervaring te bieden, wordt echter aanbevolen om in plaats daarvan pre-rendering toe te staan, maar alle acties uit te stellen die pas zouden moeten plaatsvinden als de pagina daadwerkelijk wordt bekeken, met behulp van JavaScript.

Detecteer pre-rendering in JavaScript

De document.prerendering API retourneert true terwijl de pagina vooraf wordt weergegeven. Dit kan door pagina's worden gebruikt om bepaalde activiteiten tijdens de pre-renderering te voorkomen (of uit te stellen) totdat de pagina daadwerkelijk wordt geactiveerd.

Zodra een vooraf gerenderd document is geactiveerd, wordt activationStart van PerformanceNavigationTiming ook ingesteld op een tijd die niet nul is en die de tijd vertegenwoordigt tussen het moment waarop de pre-render werd gestart en het document daadwerkelijk werd geactiveerd.

U kunt een functie hebben om te controleren op vooraf weergegeven en vooraf weergegeven pagina's, zoals de volgende:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

De eenvoudigste manier om te zien of een pagina vooraf is weergegeven (geheel of gedeeltelijk) is door DevTools te openen nadat de pagina is geactiveerd en performance.getEntriesByType('navigation')[0].activationStart in de console te typen. Als er een waarde anders dan nul wordt geretourneerd, weet u dat de pagina vooraf is weergegeven:

Console in Chrome DevTools toont een positieve activatieStart, wat aangeeft dat de pagina vooraf is weergegeven
Pre-rendering testen in de console.

Wanneer de pagina wordt geactiveerd door de gebruiker die de pagina bekijkt, wordt de prerenderingchange gebeurtenis op het document verzonden, die vervolgens kan worden gebruikt om activiteiten in te schakelen die voorheen standaard zouden worden gestart bij het laden van de pagina, maar die u wilt uitstellen totdat de pagina daadwerkelijk door de gebruiker wordt bekeken.

Met behulp van deze API's kan frontend JavaScript vooraf weergegeven pagina's detecteren en er op de juiste manier op reageren.

Impact op analyses

Analytics wordt gebruikt om het websitegebruik te meten, bijvoorbeeld met behulp van Google Analytics om paginaweergaven en gebeurtenissen te meten. Of door prestatiestatistieken van pagina's te meten met behulp van Real User Monitoring (RUM) .

Pagina's mogen alleen vooraf worden weergegeven als de kans groot is dat de pagina door de gebruiker wordt geladen. Dit is de reden waarom de opties voor pre-rendering van de Chrome-adresbalk alleen plaatsvinden als de waarschijnlijkheid zo groot is (meer dan 80% van de tijd).

Maar vooral bij het gebruik van de Speculation Rules API kunnen vooraf weergegeven pagina's invloed hebben op de analyses en site-eigenaren moeten mogelijk extra code toevoegen om alleen analyses voor vooraf weergegeven pagina's in te schakelen bij activering, aangezien niet alle analyseproviders dit standaard doen.

Dit kan worden bereikt door een Promise te gebruiken die wacht op de prerenderingchange -gebeurtenis als een document vooraf wordt weergegeven, of onmiddellijk wordt opgelost als dit nu het geval is:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Een alternatieve benadering is om analytische activiteiten uit te stellen totdat de pagina voor het eerst zichtbaar wordt gemaakt, wat zowel het geval van pre-rendering zou omvatten als ook wanneer tabbladen op de achtergrond worden geopend (bijvoorbeeld door met de rechtermuisknop te klikken en in een nieuw tabblad te openen):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

Hoewel dit zinvol kan zijn voor analyses en soortgelijke gebruiksscenario's, wil je in andere gevallen misschien meer inhoud laden voor die gevallen, en wil je dus document.prerendering en prerenderingchange gebruiken om specifiek prerenderingpagina's te targeten.

Houd andere inhoud tegen tijdens pre-rendering

Dezelfde API's die eerder zijn besproken, kunnen worden gebruikt om andere inhoud tegen te houden tijdens de pre-renderfase. Dit kunnen specifieke delen van JavaScript zijn of hele scriptelementen die u liever niet uitvoert tijdens de prerenderfase.

Gegeven dit script bijvoorbeeld:

<script src="https://example.com/app/script.js" async></script>

U kunt dit wijzigen in een dynamisch ingevoegd scriptelement dat alleen wordt ingevoegd op basis van de vorige whenActivated -functie:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Dit kan handig zijn om afzonderlijke scripts tegen te houden die analyses bevatten, of om inhoud weer te geven op basis van de status of andere variabelen die tijdens een bezoek kunnen veranderen. Aanbevelingen, inlogstatus of winkelmandjepictogrammen kunnen bijvoorbeeld allemaal worden achtergehouden om ervoor te zorgen dat de meest actuele informatie wordt weergegeven.

Hoewel de kans groter is dat dit vaker zal gebeuren bij het gebruik van prerendering, gelden deze voorwaarden ook voor pagina's die zijn geladen in de eerder genoemde achtergrondtabbladen (dus de functie whenFirstVisible zou kunnen worden gebruikt in plaats van whenActivated ).

In veel gevallen zou de status idealiter ook gecontroleerd moeten worden op algemene wijzigingen visibilitychange . Wanneer u bijvoorbeeld terugkeert naar een pagina die op de achtergrond staat, moeten alle winkelmandjestellers worden bijgewerkt met het laatste aantal artikelen in het winkelmandje. Dit is dus geen prerender-specifiek probleem, maar prerender maakt alleen maar een bestaand probleem duidelijker.

Eén manier waarop Chrome een deel van de noodzaak voor het handmatig inpakken van scripts of functies vermindert, is dat bepaalde API's worden tegengehouden zoals eerder vermeld , en dat ook iframes van derden niet worden weergegeven, dus alleen de inhoud daar bovenop moet handmatig worden tegengehouden.

Meet de prestaties

Voor het meten van prestatiestatistieken moeten analyses overwegen of het beter is om deze te meten op basis van de activeringstijd in plaats van de laadtijd van de pagina die browser-API's zullen rapporteren.

Voor Core Web Vitals, gemeten door Chrome via het Chrome User Experience Report , zijn deze bedoeld om de gebruikerservaring te meten. Deze worden dus gemeten op basis van activeringstijd. Dit resulteert bijvoorbeeld vaak in een LCP van 0 seconden, wat aantoont dat dit een geweldige manier is om uw Core Web Vitals te verbeteren.

Vanaf versie 3.1.0 is de web-vitals bibliotheek bijgewerkt om vooraf gegenereerde navigatie op dezelfde manier te verwerken als Chrome Core Web Vitals meet. Deze versie markeert ook vooraf weergegeven navigatie voor die statistieken in het kenmerk Metric.navigationType als de pagina geheel of gedeeltelijk vooraf is weergegeven.

Pre-renders meten

Of een pagina vooraf wordt weergegeven, kunt u zien met een niet-nul activationStart invoer van PerformanceNavigationTiming . Dit kan vervolgens worden geregistreerd met behulp van een aangepaste dimensie of iets dergelijks bij het loggen van de paginaweergaven, bijvoorbeeld met behulp van de eerder beschreven pagePrerendered functie :

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

Hierdoor kunnen uw analyses laten zien hoeveel navigatie vooraf wordt weergegeven in vergelijking met andere typen navigatie, en kunt u ook prestatiestatistieken of bedrijfsstatistieken aan deze verschillende navigatietypen koppelen. Snellere pagina's zorgen voor gelukkigere gebruikers, wat vaak een echte impact kan hebben op zakelijke maatregelen, zoals blijkt uit onze casestudies .

Terwijl u de zakelijke impact meet van het vooraf weergeven van pagina's voor directe navigatie, kunt u beslissen of het de moeite waard is om meer moeite te investeren in het gebruik van deze technologie om meer navigatie vooraf weer te geven, of om te onderzoeken waarom pagina's niet vooraf worden weergegeven.

Meet hitpercentages

Naast het meten van de impact van pagina's die na een pre-rendering worden bezocht, is het ook belangrijk om pagina's te meten die wel worden pre-rendered en vervolgens niet worden bezocht. Dit kan impliceren dat u te veel voorkomt en waardevolle bronnen van de gebruiker gebruikt voor weinig voordeel.

Dit kan worden gemeten door een analysegebeurtenis af te vuren wanneer speculatieregels worden ingevoegd - na het controleren van de browser ondersteunt voor- met behulp van HTMLScriptElement.supports('speculationrules') - om aan te geven dat PRERENDER werd aangevraagd. (Merk op dat alleen omdat een voor- gevraagde voor- wordt gevraagd, niet aangeven dat een voor- is gestart of voltooid zoals, zoals eerder opgemerkt, een voor- hint is voor de browser en het kan ervoor kiezen om geen voorpagina's op gebruikersinstellingen, huidige geheugengebruik of andere heuristieken te geven.)

U kunt vervolgens het aantal van deze gebeurtenissen vergelijken met de werkelijke PRERENDER -paginaweergaven. Of vuur een andere gebeurtenis op activering als dat het gemakkelijker maakt om te vergelijken.

De "succesvolle hitsnelheid" kan vervolgens worden benaderd door te kijken naar het verschil tussen deze twee cijfers. Voor pagina's waar u de speculatieregels API gebruikt om de pagina's voor te doen, kunt u de regels op de juiste manier aanpassen om ervoor te zorgen dat u een hoog hit -tarief behoudt om de balans te behouden tussen het gebruik van de gebruikersbronnen om hen te helpen, versus het onnodig gebruiken.

Houd er rekening mee dat er wat voorrechten kunnen plaatsvinden vanwege de voor- en niet alleen uw speculatieregels. U kunt het document.referrer controleren. Referrer (die leeg is voor adresbarsnavigatie inclusief PRerendered Adres Bar Navigations) als u deze wilt onderscheiden.

Vergeet niet om ook te kijken naar pagina's die geen voor- hebben, omdat dat zou kunnen aangeven dat deze pagina's niet in aanmerking komen voor voor-, zelfs uit de adresbalk. Dat kan betekenen dat u niet profiteert van deze prestatieverbetering. Het Chrome -team wil extra gereedschap toevoegen om te testen op voorliggende in aanmerking komende om mogelijk vergelijkbaar met de BFCache -testtool , en mogelijk ook een API toe te voegen om bloot te stellen waarom een ​​voor- faalde.

Impact op extensies

Zie het speciale bericht over Chrome Extensions: Uitbreiding van API ter ondersteuning van directe navigatie waarin enkele aanvullende overwegingen -extensie -auteurs mogelijk moeten nadenken voor voorgestelde pagina's.

Feedback

PRERENDING is in actieve ontwikkeling door het Chrome -team en er zijn tal van plannen om de reikwijdte uit te breiden van wat er beschikbaar is gesteld in de Chrome 108 -release. We verwelkomen alle feedback op de GitHub -repo of het gebruik van onze nummer Tracker en kijken uit naar het horen en delen van casestudy's van deze opwindende nieuwe API.

Dankbetuigingen

Miniatuurafbeelding door Marc-Olivier Jodoin op Unsplash

,

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox: niet ondersteund.
  • Safari: niet ondersteund.

Source

Het Chrome -team heeft volledig voorgesteld aan toekomstige pagina's teruggebracht waar een gebruiker waarschijnlijk naar zal navigeren.

Een korte geschiedenis van PRERENDER

In het verleden ondersteunde Chrome de <link rel="prerender" href="/next-page"> Hint, maar deze werd niet in grote lijnen ondersteund voorbij Chrome, en het was geen zeer expressieve API.

Deze legacy -voorkeur met behulp van de link rel=prerender hint werd verouderd ten gunste van nostate prefetch , die in plaats daarvan de middelen opleverde die nodig zijn door de toekomstige pagina, maar de pagina niet volledig voorzag of JavaScript niet volledig heeft uitgevoerd. Nostate prefetch helpt de paginaprestaties te verbeteren door de laden van middelen te verbeteren, maar levert geen directe pagina -lading op zoals een volledige voor- voorpers.

Het Chrome -team heeft nu volledige voor- in Chrome opnieuw geïntroduceerd. Om complicaties met bestaand gebruik te voorkomen, en om toekomstige uitbreiding van het voorligging mogelijk te maken, zal dit nieuwe PRERENDER -mechanisme de <link rel="prerender"...> Syntaxis niet gebruiken, die aanwezig blijft voor nostaatpretcher, met het oog op een bepaald punt in de toekomst.

Hoe wordt een pagina voorgesteld?

Een pagina kan worden voorgesteld op een van de vier manieren, die allemaal streven om navigaties sneller te maken:

  1. Wanneer u een URL typt in de Chrome -adresbalk (ook bekend als "de omnibox"), kan Chrome de pagina automatisch voor u voor u voordelen, als deze een hoog vertrouwen heeft, bezoekt u die pagina, op basis van uw eerdere browsegeschiedenis.
  2. Wanneer u de Bladmarks -balk gebruikt, kan Chrome de pagina automatisch voor u voor het vasthouden van de aanwijzer over een van de bladwijzerknoppen.
  3. Wanneer u een zoekterm in de Chrome -adresbalk typt, kan Chrome automatisch de pagina met zoekresultaten voorstellen, wanneer deze wordt geïnstrueerd om dit door de zoekmachine te doen.
  4. Sites kunnen de speculatieregels API gebruiken om Chrome programmatisch te vertellen welke pagina's voor Persender zijn. Dit vervangt wat <link rel="prerender"...> gebruikt om te doen en stelt sites in staat om proactief een pagina op te stellen op basis van speculatieregels op de pagina. Deze kunnen statisch op de pagina's bestaan, of dynamisch worden geïnjecteerd door JavaScript als de pagina -eigenaar dat nodig is.

In elk van deze gevallen gedraagt ​​een voor- gedraagt ​​zich alsof de pagina is geopend op een onzichtbaar achtergrondtabblad en wordt vervolgens "geactiveerd" door het tabblad voor de voorgrond te vervangen door die voorpagina. Als een pagina wordt geactiveerd voordat deze volledig is voorgesteld, is de huidige status "voorgrond" en blijft het laden, wat betekent dat u nog steeds een goede voorsprong kunt krijgen.

Aangezien de voorgestelde pagina in een verborgen toestand wordt geopend, worden een aantal API's die opdringerig gedrag veroorzaken (bijvoorbeeld prompts) niet geactiveerd in deze status en worden ze in plaats daarvan vertraagd totdat de pagina is geactiveerd. In het kleine aantal gevallen waarin dit nog niet mogelijk is, wordt de voor- geannuleerd. Het Chrome -team werkt aan het blootstellen van de annuleringsredenen van PRERENDER als API, en ook het verbeteren van Devtools -mogelijkheden om dergelijke randgevallen gemakkelijker te maken.

Impact van voor-

PRERENDING maakt een bijna-instant pagina-laad mogelijk zoals weergegeven in de volgende video:

Voorbeeld Impact van voor-.

De voorbeeldsite is al een snelle site, maar zelfs hiermee kunt u zien hoe PRERENDING de gebruikerservaring verbetert. Dit kan daarom ook een directe impact hebben op de kernwebvitalen van een site, met bijna nul LCP, verminderde CLS (omdat CL's voor loads plaatsvinden vóór de eerste weergave) en verbeterde INP (omdat de belasting moet worden voltooid voordat de gebruiker op interactie gaat).

Zelfs wanneer een pagina wordt geactiveerd voordat deze volledig wordt geladen, moet een voorsprong op de pagina -laad van de pagina de laadervaring verbeteren. Wanneer een link wordt geactiveerd terwijl er nog steeds voor wordt plaatsgevonden, gaat de voorliggende pagina naar het hoofdframe en blijft het laden.

PRERENINGING gebruikt echter extra geheugen- en netwerkbandbreedte. Pas op dat u niet te veel voorkomt, tegen een kostprijs van gebruikersbronnen. Alleen PRerender wanneer er een grote kans is dat de pagina wordt genavigeerd.

Zie de sectie Meetprestaties voor meer informatie over het meten van de werkelijke prestatie -impact in uw analyses.

Bekijk de Address Bar -voorspellingen van Chrome

Voor de eerste use case kunt u de voorspellingen van Chrome voor URL's bekijken in de pagina chrome://predictors :

De Chrome -voorspellerspagina gefilterd om lage (grijs), medium (barnsteen) en hoge (groene) voorspellingen weer te geven op basis van de ingevoerde tekst.
Chrome voorspellerspagina.

Groene lijnen duiden op voldoende vertrouwen aan om voor- te activeren. In dit voorbeeld geeft het typen van "S" een redelijk vertrouwen (Amber), maar zodra je "SH" typt, dan heeft Chrome genoeg vertrouwen dat je bijna altijd naar https://sheets.google.com navigeert.

Deze screenshot is gemaakt in een relatief frisse chroominstallatie en het filteren van nul betrouwbaarheidsvoorspellingen, maar als u uw eigen voorspellers bekijkt, ziet u waarschijnlijk aanzienlijk meer inzendingen, en mogelijk meer karakters die nodig zijn om een ​​hoog genoeg betrouwbaarheidsniveau te bereiken.

Deze voorspellers zijn ook welke drive de adresbalk voorgestelde opties die u mogelijk heeft opgemerkt:

De functie 'TypEahead' van de Chrome -adresbalk
Adresbalk 'TypEahead' functie.

Chrome zal zijn voorspellers voortdurend bijwerken op basis van uw typen en selecties.

  • Voor een betrouwbaarheidsniveau van meer dan 50% (in Amber), gaat Chrome proactief vooraf aan het domein, maar maakt de pagina niet voor.
  • Voor een betrouwbaarheidsniveau van meer dan 80% (in groen weergegeven), zal Chrome de URL voorleggen.

De speculatie regeert API

Voor de speculatieregels API PRERENDER -optie kunnen webontwikkelaars JSON -instructies in hun pagina's invoegen om de browser te informeren over welke URL's voor Persender:

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

Of door documentregels (beschikbaar bij Chrome 121), welke PRERENDERS -links in het document worden gevonden op basis van href -selectors (op basis van de URL -patroon API ) of CSS -selectors:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

Het Chrome -team heeft een speculatieregelscodelab opgesteld die u door speculatieregels aan een site toe te voegen.

Gretigheid

Browser Support

  • Chroom: 121.
  • Rand: 121.
  • Firefox: niet ondersteund.
  • Safari: niet ondersteund.

Een eagerness wordt gebruikt om aan te geven wanneer de speculaties moeten ontslaan, wat met name nuttig is voor documentregels:

  • immediate : dit wordt gebruikt om zo snel mogelijk te speculeren, dat wil zeggen zodra de speculatieregels worden waargenomen.
  • eager : dit gedraagt ​​zich 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 de aanwijzer vasthoudt over een link voor 200 milliseconden (of op de pointerdown -gebeurtenis als dat eerder is, en op mobiel waar er 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 lichtgewicht, statische site, kan speculeren meer gretig weinig kosten hebben en nuttig 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 speculatieregel die een link zou voordoen bij het vasthouden van de aanwijzer voor de link voor 200 milliseconden of op de aanwijzer als een basis - ja krachtig - implementatie van speculatieregels:

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

Prefeteren

Speculatieregels kunnen ook worden gebruikt om alleen pagina's te prefeteren, zonder een volledige voor-. Dit kan vaak een goede eerste stap zijn op weg naar het voor-:

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

Chrome limieten

Chrome heeft limieten om overmatig gebruik van de speculatieregels API te voorkomen:

gretigheid Prefeteren Voor-
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 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. Een geannuleerde speculatie kan opnieuw worden geactiveerd-bijvoorbeeld door die link opnieuw te zweven-waardoor die URL opnieuw wordt gespeculeerd, waardoor de oudste speculatie wordt uitgedrukt. In dit geval zal de vorige speculatie eventuele in de cache in de http -cache worden opgeslagen voor die URL, zodat speculatie een verdere tijd een lagere kosten zou moeten hebben. Dit is de reden waarom de limiet is ingesteld op de bescheiden drempel van 2. Statische lijstregels 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.

De immediate en eager limieten zijn ook dynamisch, dus het verwijderen van een list -URL -scriptelement maakt capaciteit door die verwijderde speculaties te annuleren.

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

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

Chrome maakt ook geen cross-origin iframes op voorgestelde pagina's tot activering.

Al deze voorwaarden zijn bedoeld om de impact van over-speculatie te verminderen wanneer het schadelijk zou zijn voor gebruikers.

Hoe speculatieregels op een pagina op te nemen

Speculatieregels kunnen statisch worden opgenomen in de HTML van de pagina of dynamisch in de pagina worden ingevoegd door JavaScript:

  • Statisch opgenomen speculatieregels : bijvoorbeeld een nieuwsmediasite, of een blog kan bijvoorbeeld het nieuwste artikel voornemen, als dat vaak de volgende navigatie is voor een groot deel van de gebruikers, als alternatief, kan regels met een moderate of conservative kunnen worden gebruikt om te speculeren als gebruikers die met links communiceren.
  • Dynamisch ingevoegde speculatieregels : dit kan gebaseerd zijn op applicatielogica, gepersonaliseerd voor de gebruiker of gebaseerd op andere heuristieken.

Degenen die de voorkeur geven aan dynamische insertie op basis van acties zoals het zweven of klikken op een link - zoals veel bibliotheken in het verleden hebben gedaan met <link rel=prefetch> - worden aanbevolen om naar documentregels te kijken, omdat deze de browser in staat stellen veel van uw use cases te verwerken.

Speculatieregels kunnen worden toegevoegd in de <head> of de <body> van in het hoofdframe. Er worden geen speculatieregels in subframes gehandeld en speculatieregels in voorgestelde pagina's worden pas opgevoerd zodra die pagina is geactiveerd.

De Speculation-Rules HTTP-header

Browser Support

  • Chroom: 121.
  • Rand: 121.
  • Firefox: niet ondersteund.
  • Safari: niet ondersteund.

Source

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 zullen relatieve URL's relatief zijn ten opzichte van de URL van het speculatieregels JSON -bestand. Dit kan met name handig zijn als u sommige-of alle-Same-Origin-links moet selecteren.

Speculatieregels en spa's

Speculatieregels worden alleen ondersteund voor volledige pagina -navigaties beheerd door de browser, en niet voor apps voor één pagina (SPA) of app -shell -pagina's. Deze architectuur gebruiken geen documenthallen, maar maken in plaats daarvan API of gedeeltelijke ophalen van gegevens of pagina's - die vervolgens worden verwerkt en gepresenteerd op de huidige pagina. De gegevens die nodig zijn voor deze zogenaamde "zachte navigaties" kunnen door de app buiten speculatieregels worden vooraf bepaald, maar ze kunnen niet worden voorgesteld.

Speculatieregels kunnen worden gebruikt om de applicatie zelf van een vorige pagina voor te stellen. Dit kan helpen bij het compenseren van een deel van de extra initiële belastingkosten die sommige spa's hebben. Routeveranderingen binnen de app kunnen echter niet worden voorgesteld.

Debug -speculatieregels

Zie de speciale post over Debugging Speculation Rules , voor nieuwe Chrome Devtools -functies om te helpen bij het bekijken en debuggen van deze nieuwe API.

Meerdere speculatieregels

Meerdere speculatieregels kunnen ook aan dezelfde pagina worden toegevoegd en ze voegen toe aan de bestaande regels. Daarom resulteren de volgende verschillende manieren allemaal in zowel one.html als two.html voor-:

Lijst met URL's:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

Meerdere speculationrules scripts:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Meerdere lijsten binnen één set speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Browser Support

  • Chrome: 127.
  • Edge: 127.
  • Firefox: niet ondersteund.
  • Safari: niet ondersteund.

Source

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 van 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 voor de geleverde bron en daarom een ​​browser toestaan ​​eerder in de cache-versies van een document te hergebruiken dat alleen door deze parameters verschilt. Dit wordt ondersteund in chroom (en op chroom gebaseerde browsers) voor navigatiespeculaties voor zowel prefetch als preerender.

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 voordat de antwoorden worden gezien.

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

U kunt ook meerdere parameters toevoegen aan expects_no_vary_search met een ruimte die deze scheidt (omdat No-Vary-Search een HTTP-gestructureerde header is):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

Speculatieregelsbeperkingen en toekomstige verbeteringen

Speculatieregels zijn beperkt tot pagina's die binnen hetzelfde tabblad worden geopend, maar we werken aan het verminderen van die beperking .

Standaard zijn speculaties beperkt tot pagina's met hetzelfde origin. Speculatie op dezelfde locatie cross-origin-pagina's (bijvoorbeeld https://a.example.com kan een pagina op https://b.example.com ). Om dit te gebruiken, moet de gespeculeerde pagina ( https://b.example.com in dit voorbeeld) u opmelden door een Supports-Loading-Mode: credentialed-prerender HTTP-header of Chrome zal de speculatie annuleren.

Toekomstige versies kunnen ook Persender toestaan ​​voor niet-samet-site, cross-origin pagina's zolang cookies niet bestaan ​​voor de voorgestelde pagina en de PRERENDERED-pagina kiest in met een vergelijkbare Supports-Loading-Mode: uncredentialed-prerender HTTP-header.

Speculatieregels ondersteunen al de prefetches van cross-origin, maar nogmaals, maar opnieuw wanneer cookies voor het cross-origin-domein niet bestaan. Als cookies bestaan ​​van de gebruiker die die site eerder hebben bezocht, wordt de speculatie niet geactiveerd en toont het een mislukking in Devtools.

Gezien die huidige beperkingen, is een patroon dat de ervaringen van uw gebruikers voor zowel interne links als externe links kan verbeteren waar mogelijk voor het voor- en proberen van hetzelfde-origin-URL's te preFetsen:

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

De beperking om cross-originspeculaties voor cross-origin-links te voorkomen, is standaard nodig voor beveiliging. Het is een verbetering ten opzichte van <link rel="prefetch"> voor cross-origin bestemmingen die ook geen cookies zullen verzenden maar nog steeds de prefetch proberen-die ofwel zal resulteren in een verspilde prefetch die moet worden hersteld of, erger nog, de onjuiste pagina laadt.

Speculatieregels worden niet ondersteund voor prefetch voor pagina's die worden bestuurd door servicemedewerkers. We werken aan het toevoegen van deze ondersteuning. Volg dit probleem van de ondersteuningsmedewerker voor updates. PRERENDER wordt ondersteund voor pagina's met servicemedewerker.

Detecteer speculatieregels API -ondersteuning

U kunt speculatieregels API -ondersteuning detecteren met standaard HTML -controles:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

Voeg speculatieregels dynamisch toe via JavaScript

Dit is een voorbeeld van het toevoegen van een prerender -speculatieregel met JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

U kunt een demo van speculatieregels API -PRERENDING bekijken, met behulp van JavaScript -invoeging, op deze demo -pagina van PRERENDER .

Het invoegen van een <script type = "speculationrules"> Element rechtstreeks in de DOM met behulp van innerHTML registreert de speculatieregels niet om veiligheidsredenen en dit moet worden toegevoegd zoals eerder getoond. Inhoud wordt echter dynamisch ingevoegd met behulp van innerHTML die nieuwe links bevat, wordt opgehaald door bestaande regels op de pagina.

Evenzo registreert directe bewerking van het elementenpaneel in Chrome Devtools om het <script type = "speculationrules"> Element toe te voegen niet de speculatieregels en in plaats daarvan moet het script dit dynamisch toevoegen aan de DOM worden uitgevoerd vanuit de console om de regels in te voegen.

Voeg speculatieregels toe via een Tag Manager

Om speculatieregels toe te voegen met behulp van een tagbeheerder zoals Google Tag Manager (GTM) vereist dat deze worden ingevoegd via JavaScript, in plaats van het <script type = "speculationrules"> element toe te voegen, hoewel GTM direct om dezelfde redenen als eerder vermeld:

Aangepaste HTML -tagconfiguratie in Google Tag Manager
Speculatieregels toevoegen via Google Tag Manager.

Opmerking Dit voorbeeld gebruikt var als GTM ondersteunt niet const .

Annuleer speculatieregels

Het verwijderen van speculatieregels zullen ertoe leiden dat de voor- wordt geannuleerd, maar tegen de tijd dat dit is gebeurd, zullen er waarschijnlijk al middelen zijn besteed om de PRERENDER te initiëren, dus het wordt aanbevolen om geen Persender te hebben als er een kans is om de voor- te annuleren.

Speculatieregels en beleid voor contentbeveiliging

Aangezien speculatieregels een <script> -element gebruiken, hoewel ze alleen JSON bevatten, moeten ze worden opgenomen in het script-src content-security-beleid als de site dit gebruikt-hetzij met behulp van een hash of nonce.

Een nieuwe inline-speculation-rules kunnen worden toegevoegd aan script-src waardoor <script type="speculationrules"> elementen die zijn geïnjecteerd bij hash of niet-gecontineerde scripts kunnen worden ondersteund. Dit ondersteunt geen regels in de eerste HTML, dus regels moeten door JavaScript worden geïnjecteerd voor sites die een strikte CSP gebruiken.

Voor- en uitschakelen van voor-

PRERENDER is meestal een positieve ervaring voor gebruikers, omdat het een snelle pagina -weergave mogelijk maakt - vaak onmiddellijk. Dit komt zowel de gebruiker als de eigenaar van de site ten goede, omdat voorgestelde pagina's een betere gebruikerservaring toestaan ​​die anders misschien moeilijk te bereiken is.

Er kunnen echter gevallen zijn waarin u niet wilt dat pagina's van pagina's plaatsvinden , bijvoorbeeld wanneer pagina's van status veranderen - op basis van het eerste verzoek, of op basis van JavaScript die op de pagina wordt uitgevoerd.

Schakel Persender in Chrome in en schakel

PRERENDER is alleen ingeschakeld voor die Chrome -gebruikers met de instelling "Voorlaadpagina's" in chrome://settings/performance/ . Bovendien is Persender ook uitgeschakeld op apparaten met lage geheugen, of als het besturingssysteem zich in save-gegevens of energiebesparende modi bevindt. Zie het gedeelte Chrome Limits .

Detecteer en schakel PRERENDER-server-side uit

PRerendered Pages worden verzonden met de Sec-Purpose HTTP-header:

Sec-Purpose: prefetch;prerender

Voorgelicht pagina's met behulp van de speculatieregels API zal deze koptekst ingesteld hebben om gewoon te prefetch :

Sec-Purpose: prefetch

Servers kunnen reageren op basis van deze koptekst, om speculatieverzoeken te loggen, verschillende inhoud retourneren of voorkomen dat een voorwijks plaatsvindt. Als een niet-succescode wordt geretourneerd-dat wil zeggen niet in het bereik van 200-299 na omleidingen-dan wordt de pagina niet voorgesteld en wordt elke prefetch-pagina weggegooid. Merk ook op dat 204 en 205 antwoorden bovendien niet geldig zijn voor voor- , maar geldig zijn voor prefetch.

Als u niet wilt dat een bepaalde pagina wordt voorgesteld, is het retourneren van een niet-2xx-antwoordcode (zoals 503) de beste manier om ervoor te zorgen dat deze niet zal gebeuren. Om de beste ervaring te leveren, wordt het echter aanbevolen om in plaats daarvan voorop te staan, maar alle acties uit te stellen die alleen zouden moeten gebeuren, wordt de pagina daadwerkelijk bekeken, met behulp van JavaScript.

Detecteer PRerender in JavaScript

Het document.prerendering API zal true retourneren terwijl de pagina voorkomt. Dit kan per pagina worden gebruikt om te voorkomen - of vertraging - activiteiten tijdens de voorliggender te voorkomen totdat de pagina daadwerkelijk is geactiveerd.

Zodra een door een voorgestelde document is geactiveerd, wordt activationStart van PerformanceNavigationTiming ook ingesteld op een niet-nul-tijd die de tijd weergeeft tussen wanneer de voor- werd gestart en het document daadwerkelijk werd geactiveerd.

U kunt een functie hebben om te controleren op voorliggende en voorgestelde pagina's zoals de volgende:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

De eenvoudigste manier om te zien of een pagina werd voorgesteld (volledig of gedeeltelijk) is om devTools te openen nadat de pagina is geactiveerd en performance.getEntriesByType('navigation')[0].activationStart in de console. Als een niet-nul-waarde wordt geretourneerd, weet u dat de pagina is voorgesteld:

Console in Chrome Devtools die een positieve activeringstart toont die aangeeft dat de pagina werd voorgelegd
PRerender testen in de console.

Wanneer de pagina wordt geactiveerd door de gebruiker die de pagina bekijkt, wordt de prerenderingchange -gebeurtenis op het document verzonden, die vervolgens kan worden gebruikt om activiteiten in te schakelen die eerder standaard worden gestart op het laden van de pagina, maar die u wilt uitstellen totdat de pagina daadwerkelijk door de gebruiker wordt bekeken.

Met behulp van deze API's kan frontend JavaScript op de juiste manier worden gedetecteerd en op voorliggende pagina's kunnen handelen.

Impact op analyse

Analytics worden gebruikt om het gebruik van het websites te meten, bijvoorbeeld met behulp van Google Analytics om paginaviews en evenementen te meten. Of door het meten van prestatiestatistieken van pagina's met behulp van echte gebruikersbewaking (rum) .

Pagina's mogen alleen worden voorgesteld als er een grote kans is dat de pagina door de gebruiker wordt geladen. Dit is de reden waarom de vooraanstaande opties van Chrome -adresbalk alleen plaatsvinden als er zo'n grote kans is (meer dan 80% van de tijd).

- met name bij het gebruik van de speculatieregels API - kunnen voorgestelde pagina's een impact hebben op analyses en site -eigenaren moeten mogelijk extra code toevoegen om alleen analyses voor voorgestelde pagina's over activering in te schakelen, omdat niet alle analyseproviders dit standaard kunnen doen.

Dit zou kunnen worden bereikt door een Promise te gebruiken die wacht op de gebeurtenis prerenderingchange als een document voorziet, of onmiddellijk oplost als het nu is:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Een alternatieve benadering is om analytische activiteiten uit te stellen totdat de pagina eerst zichtbaar wordt gemaakt, die zowel de voor- en ook voor de voor- en tabbladen op de achtergrond zou dekken (bijvoorbeeld met de rechtermuisknop en openen in nieuw tabblad):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

Hoewel dit zinvol kan zijn voor analyses en soortgelijke gebruiksscenario's, wilt u in andere gevallen misschien meer inhoud geladen voor die gevallen, en misschien wilt u document.prerendering gebruiken. Voor- en voor- en prerenderingchange en voor- gerichte -voorralingpagina's.

Houd andere inhoud tegen tijdens het voor-

Dezelfde API's die eerder worden besproken, kan worden gebruikt om andere inhoud tijdens de PRERENDER -fase tegen te houden. Dit kunnen specifieke delen van JavaScript of hele scriptelementen zijn die u liever niet kunt uitvoeren tijdens de PRERENDER -fase.

Bijvoorbeeld, gezien dit script:

<script src="https://example.com/app/script.js" async></script>

U kunt dit wijzigen in een dynamisch ingevoegd scriptelement dat alleen wordt ingevoegd op basis van de vorige whenActivated functie:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Dit kan nuttig zijn om verschillende scripts tegen te houden die analyses omvatten, of inhoud weergeven op basis van status of andere variabelen die kunnen veranderen tijdens een bezoek. Aanbevelingen of inlogstatus, of pictogrammen voor winkelmandjes kunnen bijvoorbeeld allemaal worden tegengehouden om ervoor te zorgen dat de meest actuele informatie wordt gepresenteerd.

While this is perhaps more likely to happen more often with the use of prerendering, these conditions are also true for pages loaded in background tabs mentioned previously (so the whenFirstVisible function could be used in place of whenActivated ).

In many cases state should ideally also be checked on general visibilitychange changes—for example, when returning to a page that has been background, any shopping basket counters should be updated with the latest number of items in the basket. So this is not a prerender-specific problem but prerender is just making an existing issue more obvious.

One way that Chrome mitigates some of the need for manually wrapping scripts or functions, is that certain APIs are held back as mentioned previously , and also third-party iframes are not rendered, so it's only content on top of this that is required to be manually held back.

Measure performance

For measuring performance metrics, analytics should consider whether it is better to measure these based upon the activation time rather than the page load time that browser APIs will report.

For Core Web Vitals, measured by Chrome through the Chrome User Experience Report , these are intended to measure the user experience. So these are measured based on activation time. This will often result in a 0 second LCP for example, showing this is great way of improving your Core Web Vitals.

From version 3.1.0, the web-vitals library has been updated to handle prerendered navigations in the same way Chrome measures Core Web Vitals. This version also flags prerendered navigations for those metrics in the Metric.navigationType attribute if the page was fully or partially prerendered.

Measure prerenders

Whether a page is prerendered can be seen with a non-zero activationStart entry of PerformanceNavigationTiming . This can then be logged using a Custom Dimension, or similar when logging the page views, for example using the pagePrerendered function described previously :

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

This will allow your analytics to show how many navigation are prerendered compared to other types of navigation, and also allow you to correlation any performance metrics or business metrics to these different navigation types. Faster pages means happier users, which can often have real impact on business measures as our case studies show.

As you measure the business impact of prerendering pages for instant navigations, you can decide whether it is worth investing more effort in using this technology to allow more navigations to be prerendered, or to investigate why pages are not being prerendered.

Measure hit rates

In addition to measuring the impact of pages that are visited after a prerender, it is also important to measure pages that are prerendered and not subsequently visited. This could imply you are prerendering too much, and using up valuable resources of the user for little benefit.

This can be measured by firing an analytics event when speculation rules are inserted—after checking the browser supports prerendering using HTMLScriptElement.supports('speculationrules') —to indicate that prerender was requested. (Note that just because a prerender was requested, does not indicate that a prerender was started or completed as, as noted previously, a prerender is a hint to the browser and it may choose not to prerender pages on user settings, current memory usage, or other heuristics.)

You can then compare the number of these events, to the actual prerender page views. Or alternatively fire another event on activation if that makes it easier to compare.

The "successful hit rate" can then be approximated by looking at the difference between these two figures. For pages where you are using the Speculation Rules API to prerender the pages, you can adjust the rules appropriately to ensure you keep a high hit rate to maintain the balance between using up the users resources to help them, versus using it needlessly.

Be aware that some prerendering may be taking place due to the address bar prerendering and not just your speculation rules. You can check the document.referrer (which will be blank for address bar navigation including prerendered address bar navigations) if you want to differentiate these.

Remember to also look at pages which have no prerenders, as that could indicate these pages are not eligible for prerendering, even from the address bar. That may mean you are not benefiting from this performance enhancement. The Chrome team is looking to add extra tooling to test for Prerender eligibility perhaps similar to the bfcache testing tool , and also potentially add an API to expose why a prerender failed.

Impact on extensions

See the dedicated post on Chrome Extensions: Extending API to support Instant Navigation which details some additional considerations extension authors may need to think about for prerendered pages.

Feedback

Prerendering is in active development by the Chrome team, and there are plenty of plans to expand the scope of what has been made available in the Chrome 108 release. We welcome any feedback on the GitHub repo or using our issue tracker , and look forward to hearing and sharing case studies of this exciting new API.

Dankbetuigingen

Thumbnail image by Marc-Olivier Jodoin on Unsplash