Cache back-forward

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, soprattutto per gli utenti con reti o dispositivi più lenti.

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

Compatibilità del browser

bfcache è supportata sia in Firefox che in 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 il supporto aggiuntivo. Dalla versione 96, 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 un'istantanea completa di una pagina (incluso l'heap JavaScript) mentre l'utente abbandona la pagina. Con l'intera pagina in memoria, il browser può ripristinarla rapidamente 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 di bfcache in azione per comprendere la velocità che può apportare alle navigazioni:

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

bfcache non solo velocizza la navigazione, ma riduce anche l'utilizzo dei dati, in quanto non è necessario scaricare di nuovo le risorse.

I dati sull'utilizzo di Chrome indicano che 1 navigazione su 10 su computer e 1 su 5 sui dispositivi mobili sono indietro o in avanti. Con la cache bfcache attivata, i browser potrebbero eliminare il trasferimento di dati e il tempo speso per il caricamento di miliardi di pagine web ogni giorno!

Come funziona la "cache"

La "cache" utilizzata da bfcache è diversa dalla cache HTTP, che svolge il proprio ruolo per velocizzare 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 necessarie per caricare una pagina vengano 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, richiede una certa complessità in termini di conservazione del codice in corso. Ad esempio, come si gestiscono le chiamate a setTimeout() in cui viene raggiunto il timeout mentre la pagina si trova nella cache back-forward?

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

In alcuni casi, ad esempio per timeout e promesse, questo 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, questo potrebbe influire su altre schede aperte nella stessa origine, perché più schede possono accedere contemporaneamente allo stesso database IndexedDB. Di conseguenza, i browser generalmente non tenteranno di memorizzare nella cache le pagine nel mezzo di una transazione IndexedDB o durante l'utilizzo di 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, vedi Ottimizzare le pagine per la cache back-forward.

bfcache e iframe

Se una pagina contiene iframe incorporati, gli iframe stessi non sono idonei per la cache back-forward. Ad esempio, se passi a un'altra pagina all'interno di un iframe, ma poi torni indietro, il browser andrà "indietro" all'interno dell'iframe anziché nel frame principale, ma la navigazione indietro all'interno dell'iframe non utilizzerà la bfcache.

È possibile anche impedire al frame principale di utilizzare la bfcache se un iframe incorporato utilizza API che bloccano questa operazione. Per evitare che ciò accada, puoi usare i criteri di autorizzazione impostati sul frame principale o l'uso degli attributi sandbox.

bfcache e app a pagina singola (SPA)

Poiché bfcache funziona con le navigazioni gestite dal browser, non funziona per le "navigazioni soft" all'interno di un'app a pagina singola (SPA). Tuttavia, bfcache può comunque essere d'aiuto quando si torna a un'SPA invece di dover eseguire di nuovo una reinizializzazione completa dell'app dall'inizio.

API per osservare la cache back-forward

Sebbene bfcache sia un'ottimizzazione che i browser eseguono automaticamente, è 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 back-forward sono gli eventi di transizione delle pagine pageshow e pagehide, supportati dalla maggior parte dei browser.

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. Questi eventi 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 quando la pagina viene caricata inizialmente e ogni volta che viene ripristinata dalla cache back-forward. L'evento pageshow ha una proprietà persisted, che corrisponde a true se la pagina è stata ripristinata dalla cache back-forward e in altri casi false. 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 si attiva quando le pagine vengono ripristinate dalla cache back-forward (immediatamente prima dell'evento pageshow) e 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 bfcache del tuo sito devi utilizzare l'evento pageshow. In alcuni casi, potresti dover utilizzare entrambi.

Per maggiori dettagli sulle best practice per la misurazione della cache back-forward, consulta In che modo la cache back-forward influisce sull'analisi e sulla misurazione delle prestazioni.

Osserva quando una pagina inserisce bfcache

L'evento pagehide viene attivato durante l'unload di una pagina o quando il browser tenta di inserirlo nella cache back-forward.

L'evento pagehide ha anche una proprietà persisted. Se è false, puoi avere la certezza che quella pagina non verrà inserita nella cache back-forward. Tuttavia, il fatto che persisted sia true non garantisce che una pagina venga memorizzata nella cache. Significa che il browser intends di memorizzare la pagina nella cache, ma potrebbero esserci altri 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.');
  }
});

