Prerendering delle pagine in Chrome per navigazioni immediate tra le pagine

Barry Pollard

Il team di Chrome ha ripristinato il prerendering completo delle pagine future che probabilmente verranno visitate da un utente.

Breve cronologia del prerendering

In passato, Chrome supportava il suggerimento relativo alle risorse <link rel="prerender" href="/next-page">, che tuttavia non era supportato su larga scala oltre Chrome e non era un'API molto espressiva.

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

Il team di Chrome ha ora reintrodotto il prerendering completo in Chrome. Per evitare complicazioni con l'utilizzo esistente e per consentire l'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.

Come viene eseguito il prerendering di una pagina?

È possibile eseguire il prerendering di una pagina in quattro modi, ognuno dei quali ha lo scopo di rendere la navigazione più rapida:

1. Quando digiti un URL nella barra degli indirizzi di Chrome (nota anche come "la omnibox"), Chrome potrebbe eseguire automaticamente il prerendering della pagina, se è molto probabile che la visiterai, in base alla tua cronologia di navigazione precedente.
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 di ricerca nella barra degli indirizzi di Chrome, Chrome potrebbe eseguire automaticamente il prerendering della pagina dei risultati di ricerca, quando il motore di ricerca ti chiede di farlo.
4. I siti possono utilizzare l'API Speculation Rules per indicare in modo programmatico a Chrome le pagine di cui eseguire il prerendering. Questo sostituisce l'operazione di <link rel="prerender"...> e consente ai siti di eseguire il prerendering proattivo di una pagina in base a regole di speculazione sulla pagina. Questi elementi possono esistere in modo statico nelle pagine o essere inseriti dinamicamente da JavaScript quando il proprietario della pagina ritiene opportuno.

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

Quando la pagina sottoposta a prerendering viene aperta in stato nascosto, alcune API che causano comportamenti invasivi (ad esempio dei prompt) non vengono attivate in questo stato, ma vengono ritardate fino all'attivazione della pagina. Nel numero ridotto di casi in cui ciò non è ancora possibile, il prerendering viene annullato. Il team di Chrome sta lavorando all'esposizione dei motivi dell'annullamento del prerendering come API e 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:

Il sito di esempio è già un sito veloce, ma anche con questo puoi vedere come il prerendering migliora l'esperienza utente. Di conseguenza, ciò può anche avere un impatto diretto sui Core Web Vitals di un sito, con un valore LCP quasi pari a zero, una riduzione della metrica CLS (dal momento che qualsiasi caricamento avviene prima della visualizzazione iniziale) e un miglioramento INP (dal momento che il caricamento deve essere completato prima dell'interazione dell'utente).

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

Tuttavia, il prerendering utilizza memoria e larghezza di banda di rete aggiuntive. Fai attenzione a non eseguire un prerendering eccessivo, a costo di risorse per l'utente. Esegui il prerendering solo quando c'è un'alta probabilità di raggiungere la pagina.

Per ulteriori informazioni su come misurare l'impatto effettivo sul rendimento in Analytics, consulta la sezione Misurazione del rendimento.

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:

Le linee verdi indicano una confidenza sufficiente per attivare il prerendering. In questo esempio, se digiti "s" restituisce una confidenza ragionevole (ambra), ma quando digiti "sh" Chrome è sufficientemente sicuro da consentirti di navigare quasi sempre su https://sheets.google.com.

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

Anche questi fattori di previsione sono alla base delle opzioni suggerite dalla barra degli indirizzi, che potresti aver notato:

Chrome aggiorna continuamente i suoi previsioni in base alla digitazione e alle selezioni.

