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 un utente potrebbe visitare.

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 che utilizzava l'indicazione del link rel=prerender è stato ritirato a favore del precaricamento senza stato, che invece recuperava le risorse necessarie per la pagina futura, ma non eseguiva il prerendering completo della pagina né JavaScript. Il precaricamento NoState contribuisce a migliorare le prestazioni della pagina migliorando il caricamento delle risorse, ma non garantisce un caricamento istantaneo della pagina 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 rimarrà in vigore per il precaricamento senza stato, 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 se tieni premuto il cursore sopra 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, se il motore di ricerca lo richiede.
4. I siti possono utilizzare l'API Speculation Rules per indicare a Chrome in modo programmatico quali pagine prerenderizzare. Questa operazione sostituisce la precedente funzionalità di <link rel="prerender"...> e consente ai siti di eseguire il prerendering proattivo di una pagina in base alle regole di speculazione presenti nella pagina. Questi elementi possono esistere in modo statico nelle pagine o essere iniettati dinamicamente da JavaScript in base alle esigenze del proprietario della pagina.

In ognuno di questi casi, un prerendering si comporta come se la pagina fosse stata aperta in una scheda di sfondo invisibile e poi viene "attivata" sostituendo la scheda in primo piano con la pagina preriferita. Se una pagina viene attivata prima del prerendering completo, il suo stato corrente è "in primo piano" e continua a caricarsi, il che significa che puoi comunque avere un buon vantaggio.

