Cache back-forward

Philip Walton

Barry Pollard

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

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

Compatibilità del browser

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

A partire dalla versione 86, Chrome ha attivato bfcache per le navigazioni tra siti su Android per una percentuale ridotta di utenti. Nelle release successive è stato implementato gradualmente il supporto aggiuntivo. Dalla versione 96, bfcache è attivata per tutti gli utenti di Chrome su computer e dispositivi mobili.

Nozioni di base su bfcache

bfcache è una cache in memoria che archivia un'istantanea completa di una pagina (incluso l'heap JavaScript) quando l'utente esce dal sito. Poiché l'intera pagina è in memoria, il browser può ripristinarla rapidamente se l'utente decide di tornare indietro.

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

Guarda questo video di bfcache in azione per capire la velocità che può apportare alle navigazioni:

Nel video, l'esempio con bfcache è molto più veloce rispetto all'esempio che non la contiene.

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

I dati sull'utilizzo di Chrome mostrano che 1 navigazione su 10 su computer e 1 su 5 su dispositivi mobili vanno avanti o indietro. Con bfcache abilitata, i browser potevano eliminare il trasferimento di dati e il tempo impiegato per il caricamento di miliardi di pagine web ogni singolo giorno.

In che modo la cache funziona

La "cache" utilizzata da bfcache è diversa dalla cache HTTP, che svolge il proprio ruolo nell'accelerare le navigazioni ripetute. 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é è molto raro che tutte le richieste di caricamento di una pagina vengano soddisfatte dalla cache HTTP, le visite ripetute che utilizzano il ripristino bfcache sono sempre più veloci anche delle navigazioni non bfcache più ottimizzate.

La creazione di uno snapshot di una pagina in memoria, tuttavia, richiede una certa complessità in termini di come conservare al meglio il codice in corso. Ad esempio, come gestisci le chiamate setTimeout() in cui il timeout viene raggiunto mentre la pagina si trova nella cache bfcache?

La risposta è che i browser mettono in pausa eventuali timer in sospeso o promesse non risolte per le pagine in bfcache, incluse quasi tutte le attività in sospeso nelle code di attività JavaScript, e riprendono le attività di elaborazione se la pagina viene ripristinata dalla bfcache.

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

Per ulteriori dettagli su come vari utilizzi dell'API influiscono sull'idoneità a bfcache di una pagina, consulta Ottimizzare le pagine per bfcache.

bfcache e iframe

Se una pagina contiene iframe incorporati, gli iframe stessi non sono idonei per bfcache. Ad esempio, se passi a un'altra pagina all'interno di un iframe e poi torni indietro, il browser visualizzerà "indietro" nell'iframe anziché nel frame principale, ma la navigazione a ritroso all'interno dell'iframe non utilizza bfcache.

È possibile anche impedire al frame principale di utilizzare la cache bfcache se un iframe incorporato utilizza API che lo bloccano. Per evitare che ciò accada, è possibile usare i criteri relativi alle autorizzazioni impostati nel frame principale o l'utilizzo di attributi sandbox.

bfcache e le app a pagina singola (APS)

Dato che bfcache funziona con le navigazioni gestite dal browser, non funziona per le "navigamenti non obbligatori" all'interno di un'app a pagina singola (APS). Tuttavia, bfcache può comunque essere utile quando si torna a un'APS anziché eseguire una nuova inizializzazione completa dell'app dall'inizio.

API per osservare bfcache

Anche se bfcache è un'ottimizzazione eseguita automaticamente dai browser, è comunque importante che gli sviluppatori sappiano quando ciò avviene, in modo che possano ottimizzare le proprie pagine e regolare le metriche o la misurazione del rendimento di conseguenza.

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

Gli eventi Ciclo di vita della pagina più recenti (freeze e resume) vengono inviati anche quando le pagine entrano o escono da bfcache, nonché in alcune 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.

Osserva quando una pagina viene ripristinata da bfcache

L'evento pageshow viene attivato subito dopo l'evento load quando la pagina viene caricata inizialmente e ogni volta che la pagina viene ripristinata da bfcache. L'evento pageshow ha una proprietà persisted, ovvero true se la pagina è stata ripristinata da bfcache o da false in caso contrario. Puoi utilizzare la proprietà persisted per distinguere i caricamenti di pagina regolari dai ripristini bfcache. 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 da bfcache (immediatamente prima dell'evento pageshow) e quando un utente torna a una scheda bloccata in background. Se vuoi aggiornare lo stato di una pagina dopo che è stata bloccata (che include pagine nella cache bfcache), puoi utilizzare l'evento resume, ma se vuoi misurare la percentuale di successi di bfcache del tuo sito, dovrai utilizzare l'evento pageshow. In alcuni casi, potresti dover utilizzare entrambi.

