Geef pagina's vooraf weer in Chrome voor directe paginanavigatie

Barry Pollard

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 op zijn plaats blijft voor NoState Prefetch, met het oog op dit op een bepaald moment in de toekomst met pensioen te laten gaan.

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 adresbalk van Chrome 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:

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 lading CLS plaatsvindt vóór de eerste weergave) en verbeterde INP (aangezien de lading voltooid moet zijn 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:

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:

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 pre-renderoptie Speculation Rules API kunnen webontwikkelaars JSON-instructies op hun pagina's invoegen om de browser te informeren over welke URL's vooraf moeten worden gerenderd:

<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

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:

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 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 als gebruikers communiceren met links.
• 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 het aanwijzen van de muisaanwijzer of het klikken op een link (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 om met veel van uw gebruiksscenario's.

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

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>

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 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 prefetch-navigatiespeculaties (hoewel we dit ook willen ondersteunen voor 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 wel doet, kunt u onnodige downloads verder voorkomen.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

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

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

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, de onjuist laden van 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 prerendering 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

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

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 zich echter gevallen voordoen 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:

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 is geopend. daadwerkelijk door de gebruiker 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 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 vergelijkbare 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 prerendering-pagina'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 . Als 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 wegneemt, is dat bepaalde API's worden tegengehouden zoals eerder vermeld , en dat ook iframes van derden niet worden weergegeven, dus alleen de inhoud daarbovenop hoeft te worden weergegeven handmatig 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 renderen 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 mogelijk te maken, of om te onderzoeken waarom pagina's niet vooraf worden weergegeven.

Meet hitpercentages

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

Dit kan worden gemeten door een analysegebeurtenis te activeren wanneer speculatieregels worden ingevoegd (na te hebben gecontroleerd of de browser pre-rendering ondersteunt met behulp van HTMLScriptElement.supports('speculationrules') om aan te geven dat pre-rendering is aangevraagd. (Houd er rekening mee dat het feit dat een pre-render is aangevraagd, niet betekent dat een pre-render is gestart of voltooid, aangezien, zoals eerder opgemerkt, een pre-render een hint is voor de browser en deze ervoor kan kiezen om pagina's over gebruikersinstellingen, huidig ​​geheugengebruik, of andere heuristieken.)

Vervolgens kunt u het aantal van deze gebeurtenissen vergelijken met de daadwerkelijke pre-render-paginaweergaven. Of activeer een andere gebeurtenis bij activering als dat het vergelijken gemakkelijker maakt.

Het ‘succesvolle trefferpercentage’ kan vervolgens worden benaderd door te kijken naar het verschil tussen deze twee cijfers. Voor pagina's waarop u de Speculation Rules API gebruikt om de pagina's vooraf weer te geven, kunt u de regels op de juiste manier aanpassen om ervoor te zorgen dat u een hoog trefferpercentage behoudt en de balans behoudt tussen het gebruik van de bronnen van de gebruiker om hen te helpen, en het onnodig gebruiken ervan.

Houd er rekening mee dat er mogelijk sprake is van pre-rendering vanwege de pre-rendering van de adresbalk en niet alleen vanwege uw speculatieregels. U kunt de document.referrer controleren (die leeg is voor adresbalknavigatie, inclusief vooraf weergegeven adresbalknavigatie) als u deze wilt onderscheiden.

Vergeet niet om ook naar pagina's te kijken die geen pre-rendering hebben, omdat dit erop kan wijzen dat deze pagina's niet in aanmerking komen voor pre-rendering, zelfs niet vanuit de adresbalk. Dat kan betekenen dat u niet profiteert van deze prestatieverbetering. Het Chrome-team wil extra tools toevoegen om te testen of je in aanmerking komt voor Prerender, misschien vergelijkbaar met de bfcache-testtool , en mogelijk ook een API toevoegen om te achterhalen waarom een ​​prerender mislukte.

Impact op extensies

Zie het speciale bericht over Chrome-extensies: API uitbreiden om directe navigatie te ondersteunen , waarin enkele aanvullende overwegingen worden beschreven waar auteurs van extensies mogelijk aan moeten denken voor vooraf gegenereerde pagina's.

Feedback

Prerendering wordt momenteel actief ontwikkeld door het Chrome-team en er zijn tal van plannen om de reikwijdte uit te breiden van wat beschikbaar is gemaakt in de Chrome 108-release. We verwelkomen alle feedback over de GitHub-repository of het gebruik van onze issue tracker , en kijken uit naar het horen en delen van casestudy's van deze opwindende nieuwe API.

Gerelateerde links

• Speculatieregels Codelab
• Debuggen van speculatieregels
• Maak kennis met NoState Prefetch
• Speculatieregels API-specificatie
• De navigatiespeculatie GitHub-repository
• Chrome-extensies: uitbreiding van de API ter ondersteuning van directe navigatie

Dankbetuigingen

Miniatuurafbeelding door Marc-Olivier Jodoin op Unsplash