Poiché la pagina pre-renderizzata viene aperta in uno stato nascosto, un certo numero di API che causano comportamenti intrusivi (ad esempio i prompt) non vengono attivate in questo stato, ma vengono ritardate fino all'attivazione della pagina. Nei rari casi in cui ciò non sia ancora possibile, il prerendering viene annullato. Il team di Chrome sta lavorando per esporre i motivi dell'annullamento del prerendering come API e per migliorare le funzionalità di DevTools al fine di 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à veloce, ma anche in questo caso 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 LCP quasi nullo, un CLS ridotto (poiché qualsiasi CLS di caricamento si verifica prima della visualizzazione iniziale) e un INP migliorato (poiché il caricamento deve essere completato prima che l'utente interagisca).

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 del prerendering viene spostata nel frame principale e il caricamento continua.

Tuttavia, il prerendering utilizza memoria e larghezza di banda di rete aggiuntive. Fai attenzione a non eseguire un prerendering eccessivo, a discapito delle risorse 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 nei tuoi dati e analisi, consulta la sezione Misurare il rendimento.

Visualizzare le previsioni della 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 un livello di confidenza sufficiente per attivare il prerendering. In questo esempio, digitare "s" fornisce un livello di confidenza ragionevole (ambra), ma una volta digitato "sh", Chrome ha la certezza sufficiente che quasi sempre accedi a https://sheets.google.com.

Questo screenshot è stato acquisito in un'installazione di Chrome relativamente recente e ha escluso le previsioni con confidenza pari a zero, ma se visualizzi i tuoi predittori probabilmente vedrai 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 predittori in base alle tue digitazioni e 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.

L'API Speculation Rules

Per l'opzione di prerendering dell'API Speculation Rules, gli sviluppatori web possono inserire istruzioni JSON nelle loro pagine per informare il browser su quali URL prerenderizzare:

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

Impatienza

Viene utilizzata un'impostazione eagerness per indicare quando devono essere attivate le supposizioni, il che è 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 delle supposizioni se tieni premuto il cursore su un link per 200 millisecondi (o sull'evento pointerdown se si verifica prima e sui dispositivi mobili dove non è presente l'evento hover).
• conservative: indica un evento del cursore o del tocco.

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 a un elenco specifico. Tuttavia, in molti casi, le regole document con una condizione where appropriata potrebbero essere più appropriate.

Il valore eagerness predefinito per le regole document è conservative. Poiché un documento può essere costituito da molti URL, l'utilizzo di immediate o eager per le regole document deve essere usato con cautela (vedi anche la sezione Limiti di Chrome di seguito).

L'impostazione eagerness da utilizzare dipende dal tuo sito. Per un sito statico e leggero, fare più offerte potrebbe avere un costo ridotto ed essere vantaggioso per gli utenti. I siti con architetture più complesse e payload delle pagine più pesanti potrebbero preferire ridurre gli sprechi effettuando meno spesso operazioni di speculazione finché non ricevi un segnale più positivo di intenzione 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 eseguirà il prerendering di un link quando il cursore viene tenuto sopra il link per 200 millisecondi o sull'evento pointerdown come 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 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 impedire 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 il mouse sopra il link di nuovo, il che comporterà la nuova speculazione sull'URL e l'eliminazione della speculazione più vecchia. In questo caso, la speculazione precedente avrà memorizzato nella cache tutte le risorse memorizzabili nella cache HTTP per quell'URL, quindi eseguire un'altra speculazione 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 di immediate e eager sono dinamici, pertanto la rimozione di un elemento di script URL list creerà capacità annullando le speculazioni rimosse.

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

• Salva-Dati.
• Risparmio energetico se attivato e con batteria in esaurimento.
• Vincoli di memoria.
• Quando l'impostazione "Precarica pagine" è disattivata (viene disattivata anche esplicitamente dalle estensioni di Chrome come uBlock Origin).
• Pagine aperte nelle schede in background.

Inoltre, Chrome non esegue il rendering di iframe cross-origin nelle pagine pre-renderizzate fino all'attivazione.

Tutte queste condizioni hanno lo scopo di ridurre l'impatto della sovraspeculazione quando sarebbe 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 in modo statico: ad esempio, un sito di notizie o un blog potrebbe eseguire il prerendering dell'articolo più recente, se spesso è la pagina di navigazione successiva per una grande percentuale di utenti. In alternativa, le regole del documento con moderate o conservative possono essere utilizzate per fare supposizioni quando 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.

A chi preferisce l'inserimento dinamico in base ad azioni come il passaggio del mouse sopra un link o il clic su un link, come molte librerie hanno fatto in passato con <link rel=prefetch>, consigliamo di esaminare le regole del documento, in quanto consentono al browser di gestire molti dei tuoi casi d'uso.

Le regole di speculazione possono essere aggiunte in <head> o in <body> del frame principale. Le regole di speculazione nei frame secondari non vengono applicate e le regole di speculazione nelle pagine pre-renderizzate 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 CDN senza dover modificare i contenuti dei documenti stessi.

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 cross-origin, 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 SPA

Le regole di speculazione sono supportate solo per le navigazioni a pagina intera gestite dal browser e non per le app a pagina singola (APS) o le pagine 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 cosiddette "navigazioni soft" possono essere prerecuperati dall'app al di fuori delle regole di speculazione, ma non possono essere pre-renderizzati.

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

Eseguire il debug delle regole di speculazione

Consulta il post dedicato al debug delle regole di speculazione per scoprire le nuove funzionalità di Chrome DevTools che ti aiutano a visualizzare e eseguire il 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 diversi modi generano il prerendering sia di one.html che 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 all'interno di un insieme di speculationrules

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

Assistenza No-Vary-Search

Quando esegui il pre-caricamento o il pre-rendering di una pagina, alcuni parametri URL (tecnicamente noti come parametri di ricerca) potrebbero non essere importanti per la pagina effettivamente pubblicata dal server e 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 generano 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 potrà 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 comportano differenze nella risorsa pubblicata e, di conseguenza, consente a un browser di riutilizzare le versioni memorizzate nella cache in precedenza 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 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 è previsto che venga restituita un'intestazione HTTP No-Vary-Search. In questo modo puoi evitare ulteriori 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 è lo stesso per entrambi gli ID prodotto 123 e 124. Tuttavia, i contenuti della pagina alla fine differiscono in base al rendering lato client che utilizza 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, 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 ha quindi la possibilità di recuperare di nuovo il link o di attendere il completamento del pre-caricamento 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.

Restrizioni delle regole di speculazione e miglioramenti futuri

Le regole di speculazione sono limitate alle pagine aperte all'interno della stessa scheda, ma ci stiamo adoperando per ridurre questo limite.

Per impostazione predefinita, le speculazioni sono limitate alle pagine della stessa origine. Pagina di speculazione cross-origin nello 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 di speculazione (https://b.example.com in questo esempio) deve essere attivata includendo un'intestazione HTTP Supports-Loading-Mode: credentialed-prerender, altrimenti Chrome annullerà la speculazione.

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

Le regole di speculazione supportano già i precaricamenti cross-origin, ma sempre solo quando non esistono cookie per il dominio cross-origin. Se esistono cookie dell'utente che ha visitato il sito in precedenza, la speculazione non verrà attivata e verrà visualizzato un errore in DevTools.

Date le attuali limitazioni, un pattern che può migliorare le esperienze degli utenti sia per i link interni che per quelli esterni, se possibile, è prerenderizzare gli URL dello stesso dominio e tentare di precaricare gli URL cross-origin:

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

La limitazione che impedisce le speculazioni cross-origin per i link cross-origin per impostazione predefinita è necessaria per la sicurezza. Si tratta di un miglioramento rispetto a <link rel="prefetch"> per le destinazioni cross-origin che non inviano cookie, ma tentano comunque il prefetch, il che comporterà un prefetch sprecato che deve essere inviato di nuovo o, peggio ancora, il caricamento errato della pagina.

Le regole di speculazione non sono supportate per il pre-caricamento delle pagine controllate dai service worker. Stiamo lavorando per aggiungere questo supporto. Per gli aggiornamenti, segui questo problema relativo al servizio di assistenza. Il prerendering è supportato per le pagine controllate da 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.');
}

Aggiungere 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);
}

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