• Per un livello di confidenza superiore al 50% (visualizzato 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 esegue il prerendering dell'URL.

API Speculation Rules

Per l'opzione di prerendering dell'API Speculation Rules, gli sviluppatori web possono inserire istruzioni JSON nelle proprie pagine per informare il browser sugli URL di cui eseguire il prerendering:

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

In alternativa, in base alle regole dei documenti (disponibili in Chrome 121), che eseguono il prerendering dei link trovati nel documento in base ai 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à nell'aggiunta di regole di speculazione a un sito.

Interesse

Viene utilizzata un'impostazione eagerness per indicare quando devono essere attivate le speculazioni, una funzionalità particolarmente utile per le regole dei documenti:

• immediate:viene utilizzato per eseguire speculazioni il prima possibile, ovvero non appena vengono osservate le regole di speculazione.
• eager: il comportamento è identico a quello dell'impostazione immediate, ma in futuro cercheremo di inserirlo tra immediate e moderate.
• moderate:esegue speculazioni se tieni il puntatore su un link per 200 millisecondi (o sull'evento pointerdown, se è prima, e sui dispositivi mobili in cui non è presente alcun evento hover).
• conservative: si verifica il puntatore o il tocco verso il basso.

Il valore predefinito di eagerness per le regole list è immediate. Le opzioni moderate e conservative possono essere utilizzate per limitare le regole di list agli URL con cui un utente interagisce a un elenco specifico. Tuttavia, 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ò contenere molti URL, devi utilizzare con cautela i valori immediate o eager per le regole document (vedi anche la sezione Limiti di Chrome di seguito).

L'impostazione di eagerness da usare dipende dal tuo sito. Per un sito leggero e statico, creare speculazioni più approfondite può comportare costi minimi ed essere vantaggiosi per gli utenti. I siti con architetture più complesse e payload di pagine più pesanti potrebbero preferire la riduzione degli sprechi attraverso una speculazione meno frequente, fino a quando non ottieni un segnale positivo di intenzione da parte degli utenti al fine di 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 quando si tiene il puntatore sopra il link per 200 millisecondi o sull'evento puntatoredown come implementazione di base ma efficace di regole di speculazione:

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

Precaricamento

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

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

Limiti di Chrome

In Chrome sono in vigore dei limiti per evitare l'uso eccessivo dell'API Speculation Rules:

Le impostazioni moderate e conservative, che dipendono dall'interazione dell'utente, funzionano in modo FIFO (First In, First Out): dopo aver raggiunto il limite, una nuova speculazione farà sì che la 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, con una nuova speculazione dell'URL, che verrà generata la speculazione meno recente. In questo caso la speculazione precedente avrà memorizzato nella cache tutte le risorse memorizzabili nella cache HTTP per quell'URL, quindi la speculazione successiva dovrebbe avere un costo ridotto. Per questo motivo, il limite è impostato sulla soglia modesta pari a 2. Le regole per gli elenchi statici non vengono attivate da un'azione dell'utente e, di conseguenza, hanno un limite più elevato, in quanto il browser non può sapere quali sono e quando sono necessarie.

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

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

• Salva-Dati.
• Risparmio energetico quando la funzionalità è attiva e quando la batteria è in esaurimento.
• Vincoli di memoria.
• Quando l'opzione "Precarica le pagine" viene disattivata (e viene disattivata esplicitamente anche dalle estensioni di Chrome come uBlock Origin).
• Pagine aperte nelle schede in background.

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

Tutte queste condizioni mirano a ridurre l'impatto della sovraspeculazione nei casi in cui sarebbe dannoso 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 un'ampia percentuale di utenti. In alternativa, è possibile utilizzare le regole del documento con moderate o conservative per la speculazione man mano che gli utenti interagiscono con i link.
• Regole di speculazione inserite dinamicamente: potrebbero basarsi sulla logica dell'applicazione, personalizzate per l'utente o su altre euristiche.

Consigliamo a chi preferisce l'inserimento dinamico basato su azioni come il passaggio del mouse o il clic su un link, come molte librerie hanno fatto in passato con <link rel=prefetch>, di esaminare le regole del documento, poiché queste consentono al browser di gestire molti dei tuoi casi d'uso.

Le regole di speculazione possono essere aggiunte nel tag <head> o <body> nel frame principale. Le regole di speculazione nei frame secondari non vengono applicate e le regole di speculazione nelle pagine sottoposte a prerendering vengono applicate solo dopo l'attivazione della pagina.

L'intestazione HTTP Speculation-Rules

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

L'intestazione HTTP Speculation-Rules viene restituita con il documento e punta 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, deve 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 tue 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 link della stessa origine.

Regole di speculazione e APS

Le regole di speculazione sono supportate solo per le navigazioni a pagine intere gestite dal browser e non per le pagine di app a pagina singola (APS) o shell dell'app. Questa architettura non utilizza i recuperi dei documenti, ma effettua recuperi parziali o tramite API di dati o pagine, che vengono poi elaborati e presentati nella pagina corrente. I dati necessari per queste "navigazioni secondarie" possono essere precaricati dall'app al di fuori delle regole di speculazione, ma non possono essere sottoposti a prerendering.

Le regole di speculazione possono essere utilizzate per eseguire il prerendering dell'applicazione stessa da una pagina precedente. Ciò consente di compensare alcuni dei costi di caricamento iniziale aggiuntivi di alcune APS. Tuttavia, non è possibile eseguire il prerendering delle modifiche al percorso all'interno dell'app.

Regole di speculazione di debug

Consulta il post dedicato sul debug delle regole di speculazione per conoscere le nuove funzionalità di Chrome DevTools che forniscono assistenza nella visualizzazione e nel debug di questa nuova API.

Più regole di speculazione

Alla stessa pagina possono essere aggiunte anche più regole di speculazione, che verranno aggiunte alle regole esistenti. Pertanto, i seguenti modi diversi generano tutti il prerendering di one.html e 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 unico insieme di speculationrules

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

Assistenza No-Vary-Search

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 da JavaScript lato client.

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

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

La proposta Ricerca senza Varia consente a un server di specificare parametri che non comportano alcuna differenza rispetto alla risorsa fornita e, pertanto, consente a un browser di riutilizzare le versioni memorizzate in precedenza di un documento che si differenziano solo per questi parametri. Questa funzionalità è supportata in Chrome (e nei browser basati su Chromium) per le speculazioni di navigazione di precaricamento (anche se stiamo cercando di supportarla anche per il prerendering).

Le regole di speculazione supportano l'utilizzo di expects_no_vary_search per indicare dove si prevede che venga restituita un'intestazione HTTP No-Vary-Search. In questo modo eviterai ulteriormente di download non necessari.

<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 /products è uguale per gli ID prodotto 123 e 124. Tuttavia, i contenuti della pagina differiscono in base al rendering lato client utilizzando JavaScript per recuperare i dati di prodotto utilizzando il parametro di ricerca id. L'URL viene quindi precaricato con entusiasmo 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, è possibile che il browser non abbia ricevuto la pagina /products. In questo caso, il browser non sa se conterrà l'intestazione HTTP No-Vary-Search. Il browser ha quindi la possibilità di scegliere se recuperare di nuovo il link o attendere il completamento del precaricamento per verificare 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 all'interno della stessa scheda, ma stiamo lavorando per ridurre questo limite.

Per impostazione predefinita, le speculazioni sono limitate alle pagine della stessa origine. Speculazione di pagine multiorigine dello stesso sito (ad esempio, https://a.example.com potrebbe eseguire il prerendering di una pagina su https://b.example.com). Per utilizzarlo, la pagina speculata (in questo esempio https://b.example.com) deve eseguire l'attivazione 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 dello 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 provenienti dall'utente che ha visitato il sito in precedenza, la speculazione non verrà attivata e verrà mostrato 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, è il prerendering degli URL della stessa origine e il tentativo 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, che si tradurrà in uno spreco di precaricamento che deve essere inviato di nuovo o, peggio ancora, nel caricamento di pagina errato.

Le regole di speculazione non sono supportate per il precaricamento delle pagine controllate dai service worker. Stiamo lavorando per aggiungere questo supporto. Per gli aggiornamenti, segui questo problema del Service worker. Il prerendering è supportato per le pagine controllate dai service worker.

Supporto dell'API Detect Speculation Rules

Puoi utilizzare la funzionalità di rilevamento del supporto dell'API Speculation Rules con 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

Questo è 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);
}

In questa pagina dimostrativa di prerendering puoi visualizzare una demo del prerendering dell'API Speculation Rules utilizzando l'inserimento di JavaScript.

L'inserimento di un elemento <script type = "speculationrules"> direttamente nel DOM utilizzando innerHTML non registra le regole di speculazione per motivi di sicurezza e deve essere aggiunto come mostrato in precedenza. Tuttavia, i contenuti inseriti in modo dinamico utilizzando innerHTML che includono nuovi link verranno scelti dalle regole esistenti nella pagina.

Analogamente, la modifica diretta del riquadro Elements in Chrome DevTools per aggiungere l'elemento <script type = "speculationrules"> non registra le regole di speculazione e lo script per aggiungerlo dinamicamente al DOM deve essere eseguito dalla console per inserire le regole.

Aggiungere regole di speculazione tramite un gestore di tag

Per aggiungere regole speculative utilizzando un gestore di tag come Google Tag Manager (GTM), è necessario che vengano inserite tramite JavaScript, anziché aggiungere direttamente l'elemento <script type = "speculationrules"> tramite GTM per gli stessi motivi citati in precedenza:

Tieni presente che questo esempio utilizza var, in quanto GTM non supporta const.

Annulla regole di speculazione

La rimozione delle regole di speculazione comporterà l'annullamento del prerendering, ma quando ciò è avvenuto, le risorse saranno probabilmente già state spese per avviare il prerendering, quindi è consigliabile non eseguire il prerendering se esiste la possibilità di dover annullare il prerendering.

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 nel criterio Content-Security-Policy di script-src se il sito lo utilizza, utilizzando un hash o un nonce.

È possibile aggiungere un nuovo inline-speculation-rules a script-src per supportare il supporto di elementi <script type="speculationrules"> inseriti da script hash o non ced. Non sono supportate le regole incluse nel codice HTML iniziale, quindi 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 rapido delle pagine, spesso istantaneo. Ciò apporta benefici sia all'utente sia al proprietario del sito, in quanto le pagine sottoposte a prerendering consentono una migliore esperienza utente che altrimenti potrebbe essere difficile da ottenere.

Tuttavia, potrebbero verificarsi casi in cui non vuoi che venga eseguito il prerendering delle pagine, ad esempio quando le pagine cambiano stato, in base alla richiesta iniziale o in base all'esecuzione di JavaScript sulla pagina.

Attiva e disattiva il prerendering in Chrome

Il prerendering viene attivato solo per gli utenti di Chrome con l'opzione "Precarica le pagine" in chrome://settings/performance/. Inoltre, il prerendering è 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

L'intestazione delle pagine precaricate utilizzando l'API Speculation Rules sarà impostata solo su prefetch:

Sec-Purpose: prefetch

I server possono rispondere in base a questa intestazione, per registrare richieste di speculazione, restituire contenuti diversi o impedire l'esecuzione di un prerendering. Se viene restituito un codice di risposta che non ha avuto esito positivo (non 200 o 304), la pagina non verrà sottoposta a prerendering e le pagine di precaricamento verranno ignorate.

Se non vuoi che una determinata pagina venga sottoposta a prerendering, questo è il modo migliore per assicurarti che non succeda. Tuttavia, per offrire l'esperienza migliore, è consigliabile consentire invece 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. Questo può essere usato dalle pagine per prevenire (o ritardare) determinate attività durante il prerendering finché la pagina non viene effettivamente attivata.

Una volta attivato un documento sottoposto a prerendering, anche il valore activationStart di PerformanceNavigationTiming verrà impostato su un intervallo di tempo diverso da zero, che rappresenta il tempo che intercorre tra l'avvio 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:

Quando la pagina viene attivata dall'utente che la visualizza, l'evento prerenderingchange viene inviato su document, che può essere utilizzato per attivare attività che in precedenza verrebbero avviate per impostazione predefinita al caricamento della pagina, ma che si desidera ritardare fino a quando la pagina non viene effettivamente visualizzata dall'utente.

Utilizzando queste API, JavaScript frontend può rilevare e agire in modo appropriato sulle pagine sottoposte a prerendering.

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. Puoi anche misurare le metriche sul rendimento delle pagine usando il monitoraggio degli utenti reali (RUM).

Le pagine devono essere sottoposte a prerendering solo quando è molto probabile che vengano caricate dall'utente. Questo è il motivo per cui le opzioni di prerendering della barra degli indirizzi di Chrome vengono eseguite solo quando esiste una probabilità così elevata (superiore all'80% delle volte).