Per maggiori dettagli sulle best practice per la misurazione bfcache, consulta l'articolo su come bfcache influisce sull'analisi e sulla misurazione delle prestazioni.

Osserva l'inserimento di bfcache in una pagina

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

L'evento pagehide ha anche una proprietà persisted. Se è false, puoi essere certo che una pagina non sta per inserire la cache bfcache. Tuttavia, il fatto che il valore di persisted sia true non garantisce che una pagina venga memorizzata nella cache. Significa che il browser intendisce memorizzare nella cache la pagina, ma potrebbero esserci altri fattori che ne impediscono 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 si attiva subito dopo l'evento pagehide se persisted è true, ma questo significa solo che il browser intende memorizzare la pagina nella cache. Potrebbe essere necessario eliminarlo per una serie di motivi spiegati in seguito.

Ottimizza le tue pagine per bfcache

Non tutte le pagine vengono memorizzate in bfcache e, anche quando una pagina viene memorizzata lì, non rimane per sempre. È fondamentale che gli sviluppatori comprendano cosa rende le pagine idonee (e non idonee) per bfcache al fine di massimizzare le percentuali di successo della cache.

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

Non usare mai l'evento unload

Il modo più importante per eseguire l'ottimizzazione per bfcache in tutti i browser è non utilizzare mai l'evento unload. Di sempre!

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

Pertanto, i browser si trovano di fronte a un dilemma: devono scegliere tra qualcosa in grado di migliorare l'esperienza utente e, allo stesso tempo, rischiare di danneggiare la pagina.

Su computer, Chrome e Firefox hanno scelto di rendere le pagine non idonee per la memorizzazione nella cache bfcache se aggiungono un listener unload, che è meno rischioso ma rende anche molte idonee. Safari tenterà di memorizzare nella cache alcune pagine con un listener di eventi unload, ma per ridurre i potenziali danni non eseguirà l'evento unload quando un utente sta uscendo, 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 come non idonee per la cache bfcache, ad eccezione di iOS, che richiede che tutti i browser utilizzino il motore di rendering WebKit; pertanto, si comporta come Safari.

Anziché utilizzare l'evento unload, usa 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 cache bfcache.

Infatti, Lighthouse dispone di un controllo no-unload-listeners, che avvisa gli sviluppatori se eventuali codice JavaScript sulle 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 ritirare l'evento unload.

Utilizza le norme relative alle autorizzazioni 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 usando un criterio di autorizzazione.

Permission-Policy: unload=()

In questo modo, inoltre, puoi impedire a terze parti o estensioni di rallentare il sito aggiungendo gestori dell'unload e rendendo il sito non idoneo per la cache bfcache.

Aggiungi solo ascoltatori beforeunload in modo condizionale

L'evento beforeunload non renderà le tue pagine non idonee per l'utilizzo di bfcache nei browser moderni bfcache, ma in precedenza lo era 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, quando vuoi avvisare l'utente che ha le modifiche non salvate andranno perse se escono dalla pagina. In questo caso ti è stato consigliato di aggiungere beforeunload listener solo quando un utente non ha salvato modifiche e poi rimuoverle subito dopo il salvataggio di quelle 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 server web di intestazione HTTP che può essere impostato sulle risposte che indica al browser di non archiviare la risposta in alcuna cache HTTP. Viene utilizzato per le risorse che contengono informazioni sensibili sugli utenti, ad esempio le pagine per le credenziali di accesso.

Sebbene bfcache non sia una cache HTTP, storicamente, quando Cache-Control: no-store è impostato sulla risorsa della pagina stessa (e non su qualsiasi risorsa secondaria), i browser hanno scelto di non archiviare la pagina in bfcache. Sono in corso lavori per modificare questo comportamento di Chrome in modo da garantire la tutela della privacy, ma al momento le pagine che utilizzano Cache-Control: no-store non saranno idonee per bfcache.

Poiché il criterio Cache-Control: no-store limita l'idoneità di una pagina all'utilizzo di bfcache, deve essere impostato solo su pagine che contengono informazioni sensibili, laddove la memorizzazione nella cache di qualsiasi tipo non è mai appropriata.

Utilizza Cache-Control: no-cache o Cache-Control: max-age=0 per le pagine che devono pubblicare sempre contenuti aggiornati e che non includono informazioni sensibili. Queste istruzioni indicano al browser di riconvalidare i contenuti prima di pubblicarli e non influiscono sull'idoneità a bfcache di una pagina.