Se inserisci un elemento <script type = "speculationrules"> direttamente nel DOM utilizzando innerHTML, le regole di speculazione non verranno registrate per motivi di sicurezza e devono essere aggiunte 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 Elementi in Strumenti per sviluppatori di Chrome per aggiungere l'elemento <script type = "speculationrules"> non registra le regole di speculazione, ma lo script per aggiungerlo dinamicamente al DOM deve essere eseguito dalla console per inserire le regole.

Aggiungere regole di speculazione tramite un tag manager

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

Tieni presente che questo esempio utilizza var perché GTM non supporta const.

Annullare le regole di speculazione

La rimozione delle regole di speculazione comporterà l'annullamento del prerendering, ma, a questo punto, è probabile che le risorse siano già state spese per avviare il prerendering, pertanto è consigliabile non eseguire il prerendering se è probabile che sia necessario annullarlo.

Regole sulla speculazione e norme sulla 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 nell'HTML iniziale, pertanto le regole devono essere iniettate da JavaScript per i siti che utilizzano un CSP rigoroso.

Rileva e disattiva il prerendering

In genere, il prerendering è un'esperienza positiva per gli utenti perché consente di visualizzare rapidamente le pagine, spesso in modo istantaneo. Questo è vantaggioso sia per l'utente sia per il proprietario del sito, poiché le pagine pre-renderizzate consentono un'esperienza utente migliore che altrimenti potrebbe essere difficile da ottenere.

Tuttavia, potrebbero esserci 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 nella pagina.

Attivare e disattivare il prerendering in Chrome

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

Rilevare e disattivare il prerendering lato server

Le pagine pre-renderizzate verranno inviate con l'intestazione HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

Per le pagine prelevate utilizzando l'API Speculation Rules, questa intestazione sarà impostata solo su prefetch:

Sec-Purpose: prefetch

I server possono rispondere in base a questa intestazione per registrare le richieste di speculazione, restituire contenuti diversi o impedire un prerendering. Se viene restituito un codice di risposta finale non positivo, ovvero non compreso nell'intervallo 200-299 dopo i reindirizzamenti, la pagina non verrà preriferita e qualsiasi pagina di prefetch verrà ignorata. Tieni inoltre presente che le risposte 204 e 205 non sono valide per il prerendering, ma sono valide per il prefetch.

Se non vuoi che una determinata pagina venga precompilata, restituire un codice di risposta diverso da 2XX (ad esempio 503) è il modo migliore per assicurarti che ciò non accada. Tuttavia, per offrire la migliore esperienza, ti consigliamo di consentire il prerendering, ma di ritardare le azioni che devono 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 utilizzato dalle pagine per impedire o ritardare determinate attività durante il prerendering finché la pagina non viene effettivamente attivata.

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

Puoi avere una funzione per verificare la presenza di pagine prerenderizzate e prerenderizzate 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 pre-riferita (completamente 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 a document, che può essere utilizzato per attivare le attività che in precedenza sarebbero state avviate per impostazione predefinita al caricamento della pagina, ma che vuoi ritardare fino a quando la pagina non viene effettivamente visualizzata dall'utente.

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

Impatto sull'analisi

Analytics vengono utilizzati 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 dei real user (RUM).

Le pagine devono essere pre-elaborate solo quando è elevata la probabilità che vengano caricate dall'utente. Questo è il motivo per cui le opzioni di prerendering della barra degli indirizzi di Chrome vengono applicate solo quando esiste una probabilità così elevata (più dell'80% delle volte).