Tuttavia, in particolare quando utilizzi l'API Speculation Rules, le pagine sottoposte a prerendering potrebbero avere un impatto sull'analisi e i proprietari dei siti potrebbero dover aggiungere altro codice per abilitare solo l'analisi per le pagine sottoposte a prerendering al momento dell'attivazione, poiché non tutti i fornitori di analisi possono eseguire questa operazione per impostazione predefinita.

A questo scopo, puoi utilizzare un Promise che attende l'evento prerenderingchange se è in corso il prerendering di un documento oppure si risolve immediatamente se è ora:

// 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 è ritardare le attività di analisi fino a quando la pagina non viene resa visibile per la prima volta, cosa che copre sia il caso di prerendering sia l'apertura delle schede in background (ad esempio, facendo clic con il tasto destro del mouse e aprendo in una nuova scheda):

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

Sebbene questo possa essere adatto per dati e analisi e casi d'uso simili, in altri casi potresti voler caricare più contenuti per questi casi, quindi utilizzare document.prerendering e prerenderingchange per scegliere come target in modo specifico le pagine di prerendering.

Bloccare altri contenuti durante il prerendering

Le stesse API di cui abbiamo parlato in precedenza possono essere utilizzate per bloccare altri contenuti durante la fase di prerendering. Può trattarsi di parti specifiche di JavaScript o di interi elementi dello script che preferiresti non eseguire durante la fase di prerendering.

