Cache back-forward

Philip Walton

Barry Pollard

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

In qualità di sviluppatori web, è fondamentale capire come ottimizzare le pagine per la bfcache, in modo che gli utenti possano trarne vantaggio.

Compatibilità del browser

Tutti i principali browser includono una bfcache, tra cui Chrome dalla versione 96, Firefox e Safari.

Nozioni di base su bfcache

Con la cache back-forward (bfcache), anziché eliminare una pagina quando l'utente esce, posticipiamo l'eliminazione e mettiamo in pausa l'esecuzione di JavaScript. Se l'utente torna indietro poco dopo, rendiamo nuovamente visibile la pagina e riprendiamo l'esecuzione di JavaScript. In questo modo, l'utente può navigare tra le pagine quasi istantaneamente.

Quante volte hai visitato un sito web e hai fatto clic su un link per andare a un'altra pagina, solo per renderti conto che non era quello che volevi e fare clic sul pulsante Indietro? In quel momento, la bfcache può fare una grande differenza nella velocità di caricamento della pagina precedente:

Guarda questo video della cache back-forward in azione per capire la velocità che può apportare alle navigazioni:

Nel video, l'esempio con bfcache è molto più veloce di quello senza.

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

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

Come funziona la "cache"

La "cache" utilizzata da bfcache è diversa dalla cache HTTP, che svolge un ruolo proprio nell'accelerare le navigazioni ripetute. bfcache è uno snapshot dell'intera pagina in memoria, incluso l'heap JavaScript, mentre la cache HTTP contiene solo le risposte alle richieste effettuate in precedenza. Poiché è molto raro che tutte le richieste necessarie per caricare una pagina vengano soddisfatte dalla cache HTTP, le visite ripetute che utilizzano i ripristini bfcache sono sempre più veloci anche delle navigazioni non bfcache più ottimizzate.

Il blocco di una pagina per riattivarla in un secondo momento comporta una certa complessità in termini di modalità di conservazione ottimale del codice in corso. Ad esempio, come gestisci le chiamate setTimeout() in cui viene raggiunto il timeout mentre la pagina si trova nella bfcache?

La risposta è che i browser mettono in pausa tutti i timer in attesa o le promesse irrisolte per le pagine nella bfcache, incluse quasi tutte le attività in attesa nelle code di attività JavaScript, e riprendono l'elaborazione delle attività se la pagina viene ripristinata dalla bfcache.

In alcuni casi, ad esempio per timeout e promesse, il rischio è piuttosto basso, ma in altri casi può portare a comportamenti confusi o imprevisti. Ad esempio, se il browser mette in pausa un'attività richiesta nell'ambito di una transazione IndexedDB, può influire su altre schede aperte nella stessa origine, perché più schede possono accedere contemporaneamente agli stessi database IndexedDB. Di conseguenza, in genere i browser non tentano di memorizzare nella cache le pagine nel bel mezzo di una transazione IndexedDB o durante l'utilizzo di API che potrebbero influire su altre pagine.

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

La bfcache e gli iframe

Se una pagina contiene iframe incorporati, gli iframe stessi non sono idonei separatamente per la cache back-forward. Ad esempio, se vai a un altro URL all'interno di un iframe, i contenuti precedenti non vengono inseriti nella bfcache e, se torni indietro, il browser torna "indietro" all'interno dell'iframe anziché nel frame principale, ma la navigazione indietro all'interno dell'iframe non utilizza la bfcache.

Tuttavia, quando il frame principale viene ripristinato dalla bfcache, gli iframe incorporati vengono ripristinati così com'erano quando la pagina è entrata nella bfcache.

Anche il frame principale può essere bloccato dall'utilizzo della cache back-forward se un iframe incorporato utilizza API che lo bloccano. Per evitare questo problema, puoi utilizzare i criteri per le autorizzazioni impostati sul frame principale o gli attributi sandbox.

