Prerendering delle pagine in Chrome per navigazioni immediate tra le pagine

Supporto dei browser

  • 109
  • 109
  • x
  • x

Il team di Chrome ha ripristinato il prerendering completo delle pagine future che è probabile che un utente visiti.

Breve cronologia del prerendering

In passato, Chrome supportava il suggerimento per le risorse <link rel="prerender" href="/next-page">, ma non era ampiamente supportato al di fuori di Chrome e non era un'API molto espressiva.

Questo prerendering precedente con il suggerimento rel=prerender del link è stato ritirato a favore di NoState Prefetch, che invece recuperava le risorse necessarie per la pagina futura, ma non esegue il prerendering completo della pagina né esegue JavaScript. NoState Prefetch aiuta a migliorare le prestazioni della pagina migliorando il caricamento delle risorse, ma non restituisce un caricamento della pagina istantaneo come un prerendering completo.

Il team di Chrome ha ora reintrodotto il prerendering completo in Chrome. Per evitare complicazioni nell'utilizzo esistente e per consentire un'espansione futura del prerendering, questo nuovo meccanismo di prerendering non utilizzerà la sintassi <link rel="prerender"...>, che rimane attiva per NoState Prefetch, con l'obiettivo di ritirarla in futuro.

In che modo viene eseguito il prerendering di una pagina?

Una pagina può essere sottoposta a prerendering in uno dei seguenti quattro modi, ognuno dei quali ha lo scopo di velocizzare la navigazione:

  1. Quando digiti un URL nella barra degli indirizzi di Chrome (nota anche come "omnibox"), Chrome potrebbe eseguire automaticamente il prerendering della pagina per te, se è sicuro che la visiterai.
  2. Quando utilizzi la barra dei Preferiti, Chrome potrebbe eseguire automaticamente il prerendering della pagina tenendo premuto il puntatore su uno dei pulsanti dei Preferiti.
  3. Quando digiti un termine nella barra degli indirizzi di Chrome, Chrome potrebbe eseguire automaticamente il prerendering della pagina dei risultati di ricerca su richiesta del motore di ricerca.
  4. I siti possono utilizzare l'API Speculation Rules per indicare in modo programmatico a Chrome quali pagine eseguire il prerendering. Questa funzionalità sostituisce le attività di <link rel="prerender"...> e consente ai siti di eseguire il prerendering proattivo di una pagina in base a regole di speculazione. Possono essere presenti in modo statico nelle pagine o inseriti dinamicamente da JavaScript secondo le necessità del proprietario della pagina.

In ognuno di questi casi, un prerendering si comporta come se la pagina fosse stata aperta in una scheda in background invisibile e poi "attivato" sostituendo la scheda in primo piano con quella pagina sottoposta a prerendering. Se una pagina viene attivata prima di aver eseguito il prerendering completo, il suo stato attuale è "in primo piano" e continua a caricarsi, il che significa che puoi comunque iniziare bene.

Poiché la pagina sottoposta a prerendering viene aperta in uno stato nascosto, una serie di API che causano comportamenti invasivi (ad esempio le richieste) non vengono attivate in questo stato, ma vengono ritardate fino all'attivazione della pagina. Nei pochi casi in cui non è ancora possibile, il prerendering viene annullato. Il team di Chrome sta lavorando all'esposizione dei motivi di annullamento del prerendering come API, nonché al miglioramento delle funzionalità di DevTools per semplificare l'identificazione di questi casi limite.

Impatto del prerendering

Il prerendering consente un caricamento della pagina quasi istantaneo, come mostrato nel seguente video:

Esempio di impatto del prerendering.

Il sito di esempio è già veloce, ma anche con questo puoi vedere come il prerendering migliora l'esperienza utente. Ciò può quindi avere un impatto diretto anche sui Segnali web essenziali di un sito, con un valore LCP quasi pari a zero, riduzione della CLS (dal momento che qualsiasi CLS del carico avviene prima della visualizzazione iniziale) e miglioramento dell'INP (dal momento che il caricamento deve essere completato prima dell'interazione dell'utente).

