Cache back-forward

Ottimizza le tue pagine per un caricamento istantaneo quando utilizzi i pulsanti Avanti e Indietro del browser.

Philip Walton

Barry Pollard

La cache back-forward (o bfcache) è un'ottimizzazione del browser che consente una navigazione istantanea in avanti e indietro. Migliora notevolmente l'esperienza di navigazione per gli utenti, soprattutto quelli con reti o dispositivi più lenti.

Per gli sviluppatori web è fondamentale capire come ottimizzare le pagine per bfcache in tutti i browser, in modo che gli utenti possano trarne vantaggio.

Compatibilità del browser

bfcache è supportata da Firefox e Safari da molti anni, sia su computer che su dispositivi mobili.

A partire dalla versione 86, Chrome abilitava la cache back-forward per le navigazioni tra siti su Android per una piccola percentuale di utenti. Nelle release successive è stato gradualmente implementato supporto aggiuntivo. Dalla versione 96, la cache bfcache è attiva per tutti gli utenti di Chrome su computer e dispositivi mobili.

nozioni di base su bfcache

bfcache è una cache in memoria che memorizza uno snapshot completo di una pagina (incluso l'heap JavaScript) durante l'uscita dell'utente. Con l'intera pagina in memoria, il browser può ripristinarla in modo facile e veloce se l'utente decide di tornare.

Quante volte hai visitato un sito web e fatto clic su un link per passare a un'altra pagina, per poi renderti conto che non era ciò che volevi e fare clic sul pulsante Indietro? In quel momento, bfcache può fare un'enorme differenza sulla velocità di caricamento della pagina precedente:

Guarda questo video sulla cache back-forward per comprendere quanto può accelerare le navigazioni:

Nel video precedente, l'esempio con bfcache è un po' più veloce rispetto all'esempio senza.

bfcache non solo velocizza la navigazione, ma riduce anche l'utilizzo dei dati, in quanto le risorse non devono essere scaricate di nuovo.

I dati sull'utilizzo di Chrome indicano che 1 navigazione su 10 su computer e 1 su 5 su dispositivi mobili è andata indietro o avanti. Con bfcache attivata, i browser potrebbero eliminare il trasferimento di dati e il tempo di caricamento di miliardi di pagine web ogni giorno.

Come funziona la "cache"

La "cache" utilizzata da bfcache è diversa dalla cache HTTP (utile anche per velocizzare le navigazioni ripetute). La bfcache è un'istantanea dell'intera pagina in memoria (incluso l'heap JavaScript), mentre la cache HTTP contiene solo le risposte per le richieste effettuate in precedenza. Poiché è piuttosto raro che tutte le richieste necessarie per caricare una pagina possano essere soddisfatte dalla cache HTTP, le visite ripetute utilizzando i ripristini di bfcache sono sempre più veloci anche delle navigazioni non bfcache più ottimizzate.

La creazione di uno snapshot di una pagina in memoria, tuttavia, comporta un certo grado di complessità in termini di conservazione del codice in corso. Ad esempio, come gestisci le chiamate setTimeout() in cui viene raggiunto il timeout mentre la pagina si trova nella cache back-forward?

La risposta è che i browser mettono in pausa l'esecuzione di eventuali timer in sospeso o promesse irrisolte, ovvero tutte le attività in sospeso nelle code di attività JavaScript, e ripristinano le attività di elaborazione quando (o se) la pagina viene ripristinata dalla cache back-forward.

In alcuni casi è a basso rischio (ad esempio, timeout o promesse), ma in altri casi potrebbe portare a un comportamento molto poco chiaro o imprevisto. Ad esempio, se il browser mette in pausa un'attività richiesta nell'ambito di una transazione IndexedDB, potrebbe influire su altre schede aperte nella stessa origine (dal momento che agli stessi database IndexedDB è possibile accedere da più schede contemporaneamente). Di conseguenza, i browser generalmente non tentano di memorizzare nella cache le pagine nel mezzo di una transazione IndexedDB o di utilizzare API che potrebbero influire su altre pagine.

Per ulteriori dettagli su come l'utilizzo diverso delle API influisce sull'idoneità alla cache back-forward di una pagina, consulta la sezione Ottimizzare le pagine per la cache back-forward di seguito.

bfcache e app a pagina singola (SPA)

La cache back-forward funziona con le navigazioni gestite dal browser. Pertanto, non funziona con le cosiddette "navigazioni soft " all'interno di una SPA, ma uno dei principali punti di forza di una SPA è che quei tipi di navigazione dovrebbero essere comunque veloci. Tuttavia, la bfcache può essere sicuramente utile quando si torna a un'APS anziché eseguire una reinizializzazione completa dell'app dall'inizio.

API per osservare la cache back-forward

Sebbene bfcache sia un'ottimizzazione automatica dei browser, è comunque importante che gli sviluppatori sappiano quando viene eseguita, in modo da ottimizzare le pagine e regolare eventuali metriche o misurazioni delle prestazioni di conseguenza.

Gli eventi principali utilizzati per osservare la cache bfcache sono gli eventi di transizione delle pagine pageshow e pagehide, che esistono finché bfcache è supportata e sono supportati in quasi tutti i browser in uso oggi.

Vengono inviati anche i più recenti eventi Ciclo di vita della pagina, freeze e resume, quando le pagine entrano o escono dalla cache back-forward, nonché in altre situazioni. Ad esempio, quando una scheda in background viene bloccata per ridurre al minimo l'utilizzo della CPU. Nota: al momento gli eventi del ciclo di vita delle pagine sono supportati solo nei browser basati su Chromium.

Osserva quando una pagina viene ripristinata dalla cache back-forward

L'evento pageshow viene attivato subito dopo l'evento load durante il caricamento iniziale della pagina e ogni volta che viene ripristinata dalla cache back-forward. L'evento pageshow ha una proprietà persisted che sarà true se la pagina è stata ripristinata da bfcache (e false in caso contrario). Puoi utilizzare la proprietà persisted per distinguere i normali caricamenti delle pagine dai ripristini della cache back-forward. Ad esempio:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

Nei browser che supportano l'API Page Lifecycle, l'evento resume viene attivato anche quando le pagine vengono ripristinate dalla cache back-forward (immediatamente prima dell'evento pageshow), ma anche quando un utente visita di nuovo una scheda in background bloccata. Se vuoi aggiornare lo stato di una pagina dopo che è stata bloccata (incluse le pagine nella cache back-forward), puoi utilizzare l'evento resume, ma se vuoi misurare la percentuale di hit della cache del sito per il tuo sito devi usare l'evento pageshow. In alcuni casi, potresti dover utilizzare entrambi.

Osserva quando una pagina inserisce bfcache

L'evento pagehide è la controparte dell'evento pageshow. L'evento pageshow viene attivato quando una pagina viene caricata normalmente o ripristinata dalla cache back-forward. L'evento pagehide viene attivato quando la pagina viene scaricata normalmente o quando il browser tenta di inserirla nella cache back-forward.

L'evento pagehide ha anche una proprietà persisted e, se è false, puoi essere certo che una pagina non verrà inserita nella cache back-forward. Tuttavia, se la proprietà persisted è true, non garantisce che una pagina verrà memorizzata nella cache. Significa che il browser intends a memorizzare la pagina nella cache, ma potrebbero esserci fattori che ne impediscono la memorizzazione.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

Analogamente, l'evento freeze viene attivato subito dopo l'evento pagehide (se la proprietà persisted dell'evento è true), ma anche in questo caso significa solo che il browser intends a memorizzare la pagina nella cache. Potrebbe essere ancora necessario eliminarlo per una serie di motivi spiegati di seguito.

Ottimizza le tue pagine per la cache back-forward

Non tutte le pagine vengono memorizzate nella cache back-forward e, anche se una pagina viene archiviata al suo interno, non ci rimangono per sempre. È fondamentale che gli sviluppatori comprendano cosa rende le pagine idonee (e non idonee) per la cache back-forward per massimizzare i tassi di successo della cache.

Le seguenti sezioni descrivono le best practice per fare in modo che il browser riesca a memorizzare le pagine con la massima probabilità.

Non usare mai l'evento unload

Il modo più importante per ottimizzare la cache back-forward in tutti i browser è non utilizzare mai l'evento unload. Mai!

L'evento unload è problematico per i browser perché è precedente alla bfcache e molte pagine su internet funzionano partendo dal presupposto (ragionevole) che una pagina non continuerà a esistere dopo l'attivazione dell'evento unload. Questo rappresenta una sfida perché molte di queste pagine sono state anche create partendo dal presupposto che l'evento unload si attiva ogni volta che un utente esce dalla pagina, il che non è più vero (e non è così da molto tempo).

I browser, per questo motivo, devono scegliere tra qualcosa che possa migliorare l'esperienza utente, ma che potrebbero anche rischiare di rompere la pagina.

Sui computer, Chrome e Firefox hanno scelto di rendere le pagine non idonee per la cache back-forward se aggiungono un ascolto unload, che è meno rischioso ma rende non idonee molte pagine. Safari tenterà di memorizzare nella cache alcune pagine con un listener di eventi unload, ma per ridurre il potenziale interruzione non eseguirà l'evento unload quando un utente abbandona la pagina, il che rende l'evento molto inaffidabile.

Sui dispositivi mobili, Chrome e Safari tenteranno di memorizzare nella cache le pagine con un listener di eventi unload poiché il rischio di interruzione è inferiore perché l'evento unload è sempre stato estremamente inaffidabile sui dispositivi mobili. Firefox considera le pagine che utilizzano unload non idonee per la cache back-forward, ad eccezione di iOS, che richiede a tutti i browser di utilizzare il motore di rendering WebKit, e si comporta quindi come Safari.

Anziché utilizzare l'evento unload, usa l'evento pagehide. L'evento pagehide si attiva in tutti i casi in cui l'evento unload si attiva attualmente e anche quando una pagina viene inserita nella cache back-forward.

Infatti, Lighthouse prevede un controllo no-unload-listeners che avvisa gli sviluppatori se qualsiasi codice JavaScript nelle loro pagine (incluso quello delle librerie di terze parti) aggiunge un listener di eventi unload.

A causa della sua inaffidabilità e dell'impatto sulle prestazioni di bfcache, Chrome sta cercando di deprecare l'evento unload.

Utilizza le norme di autorizzazione per impedire l'utilizzo dei gestori dell'unload in una pagina

I siti che non utilizzano gestori di eventi unload possono assicurarsi che non vengano aggiunti utilizzando un Criterio di autorizzazione di Chrome 115.

Permission-Policy: unload()

In questo modo si evita che terze parti o estensioni rallentino il sito aggiungendo gestori dell'unload e rendendo il sito non idoneo per la cache back-forward.

Aggiungi solo beforeunload listener in modo condizionale

L'evento beforeunload non renderà le tue pagine non idonee per la cache back-forward nei browser moderni, ma in precedenza lo faceva ed è ancora inaffidabile, quindi evita di utilizzarlo a meno che non sia assolutamente necessario.

Tuttavia, a differenza dell'evento unload, esistono utilizzi legittimi per beforeunload. Ad esempio, se vuoi avvisare l'utente che ha modifiche non salvate, perderà se lascia la pagina. In questo caso, ti consigliamo di aggiungere listener beforeunload solo quando un utente presenta modifiche non salvate e poi di rimuoverli immediatamente dopo il salvataggio delle modifiche non salvate.

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

Riduci al minimo l'utilizzo di Cache-Control: no-store

Cache-Control: no-store è un'intestazione HTTP che i server web possono impostare sulle risposte per indicare al browser di non memorizzare la risposta in una cache HTTP. Deve essere utilizzato per le risorse contenenti informazioni sensibili sugli utenti, ad esempio le pagine protette da login.

Sebbene bfcache non sia una cache HTTP, storicamente quando Cache-Control: no-store è impostato sulla risorsa della pagina stessa (a differenza di qualsiasi risorsa secondaria), i browser hanno scelto di non archiviare la pagina nella cache back-forward. È in corso la modifica di questo comportamento in Chrome al fine di garantire la tutela della privacy, ma al momento le pagine che utilizzano Cache-Control: no-store non sono idonee per la cache back-forward.

Poiché Cache-Control: no-store limita l'idoneità di una pagina per la cache back-forward, la memorizzazione nella cache di qualsiasi tipo non è mai appropriata per le pagine che contengono informazioni sensibili.

Per le pagine in cui vuoi pubblicare sempre contenuti aggiornati e che non includono informazioni sensibili, utilizza Cache-Control: no-cache o Cache-Control: max-age=0. Queste istruzioni indicano al browser di riconvalidare i contenuti prima di pubblicarli e non influiscono sull'idoneità alla cache back-forward di una pagina.

Tieni presente che, quando una pagina viene ripristinata dalla cache back-forward, viene ripristinata dalla memoria, non dalla cache HTTP. Di conseguenza, istruzioni come Cache-Control: no-cache o Cache-Control: max-age=0 non vengono prese in considerazione e non avviene alcuna riconvalida prima che i contenuti vengano mostrati all'utente.

Si tratta comunque probabilmente di un'esperienza utente migliore, poiché i ripristini di bfcache sono istantanei e, poiché le pagine non rimangono molto a lungo nella cache back-forward, è improbabile che i contenuti siano obsoleti. Tuttavia, se i tuoi contenuti cambiano minuto per minuto, puoi recuperare eventuali aggiornamenti utilizzando l'evento pageshow, come descritto nella sezione successiva.

Aggiorna dati inattivi o sensibili dopo il ripristino della cache back-forward

Se il tuo sito mantiene lo stato dell'utente, in particolare eventuali informazioni sensibili dell'utente, tali dati devono essere aggiornati o cancellati dopo che una pagina viene ripristinata dalla cache back-forward.

Ad esempio, se un utente apre una pagina di pagamento e poi aggiorna il carrello degli acquisti, una navigazione a ritroso potrebbe esporre informazioni obsolete se una pagina inattiva viene ripristinata dalla cache back-forward.

Un altro esempio critico è quando un utente si disconnette da un sito su un computer pubblico e l'utente successivo fa clic sul pulsante Indietro. Ciò potrebbe esporre i dati privati che l'utente supponeva siano stati cancellati al momento dell'uscita.

Per evitare situazioni come questa, è consigliabile aggiornare sempre la pagina dopo un evento pageshow se event.persisted è true:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

Anche se idealmente aggiorneresti i contenuti esistenti, ma per alcune modifiche potresti voler forzare un ricaricamento completo. Il seguente codice verifica la presenza di un cookie specifico del sito nell'evento pageshow e viene ricaricato se il cookie non viene trovato:

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie/)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

Un ricaricamento offre il vantaggio di conservare la cronologia (per consentire le navigazioni in avanti), ma in alcuni casi potrebbe essere più appropriato un reindirizzamento.

Ripristino degli annunci e della cache back-forward

Si potrebbe avere la tentazione di evitare l'uso di bfcache per pubblicare un nuovo insieme di annunci in ogni navigazione back-forward. Tuttavia, oltre ad avere un impatto sul rendimento, è discutibile se un simile comportamento porti a un migliore coinvolgimento con gli annunci. Gli utenti potrebbero avere notato un annuncio su cui intendevano tornare fare clic, ma non sono stati in grado di ricaricarlo anziché ripristinare dalla cache back-forward. Testare questo scenario, idealmente con un test A/B, è importante prima di fare ipotesi.

Per i siti che vogliono aggiornare gli annunci al momento del ripristino di bfcache, è possibile aggiornare solo gli annunci nell'evento pageshow quando event.persisted è true, senza influire sulle prestazioni della pagina. Verifica con il tuo fornitore di annunci, ma ecco un esempio di come eseguire questa operazione con il tag per la pubblicazione di Google.

Evita riferimenti a window.opener

Nei browser meno recenti, se una pagina è stata aperta utilizzando window.open() da un link con target=_blank, senza specificare rel="noopener", la pagina di apertura avrà un riferimento all'oggetto finestra della pagina aperta.

Oltre a rappresentare un rischio per la sicurezza, una pagina con un riferimento window.opener non nullo non può essere inserita in sicurezza nella cache back-forward perché ciò potrebbe interrompere le pagine che tentano di accedervi.

Di conseguenza, è meglio evitare di creare riferimenti a window.opener. Puoi farlo utilizzando rel="noopener" quando possibile (nota che ora è l'impostazione predefinita in tutti i browser moderni). Se il tuo sito richiede l'apertura di una finestra e il controllo tramite window.postMessage() o facendo riferimento direttamente all'oggetto finestra, né la finestra aperta né l'elemento di apertura saranno idonei per la cache back-forward.

Chiudi sempre le connessioni aperte prima che l'utente esca dalla pagina

Come accennato in precedenza, quando una pagina viene inserita nella cache back-forward tutte le attività JavaScript pianificate vengono messe in pausa e poi riprese quando la pagina viene estratta dalla cache.

Se queste attività JavaScript pianificate accedono solo alle API DOM (o ad altre API isolate solo nella pagina corrente), la messa in pausa di queste attività mentre la pagina non è visibile all'utente non causerà alcun problema.

Tuttavia, se queste attività sono connesse ad API accessibili anche da altre pagine nella stessa origine (ad esempio: IndexedDB, Web Lock, WebSocket e così via), questo può rappresentare un problema perché la messa in pausa di queste attività potrebbe impedire l'esecuzione del codice in altre schede.

Di conseguenza, alcuni browser non tenteranno di inserire una pagina in bfcache nei seguenti scenari:

• Pagine con una connessione IndexedDB aperta
• Pagine con fetch() o XMLHttpRequest in corso
• Pagine con una connessione WebSocket o WebRTC aperta

Se la tua pagina utilizza una di queste API, ti consigliamo di chiudere sempre le connessioni e di rimuovere o scollegare gli osservatori durante l'evento pagehide o freeze. In questo modo il browser potrà memorizzare nella cache la pagina in modo sicuro senza il rischio che influisca sulle altre schede aperte.

Quindi, se la pagina viene ripristinata dalla cache back-forward, puoi riaprirla o riconnetterti a queste API (nell'evento pageshow o resume).

L'esempio seguente mostra come assicurarsi che le pagine siano idonee per la cache back-forward quando si utilizza IndexedDB chiudendo una connessione aperta nell'elenco degli eventi pagehide:

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user is leaving.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

Verifica che le pagine possano essere memorizzate nella cache

Chrome DevTools può aiutarti a testare le tue pagine per assicurarti che siano ottimizzate per la cache back-forward e identificare eventuali problemi che potrebbero impedirne l'idoneità.

Per testare una pagina specifica, aprila in Chrome, quindi, in DevTools, vai ad Applicazione > Cache back-forward. Successivamente, fai clic sul pulsante Esegui test e DevTools tenterà di uscire e tornare indietro per determinare se è possibile ripristinare la pagina dalla cache back-forward.

Se l'operazione va a buon fine, nel riquadro verrà visualizzato il messaggio "Ripristinato dalla cache back-forward":

Se l'operazione non va a buon fine, il riquadro indicherà che la pagina non è stata ripristinata e il motivo.

Il motivo per cui puoi risolvere il problema, in qualità di sviluppatore, è indicato:

Nello screenshot riportato sopra, l'uso di un listener di eventi unload impedisce che la pagina sia idonea per la cache back-forward. Puoi risolvere il problema passando da unload all'utilizzo di pagehide:

window.addEventListener('unload', ...);

window.addEventListener('pagehide', ...);

Lighthouse 10.0 ha anche aggiunto un controllo della cache back-forward, che esegue un test simile a quello di DevTools e fornisce anche i motivi per cui la pagina non è idonea se il controllo non va a buon fine. Per ulteriori informazioni, consulta la documentazione relativa al controllo della cache bfcache.

In che modo la cache back-forward influisce sull'analisi e sulla misurazione delle prestazioni

Se monitori le visite al tuo sito con uno strumento di analisi, probabilmente noterai una diminuzione del numero totale di visualizzazioni di pagina registrate poiché Chrome continua ad attivare la cache back-forward per un numero maggiore di utenti.

Infatti, probabilmente stai già sottostimando le visualizzazioni di pagina da altri browser che implementano la cache back-forward, in quanto la maggior parte delle librerie di analisi più diffuse non monitora i ripristini di bfcache come nuove visualizzazioni di pagina.

Se non vuoi che il conteggio delle visualizzazioni di pagina diminuisca perché Chrome ha attivato bfcache, puoi segnalare i ripristini di bfcache come visualizzazioni di pagina (opzione consigliata) ascoltando l'evento pageshow e controllando la proprietà persisted.

L'esempio seguente mostra come eseguire questa operazione con Google Analytics. La logica dovrebbe essere simile per altri strumenti di analisi:

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

Misurazione del rapporto di successo della cache back-forward

Puoi inoltre controllare se è stata utilizzata la bfcache per identificare le pagine che non la utilizzano. A questo scopo, puoi misurare il tipo di navigazione per i caricamenti pagina:

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

Osservando il rapporto tra navigazioni back_forward e back_forward_cache, è possibile calcolare il rapporto della cache back-forward.

È importante capire che esistono diversi scenari, al di fuori del controllo dei proprietari del sito, in cui una navigazione Indietro/Avanti non utilizza la cache back-forward, tra cui:

• Quando l'utente chiude il browser e lo riavvia
• Quando l'utente duplica una scheda.
• Quando l'utente chiude una scheda e la apre.

In alcuni di questi casi, il tipo di navigazione originale potrebbe essere mantenuto da alcuni browser e quindi potrebbe mostrare un tipo di back_forward nonostante non si tratti di navigazioni Indietro/Avanti.

Anche senza queste esclusioni, la cache back-forward verrà eliminata dopo un determinato periodo di tempo per risparmiare memoria.

Pertanto, i proprietari di siti web non dovrebbero aspettarsi un rapporto di hit dalla cache del 100% per tutte le navigazioni back_forward. Tuttavia, misurare il rapporto può essere utile per identificare le pagine in cui la pagina stessa impedisce l'utilizzo della cache bfcache per un'elevata percentuale di navigazioni avanti e indietro.

Il team di Chrome sta lavorando a un'API NotRestoredReasons per contribuire a spiegare i motivi per cui la bfcache non è stata utilizzata per aiutare gli sviluppatori a capire il motivo per cui la cache non è stata utilizzata e se si tratta di qualcosa su cui possono lavorare per migliorare i loro siti.

Misurazione del rendimento

Inoltre, la cache bfcache può influire negativamente sulle metriche sulle prestazioni raccolte sul campo, in particolare sulle metriche che misurano i tempi di caricamento della pagina.

Poiché le navigazioni bfcache ripristinano una pagina esistente anziché avviare un nuovo caricamento pagina, il numero totale di caricamenti pagina raccolti diminuirà quando questa funzionalità è abilitata. L'aspetto fondamentale, tuttavia, è che i caricamenti di pagina, che vengono sostituiti dai ripristini di bfcache, sono probabilmente stati tra i caricamenti di pagina più veloci nel tuo set di dati. Questo perché le navigazioni avanti e indietro, per definizione, sono visite ripetute e i caricamenti di pagine ripetute sono generalmente più veloci dei caricamenti delle pagine dei nuovi visitatori (a causa della memorizzazione nella cache HTTP, come indicato in precedenza).

Il risultato è un minor caricamento delle pagine nel set di dati, che probabilmente danneggerà la distribuzione più lentamente, nonostante le prestazioni sperimentate dall'utente siano probabilmente migliorate.

Esistono diversi modi per risolvere questo problema. Uno è annotare tutte le metriche di caricamento pagina con il rispettivo tipo di navigazione: navigate, reload, back_forward o prerender. In questo modo, potrai continuare a monitorare le prestazioni all'interno di questi tipi di navigazione, anche se la distribuzione complessiva risulta negativa. Questo approccio è consigliato per le metriche relative al caricamento delle pagine non incentrate sull'utente come Time to First Byte (TTFB).

Per le metriche incentrate sugli utenti come i Segnali web essenziali, un'opzione migliore è segnalare un valore che rappresenti in modo più accurato l'esperienza utente.

Impatto sui Segnali web essenziali

I Segnali web essenziali misurano l'esperienza utente di una pagina web in diverse dimensioni (velocità di caricamento, interattività, stabilità visiva). Poiché gli utenti riscontrano i ripristini della cache back-forward come navigazioni più veloci rispetto ai caricamenti tradizionali delle pagine, è importante che le metriche di Segnali web essenziali riflettano questa situazione. Dopotutto, a un utente non importa se la cache bfcache è stata attivata o meno, ma solo che la navigazione è stata veloce.

Strumenti come il Report sull'esperienza utente di Chrome, che raccolgono e generano report sulle metriche di Segnali web essenziali, trattano i ripristini della cache back-forward come visite a pagine separate nel loro set di dati.

Sebbene non siano ancora disponibili API di prestazioni web dedicate per misurare queste metriche dopo il ripristino di bfcache, i valori possono essere approssimati utilizzando le API web esistenti.

• Per la metrica Largest Contentful Paint (LCP), puoi utilizzare il delta tra il timestamp dell'evento pageshow e il timestamp del frame dipinto successivo (dal momento che tutti gli elementi nel frame verranno dipinti contemporaneamente). Tieni presente che, nel caso di un ripristino della cache back-forward, LCP e FCP resteranno invariati.
• Per First Input Delay (FID), puoi aggiungere di nuovo i listener di eventi (gli stessi utilizzati dal polyfill FID) nell'evento pageshow e segnalare FID come ritardo del primo input dopo il ripristino della cache back-forward.
• Per la metrica Cumulative Layout Shift (CLS), puoi continuare a utilizzare il Performance Observationr esistente; non devi fare altro che reimpostare l'attuale valore CLS su 0.

Per ulteriori dettagli su come la cache back-forward influisce su ogni metrica, consulta le singole pagine delle guide alle metriche relative a Core Web Vitals. Per un esempio specifico di come implementare le versioni bfcache di queste metriche nel codice, consulta la pagina PR aggiungendole alla libreria JS degli elementi web.

Altre risorse

• Memorizzazione nella cache di Firefox (bfcache in Firefox)
• Cache delle pagine (bfcache in Safari)
• Cache back-forward: comportamento dell'esposizione web (differenze della cache back-forward tra browser)
• tester bfcache (verifica in che modo API ed eventi diversi influiscono sulla cache bfcache nei browser)
• Performance Game Changer: Browser Back/Forward Cache (case study di Smashing Magazine che mostra incredibili miglioramenti di Core Web Vitals abilitando bfcache)