La bfcache e le app a pagina singola (SPA)

Poiché la bfcache funziona con le navigazioni gestite dal browser, non funziona per le "navigazioni soft" all'interno di un'app a pagina singola (SPA). Tuttavia, la bfcache può comunque essere utile quando si torna a una SPA anziché eseguire nuovamente l'inizializzazione completa dell'app dall'inizio.

API per osservare bfcache

Anche se la bfcache è un'ottimizzazione eseguita automaticamente dai browser, è comunque importante che gli sviluppatori sappiano quando viene eseguita in modo da poter ottimizzare le pagine per questa cache e modificare di conseguenza eventuali metriche o misurazioni del rendimento.

Gli eventi principali utilizzati per osservare la bfcache sono gli eventi di transizione di pagina pageshow e pagehide, supportati dalla maggior parte dei browser.

Anche gli eventi Page Lifecycle più recenti, freeze e resume, vengono inviati quando le pagine entrano o escono dalla bfcache, nonché in altre situazioni, ad esempio quando una scheda in background viene bloccata per ridurre al minimo l'utilizzo della CPU. Questi eventi sono supportati solo nei browser basati su Chromium.

Osservare quando una pagina viene ripristinata dalla bfcache

L'evento pageshow viene attivato subito dopo l'evento load durante il caricamento iniziale della pagina e ogni volta che la pagina viene ripristinata dalla cache back-forward. L'evento pageshow ha una proprietà persisted, che è true se la pagina è stata ripristinata da bfcache e false in caso contrario. Puoi utilizzare la proprietà persisted per distinguere i caricamenti di pagine regolari 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 quando le pagine vengono ripristinate dalla bfcache (immediatamente prima dell'evento pageshow) e quando un utente rivisita una scheda in background bloccata. Se vuoi aggiornare lo stato di una pagina dopo che è stata bloccata (incluse le pagine nella bfcache), puoi utilizzare l'evento resume, ma se vuoi misurare il tasso di hit della bfcache del tuo sito, devi utilizzare l'evento pageshow. In alcuni casi, potresti doverli utilizzare entrambi.

Per informazioni dettagliate sulle best practice per la misurazione della bfcache, consulta In che modo la bfcache influisce sulla misurazione delle prestazioni e di Analytics.

Osservare quando una pagina entra nella bfcache

L'evento pagehide viene attivato quando una pagina viene scaricata o quando il browser tenta di inserirla nella bfcache.

L'evento pagehide ha anche una proprietà persisted. Se è false, puoi essere certo che la pagina non sta per entrare nella cache back-forward. Tuttavia, persisted essere true non garantisce che una pagina venga memorizzata nella cache. Significa che il browser intende memorizzare nella cache la pagina, ma potrebbero esserci altri fattori che rendono impossibile la memorizzazione nella cache.

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

Allo stesso modo, l'evento freeze viene attivato immediatamente dopo l'evento pagehide se persisted è true, ma ciò significa solo che il browser intende memorizzare nella cache la pagina. Potrebbe comunque doverlo scartare per una serie di motivi spiegati in seguito.

Ottimizzare le pagine per bfcache

Non tutte le pagine vengono memorizzate nella cache back-forward e, anche quando una pagina viene memorizzata, non rimane lì per sempre. È fondamentale che gli sviluppatori comprendano cosa rende le pagine idonee (e non idonee) alla bfcache per massimizzare i tassi di hit della cache.

Le sezioni seguenti descrivono le best practice per aumentare al massimo la probabilità che il browser possa memorizzare nella cache le tue pagine.

Non utilizzare mai l'evento unload

Il modo più importante per ottimizzare la bfcache 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 con l'ipotesi (ragionevole) che una pagina non esisterà più dopo l'attivazione dell'evento unload. Ciò rappresenta una sfida perché molte di queste pagine sono state anche create presupponendo che l'evento unload venga attivato ogni volta che un utente esce dalla pagina, il che non è più vero (e non è vero da molto tempo).