In modo analogo, l'evento freeze viene attivato immediatamente dopo l'evento pagehide se persisted è true, ma questo significa solo che il browser intends di memorizzare la pagina nella cache. Potrebbe essere 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 quando una pagina viene memorizzata, non vi rimangono per sempre. È fondamentale che gli sviluppatori comprendano ciò che rende le pagine idonee (e non idonee) per la cache back-forward al fine di massimizzare la percentuale di hit 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 operano in base al presupposto (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 attiva ogni volta che un utente esce dalla pagina, il che non è più vero (e non è più vero da molto tempo).

Per questo i browser devono affrontare un dilemma: devono scegliere tra qualcosa che possa migliorare l'esperienza utente, ma che potrebbero anche rischiare di danneggiare la pagina.

Sui computer, Chrome e Firefox hanno scelto di rendere le pagine non idonee per la cache back-forward se aggiungono un listener 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 potenziali interruzioni non eseguirà l'evento unload durante l'uscita dell'utente, 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 viene attivato in tutti i casi in cui viene attivato l'evento unload 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()

Ciò inoltre impedisce a terze parti o estensioni di rallentare 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. Viene 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 memorizzare la pagina nella cache back-forward. È in corso il lavoro per modificare 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 che devono 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.

Tuttavia, si tratta comunque 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 è il caso in cui un utente si disconnetta da un sito su un computer pubblico e l'utente successivo faccia clic sul pulsante Indietro. Questo potrebbe comportare l'esposizione di 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 a 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 che intendevano tornare a fare clic, ma non sono riusciti a ricaricarlo anziché ripristinare la 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 precedenti, 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 diverso da null può essere inserita in sicurezza nella cache back-forward perché ciò potrebbe interrompere le pagine che tentano di accedere alla pagina.

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 suo 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 le connessioni aperte prima che l'utente esca dalla pagina

Come accennato in precedenza, quando una pagina viene inserita nella cache back-forward mette in pausa tutte le attività JavaScript pianificate e le riprende 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 Locks, WebSocket) 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 vivamente di chiudere le connessioni e di rimuovere o scollegare gli osservatori durante l'evento pagehide o freeze. Ciò consente al browser di memorizzare nella cache in modo sicuro la pagina senza il rischio di influire sulle altre schede aperte.

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

L'esempio seguente mostra come assicurare che le pagine che utilizzano IndexedDB siano idonee per la cache 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. => req.result.createObjectStore('keyval');
      req. => reject(req.error);
      req. => 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 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 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 back-forward.
3. Fai clic sul pulsante Esegui test. DevTools prova a uscire e a tornare indietro per determinare se la pagina può essere ripristinata dalla cache back-forward.

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

In caso contrario, il riquadro ne indica il motivo. Se il motivo è qualcosa che puoi segnalare in qualità di sviluppatore, il riquadro lo contrassegna come agibile.

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 della cache back-forward, che esegue un test simile. Per ulteriori informazioni, consulta la documentazione relativa al controllo della cache back-forward.

In che modo la cache back-forward 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 poiché Chrome attiva la cache back-forward per più utenti.

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

Per includere i ripristini di bfcache nel conteggio delle 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 il rapporto di successi della cache back-forward

Potresti anche voler misurare 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';
    });
  }
});

Calcola il rapporto di hit della cache back-forward utilizzando i conteggi per back_forward navigazioni e back_forward_cache navigazioni.

È importante capire che esistono diversi scenari, al di fuori del controllo del proprietario 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 e riapre una scheda.

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 back-forward per un'elevata percentuale di navigazioni avanti e indietro.

Il team di Chrome ha aggiunto l'API NotRestoredReasons per contribuire a esporre i motivi per cui le pagine non utilizzano la cache back-forward, in modo che gli sviluppatori possano migliorare le percentuali di successo della cache back-forward. Il team di Chrome ha anche aggiunto tipi di navigazione a CrUX, in modo da poter vedere il numero di navigazioni nella cache anche senza effettuare misurazioni manualmente.

Misurazione del rendimento

Inoltre, la cache back-forward 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é avviarne un nuovo caricamento, il numero totale di caricamenti pagina raccolti diminuirà quando questa funzionalità è attivata. L'aspetto fondamentale, tuttavia, è che i caricamenti pagina, che dovevano essere sostituiti dai ripristini della cache back-forward, probabilmente sarebbero 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 è l'annotazione di 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 le prestazioni all'interno di questi tipi di navigazione, anche se la distribuzione complessiva è negativa. Consigliamo questo approccio per le metriche relative al caricamento pagina non incentrate sull'utente, come Time to First Byte (TTFB).

Per le metriche incentrate sugli utenti come i Segnali web essenziali, un'opzione migliore è quella di 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 base a una serie di dimensioni (velocità di caricamento, interattività, stabilità visiva) e, poiché gli utenti riscontrano il ripristino della cache back-forward come navigazioni più veloci rispetto al caricamento di una pagina intera, è importante che le metriche di Segnali web essenziali riflettano questa situazione. Dopotutto, a un utente non importa se la cache back-forward è stata attivata o meno, ma solo che la navigazione è stata veloce.

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

• Per la metrica 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. In caso di ripristino di una cache back-forward, LCP e FCP corrispondono.
• In Interaction to Next Paint (INP), continua a usare Performance Observationr esistente, ma reimposta l'attuale valore INP su 0.
• Per la metrica Cumulative Layout Shift (CLS), continua a utilizzare Performance Observationr esistente, ma reimposta 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, consulta la pagina relativa all'aggiunta di PR alla libreria JS web-vitals.

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

Altre risorse

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