Ad esempio, nel seguente script:

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

Puoi modificarlo in un elemento di script inserito dinamicamente che si inserisce solo in base alla funzione whenActivated precedente:

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');

Questo può essere utile per bloccare script distinti che includono dati e analisi o per visualizzare i contenuti in base allo stato o ad altre variabili che possono cambiare durante una visita. Ad esempio, è possibile nascondere tutti i consigli, lo stato di accesso o le icone del carrello della spesa per garantire che vengano visualizzate le informazioni più aggiornate.

Sebbene ciò probabilmente si verifichi più spesso con l'uso del prerendering, queste condizioni sono vere anche per le pagine caricate nelle schede in background menzionate in precedenza (pertanto, è possibile utilizzare la funzione whenFirstVisible al posto di whenActivated).

In molti casi, idealmente lo stato dovrebbe essere controllato anche in caso di modifiche generali a visibilitychange, ad esempio, quando torni a una pagina che è stata visualizzata in background, tutti i contatori del carrello devono essere aggiornati con il numero più recente di articoli nel carrello. Non si tratta quindi di un problema specifico del prerendering, ma solo di rendere più evidente un problema esistente.

Un modo in cui Chrome riduce parte della necessità di eseguire il wrapping manuale di script o funzioni è che alcune API vengono trattenute come accennato in precedenza e inoltre non viene eseguito il rendering degli iframe di terze parti, quindi è necessario trattenere manualmente solo i contenuti oltre a questo.