I browser si trovano quindi di fronte a un dilemma: devono scegliere tra qualcosa che può migliorare l'esperienza utente, ma che potrebbe anche rischiare di interrompere la pagina.

Su computer, Chrome e Firefox hanno scelto di rendere le pagine non idonee alla bfcache se aggiungono un listener unload, il che è meno rischioso, ma squalifica anche molte pagine. Safari tenterà di memorizzare nella cache alcune pagine con un listener di eventi unload, ma per ridurre potenziali interruzioni non eseguirà l'evento unload quando un utente esce dalla pagina, il che rende l'evento molto inaffidabile.

Su dispositivo mobile, Chrome e Safari tenteranno di memorizzare nella cache le pagine con un listener di eventi unload, poiché il rischio di interruzione è inferiore a causa del fatto che 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, pertanto si comporta come Safari.

Anziché utilizzare l'evento unload, utilizza l'evento pagehide. L'evento pagehide viene attivato in tutti i casi in cui viene attivato l'evento unload e anche quando una pagina viene inserita nella bfcache.

Infatti, Lighthouse ha un controllo no-unload-listeners, che avvisa gli sviluppatori se qualsiasi 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 per la bfcache, Chrome sta valutando di ritirare l'evento unload.

Utilizzare Permission Policy per impedire l'utilizzo dei gestori di unload in una pagina

I siti che non utilizzano i gestori di eventi unload possono assicurarsi che non vengano aggiunti utilizzando un criterio di autorizzazione.

Permissions-Policy: unload=()

In questo modo si impedisce anche a terze parti o estensioni di rallentare il sito aggiungendo gestori di scaricamento e rendendo il sito non idoneo alla bfcache.

Aggiungi solo beforeunload ascoltatori in modo condizionale

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

A differenza dell'evento unload, tuttavia, esistono utilizzi legittimi di beforeunload. Ad esempio, quando vuoi avvisare l'utente che ha modifiche non salvate che perderà se esce dalla pagina. In questo caso, è consigliabile aggiungere solo listener beforeunload quando un utente ha modifiche non salvate e 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 nelle risposte per indicare al browser di non memorizzare la risposta in alcuna cache HTTP. Viene utilizzato per le risorse contenenti informazioni sensibili dell'utente, ad esempio le pagine protette da accesso.

Sebbene la cache back-forward non sia una cache HTTP, storicamente, quando Cache-Control: no-store è impostato sulla risorsa della pagina stessa (anziché su qualsiasi risorsa secondaria), i browser hanno scelto di non memorizzare la pagina nella cache back-forward, quindi le pagine che utilizzano Cache-Control: no-store potrebbero non essere idonee per la cache back-forward. Sono in corso lavori per modificare questo comportamento per Chrome in modo da tutelare la privacy.

Poiché Cache-Control: no-store limita l'idoneità di una pagina alla cache back-forward, deve essere impostato solo sulle pagine che contengono informazioni sensibili in cui la memorizzazione nella cache di qualsiasi tipo non è mai appropriata.

Per le pagine che devono sempre mostrare contenuti aggiornati e che non contengono informazioni sensibili, utilizza Cache-Control: no-cache o Cache-Control: max-age=0. Queste direttive indicano al browser di convalidare nuovamente i contenuti prima di pubblicarli e non influiscono sull'idoneità di una pagina alla bfcache.

Tieni presente che quando una pagina viene ripristinata da bfcache, viene ripristinata dalla memoria, non dalla cache HTTP. Di conseguenza, direttive come Cache-Control: no-cache o Cache-Control: max-age=0 non vengono prese in considerazione e non viene eseguita alcuna nuova convalida prima che i contenuti vengano visualizzati dall'utente.