Anche quando una pagina si attiva prima di essere completamente caricata, avere un avvio iniziale nel caricamento pagina dovrebbe migliorare l'esperienza di caricamento. Quando viene attivato un link mentre il prerendering è ancora in corso, la pagina di prerendering verrà spostata nel frame principale e continuerà a caricarsi.

Tuttavia, il prerendering utilizza memoria e larghezza di banda di rete aggiuntivi. Fai attenzione a non eseguire il prerendering eccessivo, a scapito delle risorse utente. Esegui il prerendering solo quando c'è un'alta probabilità di accedere alla pagina.

Consulta la sezione Misurazione del rendimento per ulteriori informazioni su come misurare l'impatto effettivo sul rendimento nelle analisi.

Visualizzare le previsioni nella barra degli indirizzi di Chrome

Per il primo caso d'uso, puoi visualizzare le previsioni di Chrome per gli URL nella pagina chrome://predictors:

La pagina dei predittori di Chrome filtrata in modo da mostrare previsioni basse (grigio), medie (ambra) e alte (verde) in base al testo inserito.
Pagina degli predittori di Chrome.

Le linee verdi indicano un grado di confidenza sufficiente per attivare il prerendering. In questo esempio, se digiti "s" ottieni un livello di confidenza ragionevole (ambra), ma quando digiti "sh" Chrome ha abbastanza sicurezza che il livello di sicurezza verrà quasi sempre indirizzato a https://sheets.google.com.

Questo screenshot è stato acquisito in un'installazione di Chrome relativamente recente e ha filtrato le previsioni a confidenza zero, ma se visualizzi i tuoi previsioni, probabilmente vedrai molte più voci e potenzialmente più caratteri necessari per raggiungere un livello di confidenza sufficientemente elevato.

Questi predittori sono anche ciò che determina le opzioni suggerite nella barra degli indirizzi che potresti aver notato:

Funzionalità &quot;Typeahead&quot; della barra degli indirizzi di Chrome
Funzionalità "Typeahead" per la barra degli indirizzi.

Chrome aggiornerà continuamente i propri predittori in base alla tua digitazione e alle tue selezioni.

  • Per un livello di confidenza superiore al 50% (indicato in ambra), Chrome si precollega in modo proattivo al dominio, ma non esegue il prerendering della pagina.
  • Per un livello di confidenza superiore all'80% (indicato in verde), Chrome eseguirà il prerendering dell'URL.

L'API Speculation Rules

Per la terza opzione di prerendering, gli sviluppatori web possono inserire istruzioni JSON nelle loro pagine per comunicare al browser quali URL eseguire il prerendering:

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