Misurare le prestazioni

Per misurare le metriche delle prestazioni, i dati e le analisi dovrebbero valutare se è meglio misurarle in base al tempo di attivazione piuttosto che al tempo di caricamento della pagina che le API del browser segnaleranno.

I Core Web Vitals, misurati da Chrome tramite il Chrome User Experience Report, hanno lo scopo di misurare l'esperienza utente. Pertanto, questi vengono misurati in base al tempo di attivazione. Ad esempio, questo comporta, ad esempio, un LCP di 0 secondi, il che dimostra che è un ottimo modo per migliorare i Core Web Vitals.

A partire dalla versione 3.1.0, la libreria web-vitals è stata aggiornata per gestire le navigazioni sottoposte a prerendering allo stesso modo in cui Chrome misura i Core Web Vitals. Questa versione segnala anche le navigazioni sottoposte a prerendering per queste metriche nell'attributo Metric.navigationType, se la pagina è stata sottoposta a prerendering completo o parziale.

Misura i prerendering

Indica se una pagina viene sottoposta a prerendering con una voce activationStart diversa da zero pari a PerformanceNavigationTiming. Questo può essere registrato utilizzando una dimensione personalizzata o un'operazione 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, i tuoi dati e analisi potranno mostrare quante navigazioni vengono sottoposte a prerendering rispetto ad altri tipi di navigazione e puoi anche correlare le metriche delle prestazioni o dell'attività a questi diversi tipi di navigazione. Pagine più veloci significano utenti più soddisfatti, il che può spesso avere un impatto reale sulle misure aziendali, come dimostrano i nostri case study.