Tuttavia, è probabile che si tratti di un'esperienza utente migliore, in quanto i ripristini della bfcache sono istantanei e, poiché le pagine non rimangono nella bfcache per molto tempo, è improbabile che i contenuti siano obsoleti. Tuttavia, se i tuoi contenuti cambiano di minuto in minuto, puoi recuperare gli aggiornamenti utilizzando l'evento pageshow, come descritto nella sezione successiva.

Aggiornare i dati obsoleti o sensibili dopo il ripristino della bfcache

Se il tuo sito mantiene lo stato dell'utente, in particolare qualsiasi informazione utente sensibile, questi dati devono essere aggiornati o cancellati dopo il ripristino di una pagina dalla bfcache.

Ad esempio, se un utente passa a una pagina di pagamento e poi aggiorna il carrello, una navigazione indietro potrebbe potenzialmente esporre informazioni non aggiornate se una pagina obsoleta viene ripristinata dalla bfcache.

Un altro esempio più critico è se un utente esce da un sito su un computer pubblico e l'utente successivo fa clic sul pulsante Indietro. Ciò potrebbe potenzialmente esporre dati privati che l'utente riteneva fossero stati cancellati al momento della disconnessione.

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 l'ideale sarebbe aggiornare i contenuti sul posto, 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 ricarica la pagina 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 ha il vantaggio di conservare la cronologia (per consentire la navigazione in avanti), ma un reindirizzamento potrebbe essere più appropriato in alcuni casi.

Annunci e ripristino della bfcache

Potrebbe essere allettante cercare di evitare l'utilizzo della bfcache per pubblicare un nuovo insieme di annunci a ogni navigazione indietro/avanti. Tuttavia, oltre ad avere un impatto sul rendimento, è discutibile se questo comportamento porti a un maggiore coinvolgimento con gli annunci. Gli utenti potrebbero aver notato un annuncio su cui intendevano fare clic per tornare, ma ricaricando la pagina anziché ripristinandola dalla bfcache, non potranno farlo. Testare questo scenario, idealmente con un test A/B, è importante prima di fare ipotesi.

Per i siti che vogliono aggiornare gli annunci al ripristino della bfcache, l'aggiornamento solo degli annunci nell'evento pageshow quando event.persisted è true consente di farlo senza influire sul rendimento della pagina. Rivolgiti al tuo fornitore di annunci, ma ecco un esempio di come farlo con il Tag publisher di Google.

Evitare i riferimenti a window.opener

Nei browser meno recenti, se una pagina veniva aperta utilizzando window.open() da un link con target=_blank, senza specificare rel="noopener", la pagina di apertura aveva 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 modo sicuro nella bfcache, perché ciò potrebbe danneggiare le pagine che tentano di accedervi.

Di conseguenza, è meglio evitare di creare riferimenti window.opener. Puoi farlo utilizzando rel="noopener" quando possibile (tieni presente che ora è l'impostazione predefinita in tutti i browser moderni). Se il tuo sito richiede l'apertura di una finestra e il suo controllo tramite window.postMessage() o il riferimento diretto all'oggetto finestra, né la finestra aperta né l'apertura saranno idonee alla bfcache.

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

Come accennato in precedenza, quando una pagina viene memorizzata nella cache back-forward, tutte le attività JavaScript pianificate vengono sospese e riprese quando la pagina viene rimossa dalla cache.

Se queste attività JavaScript pianificate accedono solo alle API DOM o ad altre API isolate solo nella pagina corrente, la sospensione di queste attività mentre la pagina non è visibile all'utente non causerà problemi.

Tuttavia, se queste attività sono connesse ad API accessibili anche da altre pagine della stessa origine (ad esempio IndexedDB, Web Locks, WebSockets), ciò può essere problematico perché la sospensione di queste attività potrebbe impedire l'esecuzione del codice in altre schede.

Di conseguenza, alcuni browser non tentano di inserire una pagina nella 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 vivamente di chiudere le connessioni e rimuovere o disconnettere gli osservatori durante l'evento pagehide o freeze. In questo modo, il browser può memorizzare nella cache la pagina in modo sicuro senza rischiare di influire su altre schede aperte.

Se la pagina viene ripristinata dalla bfcache, puoi riaprire o riconnetterti a queste API durante l'evento pageshow o resume.

Il seguente esempio mostra come assicurarsi che le pagine che utilizzano IndexedDB siano idonee alla bfcache chiudendo una connessione aperta nel listener di 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 leaves.
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());