Tieni presente che quando una pagina viene ripristinata da bfcache, 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 viene eseguita alcuna riconvalida prima che i contenuti vengano mostrati all'utente.

Tuttavia, probabilmente l'esperienza utente migliore è comunque, poiché i ripristini di bfcache sono istantanei e, poiché le pagine non rimangono nella cache per molto tempo, è 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.

Aggiornare i dati inattivi o sensibili dopo il ripristino di bfcache

Se il tuo sito mantiene lo stato dell'utente, in particolare informazioni sensibili dell'utente, i dati devono essere aggiornati o cancellati dopo il ripristino di una pagina da bfcache.

Ad esempio, se un utente apre una pagina di pagamento e poi aggiorna il carrello degli acquisti, una navigazione indietro potrebbe esporre informazioni non aggiornate se una pagina non aggiornata viene ripristinata da bfcache.

Un altro esempio più importante è il caso in cui un utente esce da un sito su un computer pubblico e l'utente successivo fa clic sul pulsante Indietro. Ciò potrebbe esporre dati privati che l'utente supponeva fossero stati cancellati al momento della disconnessione.

Per evitare situazioni come questa, è buona norma aggiornare la pagina dopo un evento pageshow se il valore event.persisted è true:

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

Anche se idealmente dovresti aggiornare i contenuti, 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 lo ricarica se 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 le navigazioni in avanti), ma in alcuni casi un reindirizzamento potrebbe essere più appropriato.

Ripristino di annunci e bfcache

Potresti avere la tentazione di evitare di utilizzare bfcache per pubblicare un nuovo insieme di annunci in ogni navigazione back-forward. Tuttavia, oltre ad avere un impatto sul rendimento, è dubbio se un simile comportamento porti a un migliore coinvolgimento degli annunci. Gli utenti potrebbero aver notato un annuncio che volevano tornare a fare clic, ma non è stato possibile ricaricarlo invece di ripristinarlo dalla cache. Verificare questo scenario, idealmente con un test A/B, è importante prima di formulare ipotesi.

Per i siti che vogliono aggiornare gli annunci al ripristino di bfcache, l'aggiornamento solo degli annunci sull'evento pageshow quando event.persisted è true consente di eseguire questa operazione senza influire sulle prestazioni della pagina. Rivolgiti al tuo fornitore di annunci, ma ecco un esempio su come farlo con il tag pubblicazione di Google.

Evita riferimenti a window.opener

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

Oltre a essere un rischio per la sicurezza, una pagina con un riferimento a window.opener non nullo non può essere inserita in modo sicuro nella cache bfcache, perché questo 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: ora è l'impostazione predefinita in tutti i browser moderni). Se il tuo sito richiede di aprire una finestra e controllarla tramite window.postMessage() o di fare riferimento direttamente all'oggetto finestra, né la finestra aperta né l'elemento di apertura saranno idonei per bfcache.

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

Come accennato in precedenza, quando una pagina viene inserita nella cache bfcache, tutte le attività JavaScript pianificate vengono sospese e riprendono quando la pagina viene eliminata dalla cache.

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

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

Di conseguenza, alcuni browser non tentano 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 vivamente di chiudere le connessioni e rimuovere o disconnettere gli osservatori durante l'evento pagehide o freeze. Ciò consente al browser di memorizzare nella cache la pagina in modo sicuro senza il rischio di danneggiare altre schede aperte.

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

Nell'esempio seguente viene illustrato come garantire che le pagine che utilizzano IndexedDB siano idonee per 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());

Verifica che le tue pagine siano memorizzabili nella cache

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

Per testare una pagina:

1. Vai alla pagina in Chrome.
2. In DevTools, vai ad Applicazione -> Cache back-forward.
3. Fai clic sul pulsante Esegui test. DevTools cerca poi di uscire e tornare indietro per determinare se la pagina può essere ripristinata da bfcache.

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

Se l'operazione non va a buon fine, il riquadro ne indica il motivo. Se il motivo è un problema che puoi affrontare in qualità di sviluppatore, il riquadro lo contrassegna come Azione.

In questo esempio, l'utilizzo di un listener di eventi unload rende la pagina non idonea per bfcache. 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 ulteriori informazioni, consulta la documentazione del controllo bfcache.

In che modo bfcache influisce sull'analisi e sulla misurazione delle prestazioni

Se utilizzi uno strumento di analisi per misurare le visite al tuo sito, potresti notare una diminuzione del numero totale di visualizzazioni di pagina registrate perché Chrome abilita bfcache per più utenti.

Infatti, è probabile che tu stia già registrando una sottostima delle visualizzazioni di pagina da altri browser che implementano bfcache, perché molte librerie di analisi molto utilizzate non misurano i ripristini di bfcache come nuove visualizzazioni di pagina.

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