Man mano che 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 oppure scoprire perché le pagine non vengono sottoposte a prerendering.

Misura le percentuali di hit

Oltre a misurare l'impatto delle pagine visitate dopo un prerendering, è importante anche misurare quelle che sono state sottoposte a prerendering e non vengono visitate successivamente. Ciò potrebbe implicare un eccessivo prerendering e l'utilizzo di risorse preziose dell'utente con un vantaggio minimo.

Questo valore può essere misurato attivando un evento di analisi quando vengono inserite regole di speculazione, dopo aver verificato che il browser supporti il prerendering utilizzando 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. 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 visualizzazioni di pagina di prerendering effettive. In alternativa, attiva un altro evento al momento dell'attivazione, se questo rende più facile il confronto.

La "percentuale di successi riusciti" può quindi essere approssimata osservando la differenza tra queste due cifre. Per le pagine in cui utilizzi l'API Speculation Rules per eseguire il prerendering delle pagine, puoi modificare le regole in modo appropriato per assicurarti di mantenere un'elevata percentuale di hit e mantenere un equilibrio tra l'utilizzo delle risorse degli utenti come aiuto e l'uso inutile.

Tieni presente che alcune operazioni di prerendering potrebbero essere dovute al prerendering della barra degli indirizzi e non solo alle tue regole di speculazione. Puoi selezionare l'document.referrer (che sarà vuoto per la navigazione nella barra degli indirizzi incluse le navigazioni nella barra degli indirizzi sottoposta a prerendering) se vuoi differenziarle.

Ricordati di controllare anche le pagine senza prerendering, perché ciò potrebbe indicare che non sono idonee per il prerendering, anche dalla barra degli indirizzi. Ciò potrebbe significare che non stai usufruendo di questo miglioramento del rendimento. Il team di Chrome vorrebbe aggiungere altri strumenti per testare l'idoneità al prerendering, forse simili allo strumento di test bfcache, e aggiungere potenzialmente un'API per scoprire il motivo per cui un prerendering non è riuscito.

Impatto sulle estensioni

Leggi il post dedicato su Chrome Extensions: Extending API to support Instant Navigation che descrive in dettaglio alcune considerazioni aggiuntive che gli autori di estensioni potrebbero dover prendere in considerazione per le pagine sottoposte a prerendering.

Feedback

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

Link correlati

• Codelab sulle regole di speculazione
• Debug delle regole di speculazione
• Introduzione a NoState Prefetch
• Specifica dell'API Speculation Rules
• Repository GitHub di speculazione di navigazione
• Estensioni di Chrome: estensione dell'API per supportare la Navigazione istantanea

Ringraziamenti

Immagine in miniatura di Marc-Olivier Jodoin su Unsplash