Esegui un test per assicurarti che le pagine siano memorizzabili nella cache

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

Per testare una pagina:

1. Vai alla pagina in Chrome.
2. In DevTools, vai ad Applicazione -> Cache indietro/avanti.
3. Fai clic sul pulsante Esegui test. DevTools tenta quindi di uscire e tornare indietro per determinare se la pagina può essere ripristinata dalla bfcache.

Se il test ha esito positivo, nel riquadro viene visualizzato il messaggio "Ripristinato dalla cache back-forward".

In caso di esito negativo, il riquadro indica il motivo. Se il motivo è qualcosa che puoi risolvere in qualità di sviluppatore, il pannello lo contrassegna come Azione da intraprendere.

In questo esempio, l'utilizzo di un listener di eventi unload rende la pagina non idonea per la cache back-forward. Puoi risolvere il problema passando da unload all'utilizzo di pagehide:

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

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

Lighthouse 10.0 ha anche aggiunto un controllo bfcache, che esegue un test simile. Per saperne di più, consulta la documentazione dell'audit bfcache.

In che modo la bfcache influisce sull'analisi e sulla misurazione del rendimento

Se utilizzi uno strumento di analisi per misurare le visite al tuo sito, potresti notare una diminuzione del numero totale di visualizzazioni di pagina segnalate man mano che Chrome attiva la bfcache per un maggior numero di utenti.

Infatti, è probabile che tu stia già sottostimando le visualizzazioni di pagina provenienti da altri browser che implementano la bfcache, perché molte librerie di analisi popolari non misurano i ripristini della bfcache come nuove visualizzazioni di pagina.

Per includere i ripristini della bfcache nel conteggio delle visualizzazioni di pagina, imposta i listener per l'evento pageshow e controlla la proprietà persisted.

Il seguente esempio mostra come eseguire questa operazione con Google Analytics. Altri strumenti di analisi probabilmente utilizzano una logica simile:

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

Misurare la percentuale di successi della bfcache

Potresti anche voler misurare se è stata utilizzata la cache back-forward, per identificare le pagine che non la utilizzano. Per farlo, misura il tipo di navigazione per i caricamenti di 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';
    });
  }
});

Calcola il tasso di hit della bfcache utilizzando i conteggi per le navigazioni back_forward e back_forward_cache.

È importante rendersi conto che esistono diversi scenari, al di fuori del controllo dei proprietari del sito, in cui la navigazione Avanti/Indietro non utilizza la bfcache, 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 riapre.

In alcuni di questi casi, il tipo di navigazione originale potrebbe essere conservato 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 bfcache verrà eliminata dopo un periodo di tempo per risparmiare memoria.

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

Il team di Chrome ha aggiunto l'API NotRestoredReasons per contribuire a rivelare i motivi per cui le pagine non utilizzano la bfcache, in modo che gli sviluppatori possano migliorare le percentuali di hit della bfcache. Il team di Chrome ha anche aggiunto tipi di navigazione a CrUX, consentendo di visualizzare il numero di navigazioni bfcache anche senza misurarlo personalmente.

Misurazione del rendimento

La bfcache può anche influire negativamente sulle metriche sul rendimento raccolte sul campo, in particolare sulle metriche che misurano i tempi di caricamento delle pagine.