L'esempio seguente 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');
  }
});

Misura la percentuale di hit di bfcache

Potresti anche valutare l'utilizzo di bfcache per identificare le pagine che non la utilizzano. Per farlo, devi 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';
    });
  }
});

Calcola la percentuale di hit di bfcache utilizzando i conteggi per le navigazioni back_forward e back_forward_cache.

È importante capire che esistono vari scenari, al di fuori del controllo dei proprietari del sito, in cui la navigazione Indietro/Avanti non utilizza bfcache, tra cui:

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

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

Anche senza queste esclusioni, bfcache verrà eliminata dopo un determinato periodo per risparmiare memoria.

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

Il team di Chrome ha aggiunto l'API NotRestoredReasons per illustrare i motivi per cui le pagine non usano bfcache, in modo che gli sviluppatori possano migliorare le percentuali di successo di 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

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é avviarne un nuovo caricamento, il numero totale di caricamenti pagina raccolti diminuisce quando bfcache viene attivato. L'aspetto fondamentale, però, è che i caricamenti pagina che vengono sostituiti dai ripristini bfcache probabilmente erano 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 pagina ripetuti sono generalmente più veloci dei caricamenti pagina dai visitatori alla prima visita (a causa della memorizzazione nella cache HTTP, come accennato in precedenza).

Il risultato è un numero inferiore di caricamenti pagina veloci nel set di dati, il che probabilmente disallinea la distribuzione più lentamente, nonostante il fatto che le prestazioni sperimentate dall'utente siano probabilmente migliorate.

Esistono diversi modi per risolvere questo problema. Il primo è annotare tutte le metriche di caricamento pagina con il rispettivo tipo di navigazione: navigate, reload, back_forward o prerender. In questo modo puoi continuare a monitorare il tuo rendimento all'interno di questi tipi di navigazione, anche se la distribuzione complessiva è negativa. Consigliamo questo approccio per le metriche di caricamento delle pagine non incentrate sugli utenti, ad esempio Time to First Byte (TTFB).

Per le metriche incentrate sugli utenti come Core Web Vitals, un'opzione migliore è quella di segnalare un valore che rappresenti in modo più accurato l'esperienza utente.

Impatto sui Core Web Vitals

I Segnali web essenziali misurano l'esperienza dell'utente su una pagina web in relazione a diverse dimensioni (velocità di caricamento, interattività, stabilità visiva) e, poiché gli utenti sperimentano i ripristini bfcache come navigazione più veloce rispetto al caricamento dell'intera pagina, è importante che le metriche di Segnali web essenziali riflettano questo aspetto. Dopotutto, a un utente non importa se bfcache sia stato abilitato o meno, gli interessa solo che la navigazione sia stata veloce.

Gli strumenti che raccolgono e generano report sulle metriche Core Web Vitals, come il Chrome User Experience Report, considerano i ripristini di bfcache come visite di pagine separate nel loro set di dati. Anche se non esistono API per le prestazioni web dedicate per misurare queste metriche dopo il ripristino di bfcache, puoi approssimarne i valori utilizzando le API web esistenti:

• Per l'opzione Largest Contentful Paint (LCP), utilizza il delta tra il timestamp dell'evento pageshow e il timestamp del frame dipinto successivo, perché tutti gli elementi nel frame verranno dipinti contemporaneamente. Nel caso di un ripristino bfcache, LCP e FCP sono gli stessi.
• Per Interaction to Next Paint (INP), continua a utilizzare il Performance Observer esistente, ma reimposta il valore INP attuale su 0.
• Per Cumulative Layout Shift (CLS), continua a utilizzare Performance Observer, ma ripristina il valore CLS attuale su 0.

Per ulteriori dettagli sull'impatto di bfcache su ogni metrica, consulta le singole pagine delle guide per le metriche Core Web Vitals. Per un esempio specifico su come implementare le versioni bfcache di queste metriche, consulta il documento PR sull'aggiunta alla libreria JS web-vitals.

La libreria JavaScript web-vitals supporta i ripristini bfcache nelle metriche registrate.

Risorse aggiuntive

• Memorizzazione nella cache di Firefox (bfcache in Firefox)
• Cache pagine (bfcache in Safari)
• Cache back/forward: comportamento esposto al web (differenze bfcache tra i browser)
• tester bfcache (testa in che modo API ed eventi diversi influiscono su bfcache nei browser)
• Performance Game Changer: cache back-forward del browser (un case study di Smashing Magazine che mostra importanti miglioramenti delle metriche Core Web Vitals abilitando bfcache)