In alternativa, in base alle regole del documento (disponibili da Chrome 121), che eseguono il prerendering dei link trovati nel documento in base a selettori href (in base all'API URL Pattern) o ai selettori CSS:

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

Il team di Chrome ha preparato un codelab sulle regole di speculazione che ti guiderà nella procedura di aggiunta di queste regole a un sito.

entusiasmo

Supporto dei browser

  • 121
  • 121
  • x
  • x

Un'impostazione eagerness viene utilizzata per indicare quando attivare le speculazioni, una funzionalità particolarmente utile per le regole relative ai documenti:

  • immediate: questo parametro viene utilizzato per fare supposizioni il prima possibile, ovvero non appena vengono osservate le regole di speculazione.
  • eager: questo comportamento è identico all'impostazione immediate, ma in futuro intendiamo collocarlo tra immediate e moderate.
  • moderate: questa operazione esegue speculazioni se tieni premuto il puntatore del mouse su un link per 200 millisecondi (o sull'evento pointerdown se questo è più veloce e sui dispositivi mobili dove non è presente alcun evento hover).
  • conservative: esegue una speculazione sul puntatore o sul touchdown.

Il valore predefinito di eagerness per le regole list è immediate. Le opzioni moderate e conservative possono essere utilizzate per limitare le regole list agli URL con cui un utente interagisce con un elenco specifico. Anche se in molti casi, le regole document con una condizione where appropriata potrebbero essere più appropriate.

Il valore predefinito di eagerness per le regole document è conservative. Dato che un documento può essere composto da molti URL, l'utilizzo delle regole immediate o eager per document deve essere utilizzato con cautela (consulta anche la sezione Limiti di Chrome di seguito).

L'impostazione di eagerness da utilizzare dipende dal tuo sito. Per un sito leggero e statico, fare supposizioni con più entusiasmo può avere pochi costi ed essere vantaggioso per gli utenti. I siti con architetture più complesse e un payload più pesante per le pagine potrebbero preferire ridurre gli sprechi speculando meno spesso fino a quando non si ottiene un segnale di intenzione più positivo da parte degli utenti per limitare gli sprechi.

L'opzione moderate è una via di mezzo e molti siti potrebbero trarre vantaggio dalla seguente regola di speculazione che eseguirebbe il prerendering di un link tenendo il puntatore sul link per 200 millisecondi o sull'evento di puntatore come un'implementazione di base ma efficace delle regole di speculazione:

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

Precaricamento

Le regole di speculazione possono essere utilizzate anche per precaricare soltanto le pagine, senza un prerendering completo. Spesso questa procedura può essere un buon primo passo verso il prerendering:

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

Limiti di Chrome

Chrome prevede dei limiti per impedire l'uso eccessivo dell'API Speculation Rules:

entusiasmo Precaricamento Prerendering
immediate/eager 50 10
moderate/conservative 2 (FIFO) 2 (FIFO)
Limiti di speculazione in Chrome.

Le impostazioni moderate e conservative, che dipendono dall'interazione dell'utente, funzionano secondo il modo FIFO (First In, First Out): una volta raggiunto il limite, una nuova speculazione farà sì che la speculazione meno recente venga annullata e sostituita da quella più recente per risparmiare memoria. Una speculazione annullata può essere attivata di nuovo, ad esempio passando di nuovo il mouse sopra il link. In questo modo, l'URL viene speculato, eliminando la speculazione meno recente. In questo caso, la speculazione precedente avrà memorizzato nella cache tutte le risorse memorizzabili nella cache nella cache HTTP per quell'URL, quindi ipotizzare un periodo di tempo aggiuntivo dovrebbe avere un costo ridotto. Ecco perché il limite viene impostato sulla soglia modesta di 2. Le regole dell'elenco statico non vengono attivate da un'azione dell'utente, pertanto hanno un limite più alto, in quanto il browser non può sapere quali sono e quando sono necessarie.

Anche i limiti immediate e eager sono dinamici, quindi la rimozione di un elemento script URL list creerà capacità annullando le speculazioni rimosse.

Inoltre, Chrome impedirà l'utilizzo di speculazioni in determinate condizioni, tra cui:

  • Save-Data (Salva dati).
  • Risparmio energetico quando questa funzionalità è attiva e con batteria in esaurimento.
  • Vincoli di memoria.
  • Quando l'impostazione "Precarica le pagine" è disattivata (disattivata anche esplicitamente da estensioni di Chrome, come uBlock Origin).
  • Pagine aperte in schede in background.

Inoltre, Chrome non esegue il rendering degli iframe multiorigine sulle pagine sottoposte a prerendering fino all'attivazione.

L'obiettivo di tutte queste condizioni è ridurre l'impatto di una speculazione eccessiva che potrebbe essere dannosa per gli utenti.

Come includere regole di speculazione in una pagina

Le regole di speculazione possono essere incluse in modo statico nel codice HTML della pagina o inserite dinamicamente nella pagina tramite JavaScript:

  • Regole di speculazione incluse staticamente: ad esempio un sito di notizie o un blog può eseguire il prerendering dell'articolo più recente, se questa è spesso la navigazione successiva per una grande percentuale di utenti. In alternativa, le regole per i documenti con moderate o conservative possono essere utilizzate per speculare quando gli utenti interagiscono con i link.
  • Regole di speculazione inserite dinamicamente: potrebbero basarsi sulla logica dell'applicazione, personalizzate in base all'utente o ad altre euristiche.

Consigliamo a chi preferisce l'inserimento dinamico in base ad azioni quali il passaggio del mouse o il clic verso il basso su un link, come facevano in passato molte librerie con <link rel=prefetch>, di esaminare le regole dei documenti, poiché queste consentono al browser di gestire molti dei casi d'uso.

Le regole di speculazione possono essere aggiunte in <head> o in <body> nel frame principale. Non viene eseguita alcuna azione sulle regole di speculazione nei frame secondari e le regole di speculazione nelle pagine sottoposte a prerendering vengono eseguite solo dopo che la pagina è stata attivata.

L'intestazione HTTP Speculation-Rules

Supporto dei browser

  • 121
  • 121
  • x
  • x

Origine

Le regole di speculazione possono essere caricate anche utilizzando un'intestazione HTTP Speculation-Rules, invece di includerle direttamente nel codice HTML del documento. Ciò consente un deployment più semplice da parte delle reti CDN senza dover modificare i contenuti dei documenti.

L'intestazione HTTP Speculation-Rules viene restituita con il documento e rimanda alla posizione di un file JSON contenente le regole di speculazione:

Speculation-Rules: "/speculationrules.json"

Questa risorsa deve utilizzare il tipo MIME corretto e, se si tratta di una risorsa multiorigine, superare un controllo CORS.

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

Se vuoi utilizzare URL relativi, ti consigliamo di includere la chiave "relative_to": "document" nelle regole di speculazione. In caso contrario, gli URL relativi saranno relativi all'URL del file JSON delle regole di speculazione. Questo può essere particolarmente utile se devi selezionare alcuni o tutti i collegamenti della stessa origine.

Regole di speculazione e APS

Le regole di speculazione sono supportate solo per le navigazioni nelle pagine complete gestite dal browser e non per le app a pagina singola (APS) o le pagine shell dell'app. Queste architettura non utilizzano i recuperi dei documenti, ma eseguono recuperi parziali di dati o pagine da parte dell'API o di pagine, che vengono poi elaborati e presentati nella pagina corrente. I dati necessari per queste cosiddette "navigazioni soft" possono essere precaricati dall'app al di fuori delle regole di speculazione, ma non possono essere sottoposti a prerendering.

Puoi usare regole di speculazione per eseguire il prerendering dell'applicazione stessa da una pagina precedente. Ciò può aiutarti a compensare alcuni dei costi di caricamento iniziali aggiuntivi sostenuti da alcune APS. Tuttavia, le modifiche al percorso all'interno dell'app non possono essere sottoposte a prerendering.

Debug delle regole di speculazione

Consulta il post dedicato sul debug delle regole di speculazione per scoprire le nuove funzionalità di Chrome DevTools che ti aiuteranno a visualizzare e eseguire il debug di questa nuova API.

Regole di speculazione multipla

Puoi anche aggiungere più regole di speculazione alla stessa pagina, che vengono aggiunte alle regole esistenti. Di conseguenza, tutti questi modi diversi comportano il prerendering sia di one.html sia di two.html:

Elenco di URL:

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

Più script speculationrules:

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

Più elenchi in un insieme di speculationrules

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

Supporto dei browser

  • 121
  • 121
  • x
  • x

Origine

Durante il precaricamento o il prerendering di una pagina, alcuni parametri URL (tecnicamente noti come parametri di ricerca) potrebbero non essere importanti per la pagina effettivamente pubblicata dal server ed essere utilizzati solo dal codice JavaScript lato client.

Ad esempio, i parametri UTM vengono utilizzati da Google Analytics per la misurazione delle campagne, ma di solito non generano pagine diverse pubblicate dal server. Ciò significa che page1.html?utm_content=123 e page1.html?utm_content=456 pubblicheranno la stessa pagina dal server, pertanto la stessa pagina può essere riutilizzata dalla cache.

Analogamente, le applicazioni possono utilizzare altri parametri URL gestiti solo sul lato client.

La proposta No-Vary-Search consente a un server di specificare parametri che non risultano in una differenza rispetto alla risorsa pubblicata, consentendo al browser di riutilizzare versioni precedentemente memorizzate nella cache di un documento che differiscono solo per questi parametri. Questa funzionalità è supportata in Chrome (e nei browser basati su Chromium) per le speculazioni di navigazione con precaricamento (anche se stiamo cercando di supportare questa funzionalità anche per il prerendering).

Le regole di speculazione supportano l'uso di expects_no_vary_search per indicare dove è previsto che venga restituita un'intestazione HTTP No-Vary-Search. In questo modo è possibile evitare ulteriori download inutili.

<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 questo esempio, il codice HTML della pagina iniziale di /products è lo stesso per gli ID prodotto 123 e 124. Tuttavia, alla fine i contenuti della pagina differiscono in base al rendering lato client se viene utilizzato JavaScript per recuperare i dati di prodotto usando il parametro di ricerca id. Di conseguenza, precaricamo con entusiasmo l'URL e dovrebbe restituire un'intestazione HTTP No-Vary-Search che mostra che la pagina può essere utilizzata per qualsiasi parametro di ricerca id.

Tuttavia, se l'utente fa clic su uno dei link prima del completamento del precaricamento, il browser potrebbe non aver ricevuto la pagina /products. In questo caso, il browser non sa se conterrà l'intestazione HTTP No-Vary-Search. Il browser può quindi scegliere se recuperare di nuovo il link o attendere il completamento del precaricamento per vedere se contiene un'intestazione HTTP No-Vary-Search. L'impostazione expects_no_vary_search consente al browser di sapere che la risposta della pagina dovrebbe contenere un'intestazione HTTP No-Vary-Search e di attendere il completamento del precaricamento.

Limitazioni delle regole di speculazione e miglioramenti futuri

Le regole di speculazione sono limitate alle pagine aperte nella stessa scheda, ma ci stiamo adoperando per ridurre questa limitazione.

Per impostazione predefinita, le speculazioni sono limitate alle pagine della stessa origine. Pagine multiorigine di speculazione dello stesso sito (ad esempio, https://a.example.com potrebbe eseguire il prerendering di una pagina su https://b.example.com). Per utilizzare questa funzionalità, la pagina speculata (in questo esempio https://b.example.com) deve essere attivata includendo un'intestazione HTTP Supports-Loading-Mode: credentialed-prerender. In caso contrario, Chrome annullerà la speculazione.

Le versioni future potrebbero anche consentire il prerendering per pagine multiorigine non sullo stesso sito, a condizione che non esistano cookie per la pagina sottoposta a prerendering e che la pagina sottoposta a prerendering venga attivata con un'intestazione HTTP Supports-Loading-Mode: uncredentialed-prerender simile.

Le regole di speculazione supportano già i precaricamenti multiorigine, ma di nuovo solo quando non esistono cookie per il dominio multiorigine. Se sono presenti cookie di un utente che ha visitato quel sito in precedenza, la speculazione non verrà attivata e mostrerà un errore in DevTools.

Date queste limitazioni attuali, un pattern che può migliorare l'esperienza utente sia per i link interni che per i link esterni, ove possibile, consiste nel prerenderizzare gli URL della stessa origine e tentare di precaricare gli URL multiorigine:

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

La limitazione per impedire le speculazioni multiorigine per i collegamenti multiorigine per impostazione predefinita è necessaria per la sicurezza. Si tratta di un miglioramento rispetto a <link rel="prefetch"> per le destinazioni multiorigine, che non inviano cookie, ma tentano comunque di eseguire il precaricamento. Ciò si tradurrà in un precaricamento sprecato che deve essere inviato di nuovo o, peggio ancora, in un caricamento errato della pagina.

Supporto dell'API Detect Speculation Rules

Puoi rilevare il supporto dell'API Speculation Rules con i controlli HTML standard:

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

Aggiungi regole di speculazione in modo dinamico tramite JavaScript

Ecco un esempio di aggiunta di una regola di speculazione prerender con 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);
}

Puoi visualizzare una demo del prerendering dell'API Speculation Rules, utilizzando l'inserimento JavaScript, in questa pagina demo di prerendering.

L'inserimento di un elemento <script type = "speculationrules"> direttamente nel DOM non registrerà le regole di speculazione poiché deve essere aggiunto come mostrato in precedenza. Ad esempio, la modifica diretta del riquadro Elementi in Chrome DevTools per aggiungere l'elemento <script type = "speculationrules"> non registra le regole di speculazione. Al contrario, per inserire le regole, lo script per aggiungerlo in modo dinamico al DOM deve essere eseguito dalla console.

Aggiungere regole di speculazione tramite un gestore di tag

Per aggiungere regole di speculazione utilizzando uno strumento di gestione dei tag come Google Tag Manager (GTM), queste devono essere inserite tramite JavaScript, anziché aggiungere l'elemento <script type = "speculationrules"> tramite GTM direttamente per gli stessi motivi indicati in precedenza:

Configurazione di un tag HTML personalizzato in Google Tag Manager
Aggiunta di regole di speculazione tramite Google Tag Manager.

Tieni presente che in questo esempio viene utilizzato var perché GTM non supporta const.

Annulla regole di speculazione

La rimozione di regole di speculazione comporterà l'annullamento del prerendering, ma, quando ciò è avvenuto, è probabile che le risorse siano già state esaurite per avviare il prerendering, pertanto è consigliabile non eseguire il prerendering se esiste la probabilità che sia necessario annullarlo.

Regole di speculazione e Criterio di sicurezza del contenuto

Poiché le regole di speculazione utilizzano un elemento <script>, anche se contengono solo JSON, devono essere incluse nei Content-Security-Policy di script-src se il sito lo utilizza usando un hash o un nonce.

È possibile aggiungere un nuovo inline-speculation-rules a script-src per consentire il supporto degli elementi <script type="speculationrules"> inseriti da script hash o non gestiti. Non supporta le regole incluse nell'HTML iniziale, di conseguenza le regole devono essere inserite da JavaScript per i siti che utilizzano un CSP rigoroso.

Rileva e disattiva il prerendering

Il prerendering è in genere un'esperienza positiva per gli utenti, in quanto consente un rendering delle pagine veloce, spesso istantaneo. Questo è vantaggioso sia per l'utente sia per il proprietario del sito, poiché le pagine sottoposte a prerendering consentono una migliore esperienza utente che altrimenti sarebbe difficile ottenere.

Tuttavia, in alcuni casi non vuoi che venga eseguito il prerendering delle pagine, ad esempio quando lo stato delle pagine cambia, in base alla richiesta iniziale o in base all'esecuzione di JavaScript sulla pagina.

Attivare e disattivare il prerendering in Chrome

Il prerendering viene attivato solo per gli utenti di Chrome con l'impostazione "Precarica le pagine" in chrome://settings/performance/. Inoltre, il prerendering viene disattivato anche sui dispositivi con memoria ridotta o se il sistema operativo è in modalità Salva dati o Risparmio energetico. Consulta la sezione Limiti di Chrome.

Rileva e disattiva il prerendering lato server

Le pagine sottoposte a prerendering verranno inviate con l'intestazione HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

Per le pagine precaricate che utilizzano l'API Speculation Rules, l'intestazione sarà impostata su prefetch:

Sec-Purpose: prefetch

I server possono rispondere in base a questa intestazione, per registrare richieste di speculazione, restituire contenuti diversi o impedire un prerendering. Se viene restituito un codice di risposta di non riuscita (ovvero non 200 o 304), la pagina non verrà sottoposta a prerendering e qualsiasi pagina di precaricamento verrà eliminata.

Se non vuoi che una determinata pagina venga sottoposta a prerendering, questo è il modo migliore per assicurarti che ciò non avvenga. Tuttavia, per offrire un'esperienza ottimale, è consigliabile consentire il prerendering, ma ritardare le azioni che dovrebbero avvenire solo quando la pagina viene effettivamente visualizzata utilizzando JavaScript.

Rileva il prerendering in JavaScript

L'API document.prerendering restituirà true durante il prerendering della pagina. Questa funzionalità può essere utilizzata dalle pagine per evitare, o ritardare, determinate attività durante il prerendering fino all'attivazione effettiva della pagina.

Una volta attivato un documento sottoposto a prerendering, anche il valore activationStart di PerformanceNavigationTiming verrà impostato su un tempo diverso da zero che rappresenta il tempo tra l'inizio del prerendering e l'effettiva attivazione del documento.

Puoi avere una funzione per verificare le pagine di prerendering e prerendering come la seguente:

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

Il modo più semplice per vedere se una pagina è stata sottoposta a prerendering (totalmente o parzialmente) è aprire DevTools dopo l'attivazione della pagina e digitare performance.getEntriesByType('navigation')[0].activationStart nella console. Se viene restituito un valore diverso da zero, sai che la pagina è stata sottoposta a prerendering:

La console in Chrome DevTools mostra un valore di activationStart positivo che indica che la pagina è stata sottoposta a prerendering
Test del prerendering nella console.

Quando la pagina viene attivata dall'utente che la visualizza, l'evento prerenderingchange viene inviato sulla pagina document, che può essere quindi utilizzata per abilitare le attività che in precedenza sarebbero state avviate per impostazione predefinita al caricamento della pagina, ma che vuoi ritardare finché la pagina non viene effettivamente visualizzata dall'utente.

Utilizzando queste API, il codice JavaScript frontend può rilevare le pagine sottoposte a prerendering e intervenire in modo appropriato.

Impatto sull'analisi

Analytics viene utilizzato per misurare l'utilizzo del sito web, ad esempio utilizzando Google Analytics per misurare le visualizzazioni di pagina e gli eventi. In alternativa, puoi misurare le metriche sul rendimento delle pagine utilizzando il monitoraggio degli utenti reali (RUM).

Le pagine devono essere sottoposte a prerendering solo quando è molto probabile che la pagina venga caricata dall'utente. Questo è il motivo per cui le opzioni di prerendering della barra degli indirizzi di Chrome vengono visualizzate solo quando c'è una probabilità così alta (superiore all'80% delle volte).

Tuttavia, in particolare quando si utilizza l'API Speculation Rules, le pagine sottoposte a prerendering potrebbero influire sull'analisi e i proprietari dei siti potrebbero dover aggiungere codice aggiuntivo per abilitare l'analisi solo per le pagine sottoposte a prerendering al momento dell'attivazione, poiché non tutti i fornitori di analisi potrebbero farlo per impostazione predefinita.

Puoi ottenere questo risultato utilizzando un elemento Promise che attende l'evento prerenderingchange se è in corso il prerendering di un documento o si risolve immediatamente se lo è:

// 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();

Un approccio alternativo consiste nel ritardare le attività fino a quando la pagina non viene resa visibile per la prima volta, il che riguarda sia le maiuscole/minuscole di prerendering, sia quando le schede vengono aperte in background (ad esempio facendo clic con il tasto destro del mouse e aperte in una nuova scheda):

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

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

initAnalytics();

Anche se questo può avere senso per dati e analisi e casi d'uso simili, in altri casi potresti voler caricare più contenuti in questi casi, quindi utilizzare document.prerendering e prerenderingchange per scegliere come target specificamente pagine di prerendering.

Misurare le prestazioni

Per misurare le metriche sul rendimento, Analytics dovrebbe valutare se è meglio misurarle in base al tempo di attivazione anziché al tempo di caricamento della pagina segnalato dalle API del browser.

Per i Segnali web essenziali, misurati da Chrome tramite il Report sull'esperienza utente di Chrome, hanno lo scopo di misurare l'esperienza utente. che vengono quindi misurate in base al tempo di attivazione. Ad esempio, questo si traduce in un LCP di 0 secondi. Questo è un ottimo modo per migliorare i tuoi Segnali web essenziali.

A partire dalla versione 3.1.0, la libreria web-vitals è stata aggiornata per gestire le navigazioni con prerendering allo stesso modo in cui Chrome misura i Segnali web essenziali. Questa versione segnala anche le navigazioni con prerendering per queste metriche nell'attributo Metric.navigationType se la pagina è stata sottoposta a prerendering completamente o parzialmente.

Misurare il prerendering

Indica se una pagina è sottoposta a prerendering può essere visualizzata con una voce activationStart diversa da zero di PerformanceNavigationTiming. Questo può essere registrato utilizzando una dimensione personalizzata o simile quando registri le visualizzazioni di pagina, ad esempio utilizzando la funzione pagePrerendered descritta in precedenza:

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

In questo modo, le tue analisi potranno mostrare quante navigazioni vengono sottoposte a prerendering rispetto ad altri tipi di navigazione e potrai correlare eventuali metriche sul rendimento o sull'attività con questi diversi tipi di navigazione. Pagine più veloci significano utenti più soddisfatti, il che spesso può avere un impatto reale sulle misure aziendali, come mostrano i nostri case study.

Quando misuri l'impatto commerciale del prerendering delle pagine per le navigazioni istantanee, puoi decidere se vale la pena investire di più nell'utilizzo di questa tecnologia per consentire il prerendering di più navigazioni o per capire perché le pagine non vengono sottoposte a prerendering.

Misurare le percentuali di successo

Oltre a misurare l'impatto delle pagine visitate dopo un prerendering, è importante anche misurare le pagine che vengono sottoposte a prerendering e non visitate successivamente. Ciò potrebbe significare che stai eseguendo troppo il prerendering e che stai utilizzando risorse preziose dell'utente per pochi vantaggi.

Questo può essere misurato attivando un evento di analisi quando vengono inserite regole di speculazione, dopo aver verificato che il browser supporti il prerendering tramite HTMLScriptElement.supports('speculationrules'), per indicare che è stato richiesto il prerendering. Tieni presente che solo perché è stato richiesto un prerendering, non indica che un prerendering è stato avviato o completato poiché, come indicato in precedenza, un prerendering è un suggerimento per il browser e potrebbe scegliere di non eseguire il prerendering delle pagine in base alle impostazioni utente, all'utilizzo corrente della memoria o ad altre euristiche.)

Puoi quindi confrontare il numero di questi eventi con le effettive visualizzazioni di pagina di prerendering. In alternativa, attiva un altro evento al momento dell'attivazione, se questo semplifica il confronto.

La "percentuale di hit andati a buon fine" può quindi essere approssimata osservando la differenza tra queste due cifre. Per le pagine in cui utilizzi l'API Speculation Rules per il prerendering delle pagine, puoi modificare le regole in modo appropriato per mantenere un alto tasso di successo e mantenere l'equilibrio tra l'utilizzo eccessivo delle risorse per gli utenti e l'uso superfluo.

Tieni presente che potrebbe verificarsi qualche prerendering a causa del prerendering della barra degli indirizzi e non solo delle tue regole di speculazione. Puoi selezionare document.referrer (che sarà vuoto per la navigazione nella barra degli indirizzi, incluse le navigazioni nella barra degli indirizzi sottoposti a prerendering) se vuoi distinguerli.

Ricordati di controllare anche le pagine che non hanno prerendering, poiché ciò potrebbe indicare che queste pagine non sono idonee per il prerendering, anche dalla barra degli indirizzi. Ciò potrebbe significare che non stai beneficiando di questo miglioramento delle prestazioni. Il team di Chrome sta cercando di aggiungere ulteriori strumenti per testare l'idoneità di prerendering, forse simili allo strumento di test bfcache, nonché aggiungere potenzialmente un'API per scoprire il motivo per cui un prerendering non è riuscito.

Impatto sulle estensioni

Leggi il post dedicato Chrome Extensions: estensione dell'API per supportare la navigazione istantanea che descrive in dettaglio alcune considerazioni aggiuntive a cui gli autori delle estensioni potrebbero dover tenere conto per le pagine sottoposte a prerendering.

Feedback

Il prerendering è in fase di sviluppo attivo da parte del team di Chrome e sono in programma molti per estendere l'ambito di ciò che è stato reso disponibile con la release 108 di Chrome. Siamo lieti di ricevere feedback sul repository GitHub o sull'utilizzo del nostro strumento di monitoraggio dei problemi. Non vediamo l'ora di ascoltare e condividere i case study di questa nuova ed entusiasmante API.

Ringraziamenti

Immagine in miniatura di Marc-Olivier Jodoin su Unsplash