Poiché le navigazioni bfcache ripristinano una pagina esistente anziché avviare un nuovo caricamento della pagina, il numero totale di caricamenti di pagina raccolti diminuirà quando bfcache è abilitata. Tuttavia, è fondamentale che i caricamenti di pagina sostituiti dai ripristini della bfcache sarebbero stati probabilmente tra i più veloci del tuo set di dati. Questo perché le navigazioni indietro e avanti, per definizione, sono visite ripetute e i caricamenti ripetuti delle pagine sono generalmente più veloci rispetto ai caricamenti delle pagine dei visitatori che visitano il sito per la prima volta (a causa della memorizzazione nella cache HTTP, come accennato in precedenza).

Il risultato è un minor numero di caricamenti rapidi delle pagine nel tuo set di dati, il che probabilmente distorcerà la distribuzione più lentamente, nonostante il fatto che le prestazioni sperimentate dall'utente siano probabilmente migliorate.

Esistono alcuni modi per risolvere il problema. Un modo è annotare tutte le metriche di caricamento della pagina con il rispettivo tipo di navigazione: navigate, reload, back_forward o prerender. In questo modo, puoi continuare a monitorare il rendimento all'interno di questi tipi di navigazione, anche se la distribuzione complessiva è negativa. Consigliamo questo approccio per le metriche di caricamento della pagina non incentrate sull'utente, come Time to First Byte (TTFB).

Per le metriche incentrate sull'utente, come i Core Web Vitals, un'opzione migliore è segnalare un valore che rappresenti in modo più accurato l'esperienza dell'utente.

Impatto sui Core Web Vitals

Segnali web essenziali misurano l'esperienza dell'utente su una pagina web in base a una serie di dimensioni (velocità di caricamento, interattività, stabilità visiva) e, poiché gli utenti percepiscono i ripristini della bfcache come navigazioni più veloci rispetto ai caricamenti di pagine complete, è importante che le metriche di Segnali web essenziali riflettano questo aspetto. Dopo tutto, a un utente non interessa se la bfcache è stata attivata o meno, ma solo che la navigazione sia veloce.

Gli strumenti che raccolgono e generano report sulle metriche Core Web Vitals, come il Report sull'esperienza utente di Chrome, considerano i ripristini della bfcache come visite di pagine separate nel set di dati. Sebbene non esistano API per le prestazioni web dedicate per misurare queste metriche dopo i ripristini della bfcache, puoi approssimarne i valori utilizzando le API web esistenti:

• Per Largest Contentful Paint (LCP), utilizza la differenza tra il timestamp dell'evento pageshow e il timestamp del frame successivo, perché tutti gli elementi del frame verranno visualizzati contemporaneamente. Nel caso di un ripristino della bfcache, LCP e FCP sono uguali.
• Per Interaction to Next Paint (INP), continua a utilizzare l'osservatore delle prestazioni esistente, ma reimposta il valore INP corrente su 0.
• Per Cumulative Layout Shift (CLS), continua a utilizzare l'osservatore del rendimento esistente, ma reimposta il valore CLS corrente su 0.

Per ulteriori dettagli su come la bfcache influisce su ogni metrica, consulta le singole pagine delle guide alle metriche di Core Web Vitals. Per un esempio specifico di come implementare le versioni bfcache di queste metriche, consulta la PR che le aggiunge alla libreria JS web-vitals.

La libreria JavaScript web-vitals supporta i ripristini della cache bf nelle metriche che riporta.

Risorse aggiuntive

• Memorizzazione nella cache di Firefox (bfcache in Firefox)
• Cache pagina (bfcache in Safari)
• Cache back-forward: comportamento esposto sul web (differenze della cache back-forward tra i browser)
• bfcache tester (testa in che modo diverse API ed eventi influiscono su bfcache nei browser)
• Un punto di svolta per il rendimento: la cache back-forward del browser (un case study di Smashing Magazine che mostra miglioramenti drastici dei Core Web Vitals grazie all'attivazione della cache back-forward)