Tuttavia, in particolare quando si utilizza l'API Speculation Rules, le pagine pre-renderizzate potrebbero influire su Analytics e i proprietari di siti potrebbero dover aggiungere codice aggiuntivo per attivare l'analisi solo per le pagine pre-renderizzate al momento dell'attivazione, poiché non tutti i fornitori di analisi potrebbero farlo 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 consiste nel ritardare le attività di analisi fino a quando la pagina non viene visualizzata per la prima volta, il che coprirebbe sia il caso di prerendering sia l'apertura delle schede in background (ad esempio, con il clic destro e l'apertura 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 questa opzione possa essere utile per casi d'uso di analisi e simili, in altri casi potresti voler caricare più contenuti per questi casi e, di conseguenza, potresti utilizzare document.prerendering e prerenderingchange per scegliere come target specifico le pagine di prerendering.

Non mostrare altri contenuti durante il pre-rendering

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

Ad esempio, con questo script:

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

Puoi sostituirlo con un elemento script inserito dinamicamente che viene inserito 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');

Questa opzione può essere utile per bloccare script distinti che includono dati e analisi o per eseguire il rendering dei contenuti in base allo stato o ad altre variabili che possono cambiare durante il periodo di una visita. Ad esempio, i consigli, lo stato di accesso o le icone del carrello degli acquisti potrebbero essere trattenuti per garantire la presentazione delle informazioni più aggiornate.

Sebbene questo problema sia più probabile che si verifichi con l'utilizzo del prerendering, queste condizioni valgono anche per le pagine caricate nelle schede in background menzionate in precedenza (quindi la funzione whenFirstVisible potrebbe essere utilizzata al posto di whenActivated).

In molti casi, lo stato dovrebbe idealmente essere controllato anche in caso di modifiche generali visibilitychange, ad esempio quando si torna a una pagina in background, tutti i contatori del carrello degli acquisti devono essere aggiornati con il numero più recente di articoli nel carrello. Pertanto, non si tratta di un problema specifico del prerendering, ma il prerendering rende più evidente un problema esistente.

Un modo in cui Chrome riduce la necessità di eseguire il wrapping manuale di script o funzioni è che alcune API vengono bloccate come accennato in precedenza e anche gli iframe di terze parti non vengono visualizzati, quindi sono solo i contenuti aggiuntivi che devono essere bloccati manualmente.

Misurare le prestazioni

Per misurare le metriche sul rendimento, gli analisti devono valutare se è meglio misurarle in base al momento dell'attivazione anziché al tempo di caricamento della pagina registrato dalle API del browser.

I Core Web Vitals, misurati da Chrome tramite il Chrome User Experience Report, hanno lo scopo di misurare l'esperienza utente. Pertanto, vengono misurate in base al momento dell'attivazione. Ad esempio, questo comporta spesso 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.

Misurare i pre-rendering

Indica se una pagina viene sottoposta a prerendering con una voce activationStart diversa da zero pari a PerformanceNavigationTiming. Questi dati possono essere registrati utilizzando una dimensione personalizzata o un'altra metrica simile quando vengono registrate 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, gli analytics potranno mostrare quante navigazioni vengono pre-renderizzate rispetto ad altri tipi di navigazione e potrai anche correlare eventuali metriche sul rendimento o metriche aziendali 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 mostrano i nostri case study.

Mentre 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 scoprire perché le pagine non vengono prerenderizzate.

Misurare le percentuali di hit

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

Questo può essere misurato attivando un evento di analisi quando vengono inserite le 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 il fatto che sia stato richiesto un prerendering non indica che il prerendering sia stato avviato o completato, in quanto, come indicato in precedenza, il prerendering è un suggerimento per il browser e quest'ultimo potrebbe scegliere di non eseguire il prerendering delle pagine in base alle impostazioni dell'utente, all'utilizzo corrente della memoria o ad altre strategie di euristica.

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

Il "tasso di hit riusciti" può quindi essere approssimato osservando la differenza tra queste due cifre. Per le pagine in cui utilizzi l'API Speculation Rules per il prerendering, puoi modificare le regole in modo appropriato per mantenere un tasso di hit elevato e mantenere il giusto equilibrio tra l'utilizzo delle risorse degli utenti per aiutarli e l'utilizzo non necessario.

Tieni presente che potrebbe essere in corso un prerendering parziale a causa del prerendering della barra degli indirizzi e non solo delle regole di speculazione. Puoi controllare document.referrer (che sarà vuoto per la navigazione nella barra degli indirizzi, incluse le navigazioni nella barra degli indirizzi pre-renderizzate) se vuoi distinguerli.

Ricorda di esaminare anche le pagine senza prerendering, in quanto 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 attivo da parte del team di Chrome e sono previsti molti piani per espandere l'ambito di ciò che è stato reso disponibile nella release di Chrome 108. Accogliamo con favore qualsiasi feedback sul repository GitHub o tramite il nostro tracker dei problemi e non vediamo l'ora di ascoltare e condividere casi d'uso di questa nuova entusiasmante API.

Link correlati

• Codelab sulle Regole di speculazione
• Debug delle regole di speculazione
• Introduzione a NoState Prefetch
• Specifica dell'API Regole di scommessa
• Il repository GitHub di Navigational speculation
• Estensioni di Chrome: estensione dell'API per supportare la Navigazione istantanea

Ringraziamenti

Immagine in miniatura di Marc-Olivier Jodoin su Unsplash