Cache back/forward (bfcache)

TL;DR — La back/forward cache (bfcache) è una funzione del browser che congela un’intera pagina in memoria quando la lasci, così premere Indietro o Avanti può riportarla istantaneamente — senza ricaricarla — finché il browser non ha prima espulso quella pagina congelata. È una funzione del browser, non un fattore di ranking Google. Ma poiché una pagina ripristinata si carica quasi istantaneamente, migliora silenziosamente i numeri dei Core Web Vitals nelle navigazioni Indietro/Avanti che vengono davvero ripristinate: per questo un audit delle prestazioni può invitarti a «correggere l’idoneità al bfcache».

Che cos’è il bfcache

Quando fai clic sul pulsante Indietro del browser, accade una di due cose. Il browser ricostruisce la pagina precedente da zero — riscarica i file, riesegue JavaScript e ricalcola il layout — oppure ripristina la pagina istantaneamente, esattamente come l’avevi lasciata. Questa versione istantanea è la back/forward cache, o bfcache.

Ecco il trucco: invece di eliminare la vecchia pagina quando ti sposti altrove, il browser congela l’intera pagina in memoria — tutto, compreso JavaScript in esecuzione — e la conserva sul ghiaccio. Se torni poco dopo e il browser ha ancora disponibile quella pagina congelata, la scongela e te la mostra di nuovo identica — nessuna richiesta di rete, nessuna attesa. È un possibile ripristino, non una garanzia: il browser può espellere una pagina congelata dalla memoria prima che tu prema Indietro (poca memoria, timeout, determinate attività), e allora ottieni un normale ricaricamento.

La descrizione in una riga di Google lo dice chiaramente: il bfcache è «a browser optimization that enables instant back and forward navigation.» (traduzione) «un’ottimizzazione del browser che consente una navigazione istantanea indietro e avanti.»

Perché non è «la cache» che già conosci

Questa è la parte che le persone confondono. Quando senti «cache» probabilmente pensi alla cache del browser o alla cache HTTP — i file (immagini, script, fogli di stile) che il browser salva per non doverli scaricare di nuovo. Il bfcache non è questo. Quelle cache conservano file; il bfcache conserva l’intera pagina viva, con stato JavaScript e tutto il resto, come un’istantanea. La documentazione Chrome lo spiega chiaramente: il bfcache «differs from browser cache and HTTP cache.» (traduzione) «è diversa dalla cache del browser e dalla cache HTTP.»

Non è nemmeno altre due cose che a volte vengono raggruppate insieme: la cache delle risorse nella memoria del browser (script compilati e immagini decodificate conservati per la sessione corrente) e la Cache Storage di un service worker (coppie richiesta/risposta che il sito gestisce esplicitamente con caches.open()). Entrambe possono essere attive sulla stessa pagina insieme al bfcache: sono meccanismi separati, non il bfcache.

Inoltre non è la vecchia funzione «pagina memorizzata» o «istantanea memorizzata» che Google e Bing offrivano nei risultati di ricerca (il piccolo menu che mostrava la versione di una pagina archiviata). Era una funzione di ricerca ed è stata ritirata. Il bfcache è una funzione live del browser che non ha nulla a che fare con i risultati di ricerca.

Il bfcache aiuta la mia SEO?

Non direttamente. Il bfcache non è un fattore di ranking Google: la documentazione Google sul ranking dei Core Web Vitals non lo menziona mai. Ciò che fa è rendere quasi istantanee le navigazioni Indietro/Avanti per i visitatori che ottengono davvero un ripristino, e i browser lo misurano come un eccellente «caricamento della pagina». Quindi, se molti visitatori usano Indietro e Avanti (acquisti, risultati di ricerca, lettura di un articolo dopo l’altro), il bfcache può migliorare i numeri di campo complessivi dei Core Web Vitals del sito: è una delle molte cose che Google dice essere coerenti con ciò che i suoi sistemi di ranking premiano. Sono due passaggi dopo «il bfcache aumenta il ranking» e non garantisce il tasso di ripristino, il punteggio CWV complessivo o il ranking, ma l’effetto è reale e misurabile.

Vuoi il quadro completo — che cosa blocca esattamente il bfcache, come testarlo e il rapporto preciso (senza sopravvalutazioni) con i Core Web Vitals? Passa alla scheda Advanced.

TL;DR — Il bfcache è un’istantanea in memoria dell’intera pagina (DOM + heap JS + stato in esecuzione), non una risposta HTTP recuperabile, la cache delle risorse nella memoria del browser o la Cache Storage di un service worker: questa è la distinzione concettuale numero 1 da fissare. Quando ti allontani, il browser mette in pausa JS e congela la pagina; con Indietro/Avanti, se l’istantanea congelata è ancora disponibile, la scongela e la ridisplaya istantaneamente senza richieste di rete, ma l’espulsione è sempre possibile: considera il ripristino probabile, non garantito. Non è un fattore di ranking Google documentato (i documenti Search Central sui Core Web Vitals non lo menzionano); la rilevanza è indiretta e circoscritta, attraverso la misurazione CWV di campo (soprattutto LCP e CLS) nelle navigazioni effettivamente ripristinate: non garantisce tasso di ripristino, punteggio CWV aggregato, ranking o conversioni. Il principale blocco all’idoneità è l’handler unload (circa 18 punti percentuali di tasso di utilizzo su Chrome); storicamente il maggiore era Cache-Control: no-store (bloccava circa il 17% delle navigazioni di cronologia mobile e il 7% di quelle desktop), anche se Chrome ora ammette condizionatamente molte pagine no-store (espulse al cambio di autenticazione/cookie e ancora bloccate dalle stesse API con connessioni aperte) dopo il rollout del 2025. Connessioni aperte, timer e observer vanno chiusi o messi in pausa su pagehide/freeze e ristabiliti su pageshow/resume; anche window.opener, policy delle permissions e frame possono bloccarlo: controlla la ragione per frame in DevTools o notRestoredReasons invece di supporre. Fai test una tantum con Chrome DevTools; diagnostica sul campo con l’API notRestoredReasons riservata a Chrome (un risultato null non prova un ripristino e il testo della ragione non è stabile). Ogni browser ha regole di idoneità proprie e le soft navigation delle SPA non ricevono lo stesso trattamento.

Che cos’è davvero il bfcache (la spina dorsale dell’accuratezza)

La cosa più importante da dire correttamente è questa: il bfcache è un’istantanea in memoria dell’intera pagina, non una risposta HTTP memorizzata. Quando lasci una pagina, invece di smontarla il browser mette in pausa l’esecuzione JavaScript e congela tutto — DOM, heap JS, timer in volo e il resto — conservandolo in memoria. Se premi Indietro o Avanti mentre l’istantanea è ancora disponibile, il browser la scongela e ridisplaya esattamente la pagina che avevi lasciato, con zero richieste di rete e zero nuovo rendering. È un ripristino possibile, non garantito: il browser può espellere l’istantanea prima del ritorno (pressione sulla memoria, timeout, determinati eventi), oppure una regola specifica del browser può imporre un caricamento nuovo; in tal caso è una normale navigazione nella cronologia. La formulazione canonica di Google è che il bfcache è «a browser optimization that enables instant back and forward navigation.» (traduzione) «un’ottimizzazione del browser che consente una navigazione istantanea indietro e avanti.»

Ecco perché confonderlo con la cache HTTP/browser è l’errore ricorrente dei concorrenti. La cache HTTP conserva risposte a richieste precedenti, cioè file da riservire. Il bfcache conserva la pagina viva in esecuzione. La documentazione Chrome DevTools traccia esplicitamente il confine: il bfcache «differs from browser cache and HTTP cache.» (traduzione) «è diversa dalla cache del browser e dalla cache HTTP.» Non «attivi» il bfcache con gli header di caching come configuri la cache HTTP: l’unico punto in cui entrano gli header è che Cache-Control: no-store in passato squalificava una pagina (ne parleremo più avanti).

La stessa distinzione vale rispetto ad altre due cache che vengono confuse con il bfcache: la cache delle risorse nella memoria del browser (script compilati e immagini decodificate conservati per la sessione corrente) e la Cache Storage di un service worker (coppie richiesta/risposta esplicite che il sito gestisce con caches.open()). Entrambe possono essere attive contemporaneamente al bfcache sulla stessa pagina, ma nessuna delle due è il bfcache, che è nello specifico l’istanza di pagina congelata, non asset memorizzati o risposte intercettate.

Un’altra distinzione è utile perché continua a generare confusione: il bfcache non ha nulla a che fare con la vecchia funzione di ricerca «pagina memorizzata» che Google (e Bing) mostravano un tempo nei risultati. Era un’istantanea archiviata di una pagina nell’indice di ricerca ed è stata ritirata. Il bfcache è una funzione del motore di rendering lato client.

Quanto sono comuni davvero le navigazioni Indietro/Avanti?

Non è un caso limite. Secondo web.dev, «1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.» (traduzione) «una navigazione desktop su 10 e una mobile su 5 è una navigazione indietro o avanti.» Su qualunque sito con flussi di ritorno — categoria-prodotto e ritorno nell’ecommerce, risultati di ricerca, contenuti paginati, lettura articolo-dopo-articolo — è una fetta consistente di navigazioni reali che puoi rendere quasi istantanee.

Supporto dei browser

«All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.» (traduzione) «tutti i principali browser includono una bfcache, compresi Chrome dalla versione 96, Firefox e Safari.» Firefox e Safari hanno implementazioni bfcache proprie e più longeve; tutti i browser basati su Chromium (Edge, Brave, Opera, Arc) ereditano quella di Chrome. La documentazione delle policy Edge di Microsoft descrive la stessa funzione: quando si lascia una pagina, il suo stato corrente (albero del documento, script e così via) può essere conservato nella back-forward cache e, se il browser torna indietro, la pagina può essere ripristinata e mostrata nello stato in cui si trovava prima di essere memorizzata. È abilitata di default in Edge; l’unico interruttore è una policy aziendale controllata dall’amministratore IT, non dal proprietario del sito.

La precisazione importante: il bfcache di ogni browser applica regole di idoneità proprie. Una pagina che supera «Test back/forward cache» in Chrome DevTools non è garantita come idonea in Firefox o Safari. Considera il passaggio Chrome necessario, non sufficiente.

Che cosa blocca l’idoneità al bfcache

L’evento unload — il blocco principale

Se ricordi una sola cosa di questo articolo: smetti di usare l’evento unload. web.dev lo sottolinea con rara enfasi per un documento Google: «Never use the unload event. Ever!» (traduzione) «non usare mai l’evento unload. Mai!» Su Chrome, gli handler unload costano circa una riduzione di 18 punti percentuali del tasso di utilizzo del bfcache, di gran lunga la più grande esclusione auto-inflitta.

Chrome lo sta deprecando attivamente per due ragioni. Primo, è il maggiore blocco al bfcache. Secondo, unload è estremamente inaffidabile in partenza: sui dispositivi mobili spesso non viene eseguito perché le schede passano in background e vengono terminate e il browser privilegia il bfcache rispetto all’esecuzione di unload. Quindi l’evento su cui fai affidamento per la «pulizia» spesso non viene eseguito e blocca un vero vantaggio prestazionale.

Le correzioni:

• Sostituisci unload con pagehide. L’evento pagehide si verifica in ogni caso in cui si verificherebbe unload, più quando una pagina entra nel bfcache: è quindi un miglioramento netto. Usa visibilitychange per una pulizia affidabile quando «l’utente se ne va».
• Rileva un ripristino bfcache con pageshow. Ascolta pageshow e controlla event.persisted: se è true, la pagina è stata ripristinata dal bfcache; è il momento di aggiornare dati obsoleti o ricontare una visualizzazione.
• Blocca in modo proattivo gli ascoltatori unload con l’header di risposta Permissions-Policy: unload=(), che impedisce del tutto la registrazione degli handler unload. Chrome sta spostando gradualmente la policy predefinita verso deny (una Permissions-Policy per unload è stata rilasciata da Chrome 115).

Cache-Control: no-store — storicamente il blocco più grande, oggi più sfumato

È il punto sulla freschezza che la maggior parte dei contenuti concorrenti sbaglia. Storicamente, Cache-Control: no-store era la singola ragione principale per cui le pagine venivano escluse dal bfcache: le cifre Chrome lo stimavano in circa 17% delle navigazioni nella cronologia mobile e 7% di quelle desktop. Molti siti impostano no-store in modo difensivo per non servire una pagina obsoleta, ma l’argomento Google è che un ripristino bfcache non carica una risposta cache obsoleta: ridisplaya la pagina viva esatta, quasi come se la scheda fosse rimasta aperta.

Chrome ha quindi cambiato il comportamento, ma in modo condizionale, non universale. Gli esperimenti sono iniziati in Chrome 116, con il rollout finale al 100% degli utenti tra marzo e aprile 2025: ora Chrome ammette molte pagine no-store nel bfcache, soggette a condizioni di sicurezza specifiche invece che a un’eccezione generale. Secondo la documentazione Chrome, esistono vincoli reali: la pagina viene espulsa dal bfcache se cambiano lo stato di autenticazione o i cookie mentre è congelata (così un visitatore disconnesso o con cookie cancellati non vede un’istantanea autenticata obsoleta) e un elenco fisso di API — le stesse API per connessioni aperte descritte sotto (IndexedDB, WebSocket, WebRTC e le altre) — continua a escludere una pagina no-store dal bfcache come qualunque altra pagina. È un comportamento specifico di Chrome in un intervallo di versioni preciso, non una regola da presumere per gli altri browser o per versioni Chrome più vecchie: recupera il report DevTools/notRestoredReasons corrente per browser e versione che stai testando invece di fidarti di una regola fissa. La conseguenza pratica: qualsiasi guida (comprese le versioni vecchie di questa) che elenchi no-store come blocco incondizionato e permanente al bfcache è obsoleta, ma lo è anche trattarlo come completamente risolto. Se la freschezza conta davvero, la documentazione Chrome suggerisce no-cache o un max-age breve (per esempio max-age=60) invece di no-store.

Connessioni aperte, observer e altri blocchi

Al momento della navigazione, alcune risorse aperte possono ancora bloccare l’idoneità, e proprio quali lo facciano — e se blocchino del tutto o vengano solo chiuse e ricollegabili — dipende dal browser e dalla versione. Considera l’elenco sotto come esempi di un modello, non come una lista fissa e permanente.

• Richieste fetch() / XMLHttpRequest in corso.
• Transazioni IndexedDB aperte.
• Connessioni WebSocket / WebRTC, timer e observer aperti (MutationObserver, IntersectionObserver e simili). È un’area in evoluzione: le note di rilascio recenti di Microsoft Edge mostrano che un WebSocket aperto ora viene chiuso quando la pagina entra nel bfcache (invece di bloccare la cache del tutto), con riconnessione raccomandata tramite l’evento pageshow e il controllo di event.persisted. Questo rispecchia la tendenza più ampia di Chrome a ridurre i blocchi invece di escludere semplicemente le pagine.

Il modello generale da implementare, invece di imparare a memoria una lista fissa: chiudi o metti in pausa connessioni aperte, timer e observer nella gestione pagehide/freeze e ristabiliscili nella gestione pageshow/resume quando event.persisted è true. Questo modello resta valido anche se un browser cambia quali API bloccano del tutto l’idoneità e quali invece sospende lasciando che tu ti ricolleghi.

window.opener, policy delle permissions e frame. Un riferimento window.opener, alcune policy delle permissions e iframe incorporati (della stessa origine o di origine diversa) possono influire sull’idoneità: è quanto compare nella checklist che ho ricavato dalla guida CLS di Ahrefs e nella documentazione Chrome. Non presumere però la causa reale da una checklist generica: il pannello DevTools e l’API notRestoredReasons riportano le ragioni di blocco per frame, per il frame principale e per ogni iframe, perché il frame responsabile non è sempre la pagina di livello superiore. Recupera la ragione reale dal report per frame del browser che stai testando invece di indovinare da un elenco generale.

Ottenere correttamente la sequenza evento/stato del ciclo di vita

Confondere ciò che ogni evento del ciclo di vita prova con ciò che si limita a suggerire è il secondo bug di correttezza più comune qui, dopo gli errori di idoneità già descritti:

La regola pratica: tratta pagehide.persisted come intento, non come prova: la pagina può essere espulsa prima che tu veda un ripristino. Solo pageshow.persisted === true dimostra che un ripristino è avvenuto. Esegui la pulizia incondizionatamente su pagehide/freeze (è economico e sicuro anche in una normale navigazione) e svolgi il lavoro specifico del ripristino solo su pageshow/resume, condizionato da event.persisted, così non aggiorni dati e non conti due volte una visualizzazione analytics in un semplice caricamento nuovo.

Come testare e diagnosticare il bfcache

Laboratorio / una tantum: Chrome DevTools

Apri DevTools → Application → Background services → Back/forward cache, poi fai clic su «Test back/forward cache.» (traduzione) «Testa la cache back/forward.» Chrome naviga automaticamente a chrome://terms/ e torna indietro, quindi segnala successo o un elenco specifico delle ragioni di blocco. È utile per controllare un URL alla volta.

Campo / produzione: API notRestoredReasons

In passato l’unico modo per controllare l’idoneità era il test DevTools manuale, un URL alla volta: non c’era modo di capire perché le navigazioni degli utenti reali fossero bloccate. La proprietà notRestoredReasons di PerformanceNavigationTiming (rilasciata in Chrome 123+) colma il divario: segnala le ragioni specifiche di blocco per il frame principale e gli iframe della stessa origine nei dati reali di campo.

const nav = performance.getEntriesByType('navigation')[0];
console.log(nav.notRestoredReasons);

Ecco alcune cose da fare correttamente, direttamente dalle indicazioni API di Chrome:

• È solo Chrome (123+). Firefox e Safari non espongono un’API di campo equivalente, quindi per conoscere il tasso di ripristino devi ancora fare controlli manuali in quei browser.
• Un risultato null è ambiguo, non un semaforo verde. Può significare che la pagina è stata ripristinata oppure che il browser non ha raccolto una ragione; la documentazione Chrome dice di non trattare null come prova di un ripristino riuscito.
• Il testo della ragione non è un contratto stabile. Non codificare corrispondenze di stringhe; raggruppa e osserva le tendenze per ragione, perché la formulazione esatta può cambiare tra versioni Chrome.

In pratica: raccogli notRestoredReasons insieme ai tassi di ripristino pageshow.persisted prima e dopo il rilascio di una correzione, confronta la tendenza invece di una singola istantanea e abbinala a un passaggio manuale DevTools/lab in Firefox e Safari per i browser che l’API non può raggiungere. È lo strumento da usare per diagnosticare il bfcache su larga scala in RUM/produzione invece di controllare gli URL uno per uno, ma non trattarlo come il quadro completo.

Bfcache e Core Web Vitals — il rapporto preciso

Ecco la sfumatura che la maggior parte dei contenuti concorrenti appiattisce e l’angolo che vale la pena presidiare.

Come si misura un ripristino bfcache. I browser (e quindi i dati di campo CrUX) contano una navigazione ripristinata dal bfcache come un «caricamento pagina» estremamente rapido: LCP quasi istantaneo e, quando la pagina è implementata correttamente (nulla deve ricalcolare il layout), zero CLS aggiuntivo in pratica, perché non c’è nuovo rendering. Nel confronto reale di DebugBear, una pagina ripristinata dal bfcache ha ottenuto un LCP di circa 100ms contro ~427ms per un caricamento non in cache. È esattamente il motivo per cui il bfcache appare come leva per CLS e LCP nella mia checklist CLS di Ahrefs, dove lo riassumo così: «Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.» (traduzione) «Assicurati che le pagine siano idonee alla bfcache. La cache back/forward conserva le pagine nella cache del browser e permette di caricare istantaneamente una pagina già caricata, evitando variazioni del layout.»

Due precisazioni di ambito meritano accuratezza, perché è qui che i contenuti concorrenti tendono a esagerare. Primo: l’effetto riguarda solo le navigazioni che CrUX classifica come Indietro/Avanti (la dimensione navigation-type); non dice nulla sulle navigazioni di prima visita o sui ricaricamenti, che sono la maggior parte del traffico su molti siti. Secondo: un ripristino che migliora l’esperienza misurata per gli utenti che lo ricevono non equivale a una garanzia: chi viene espulso dalla bfcache (vedi la tabella del ciclo di vita) ottiene comunque un caricamento normale e non migliorato, quindi il lavoro sull’idoneità della bfcache sposta il tasso di ripristino tra le navigazioni Indietro/Avanti, non una quota fissa del traffico totale — e non garantisce la valutazione aggregata dei Core Web Vitals di campo, il ranking o il tasso di conversione. È una leva reale e misurabile con un ambito preciso e limitato, non una correzione generale delle prestazioni o della SEO.

Il bfcache è un fattore di ranking? No. Questa è l’affermazione difendibile e distintiva. La documentazione Google sul ranking dei Core Web Vitals non menziona affatto il bfcache. La catena onesta è: idoneità bfcache → numeri CWV di campo migliori (soprattutto LCP/CLS) nelle navigazioni Indietro/Avanti → i Core Web Vitals sono uno dei molti segnali di «esperienza di pagina» che Google dice essere allineati a ciò che i suoi sistemi di ranking già premiano. È un’affermazione molto più debole e precisa di «il bfcache aumenta il ranking»: ed è quella che i contenuti concorrenti dovrebbero fare, ma di solito non formulano con cura. Il bfcache è inoltre, correttamente, una funzione del motore di rendering, non del crawler: non riguarda il modo in cui Googlebot o Bingbot eseguono il crawl delle pagine, perciò non esiste una «posizione di Bing sul bfcache per la SEO» analoga a quella su robots.txt o sitemap.

SPA e soft navigation. Il bfcache opera sulle navigazioni reali del browser e sugli eventi della cronologia. Il cambio di rotta «soft» lato client di una single-page app (uno scambio di vista guidato da JS che non attiva una navigazione reale del browser) non è un evento bfcache e non riceve lo stesso trattamento. I tentativi di alcuni strumenti RUM di attribuire i Core Web Vitals alle soft navigation possono creare discrepanze di misurazione tra CrUX e RUM: un punto da segnalare se stai verificando un sito basato su un framework JS.

Quanto sono diffusi i blocchi al bfcache nel mondo reale?

Il Web Almanac di HTTP Archive tiene traccia del fenomeno, che è vivo e in movimento, non una notizia vecchia ormai definita. Nell’edizione 2022 almeno il ~22% delle pagine mobile non era idoneo al bfcache solo per i criteri unload e no-store. Da allora l’uso degli handler unload è diminuito nelle diverse fasce di siti e dispositivi, ma l’uso di Cache-Control: no-store è aumentato (il capitolo 2025 lo colloca intorno al 23% dei siti, rispetto a circa il ~21% nel 2024, in parte per l’aumento delle esperienze autenticate/personalizzate e per requisiti di conformità più severi).

La scoperta controintuitiva da citare: i siti più grandi e con più traffico sono sproporzionatamente più propensi a bloccare il proprio bfcache. Tra i primi 1 000 siti, circa il 28% delle pagine desktop e il 20% di quelle mobile usa ancora handler unload, contro solo ~11% desktop / ~10% mobile su tutti i siti, spesso perché i siti più grandi portano più codice legacy di analytics e dipendente da unload. I siti che hanno più traffico Indietro/Avanti da perdere sono spesso quelli che continuano a ostacolarsi da soli.

Dove si colloca

Il bfcache è una leva di performance tra diverse in questo cluster. Il suo vantaggio si vede nei dati di campo dei Core Web Vitals, in particolare in Cumulative Layout Shift e Largest Contentful Paint, perché una pagina ripristinata viene ridisplayata istantaneamente senza ricalcolo del layout. È distinto dalla caching, che conserva file invece di un’istantanea di pagina viva, anche se le due cose condividono l’header Cache-Control come punto di contatto. Non esiste un legame diretto con Interaction to Next Paint, quindi non ne forzerò uno.

Riepilogo AI

Una versione condensata della scheda Advanced:

• Bfcache = un’istantanea in memoria dell’intera pagina (DOM + heap JS + stato in esecuzione), non una risposta HTTP recuperabile, la cache delle risorse nella memoria del browser o la Cache Storage di un service worker. Quando ti allontani il browser mette in pausa JS e congela la pagina; con Indietro/Avanti, se l’istantanea è ancora disponibile, la scongela e la ridisplaya all’istante senza richieste di rete: l’espulsione è sempre possibile, quindi il ripristino è probabile, non garantito. La documentazione Chrome dice che la bfcache è diversa dalla cache del browser e dalla cache HTTP. Inoltre non è la vecchia funzione di ricerca «cached page», ormai ritirata.
• Non è un fattore di ranking ed è circoscritto. I documenti Google sui Core Web Vitals non menzionano mai il bfcache. La catena reale è indiretta: idoneità bfcache → numeri CWV di campo migliori (soprattutto LCP/CLS) nelle navigazioni Indietro/Avanti ripristinate → CWV come uno dei segnali di esperienza di pagina che Google dice allineati ai suoi sistemi di ranking. Non garantisce tasso di ripristino, CWV aggregati, ranking o conversioni e riguarda solo le navigazioni che CrUX classifica come Indietro/Avanti.
• Scala: una navigazione desktop su 10 e una mobile su 5 è una navigazione indietro o avanti. Supporto: Chrome dalla versione 96, oltre a Firefox e Safari, ma ogni browser ha regole di idoneità proprie.
• Blocco principale: l’evento unload, che la fonte invita categoricamente a non usare, che costa circa 18 punti percentuali al tasso di utilizzo Chrome. Sostituiscilo con pagehide + visibilitychange, rileva i ripristini con pageshow/event.persisted e blocca unload con Permissions-Policy: unload=().
• Cache-Control: no-store era storicamente il blocco più grande (circa 17% delle navigazioni di cronologia mobile / 7% desktop). Ora Chrome ammette condizionatamente molte pagine no-store dopo il rollout tra marzo e aprile 2025: le espelle se cambiano autenticazione/cookie, le blocca ancora per le stesse API con connessioni aperte e lo fa solo su Chrome. Le guide vecchie che lo definiscono blocco assoluto sono obsolete, ma lo è anche considerarlo completamente risolto.
• Altri blocchi: fetch/XHR in corso, timer, observer, IndexedDB aperto, WebSocket/WebRTC (chiudi/metti in pausa su pagehide/freeze, ricollega su pageshow/resume), window.opener, policy delle permissions e frame: recupera la ragione per frame da DevTools/notRestoredReasons invece di supporre.
• Correttezza del ciclo di vita: pagehide.persisted è intento, non prova; solo pageshow.persisted === true conferma un ripristino. Fai la pulizia incondizionatamente su pagehide/freeze e il lavoro specifico del ripristino (aggiorna dati sensibili, ricollega, conta una visualizzazione) solo su pageshow/resume.
• Test: Chrome DevTools «Test back/forward cache» (laboratorio una tantum); API notRestoredReasons riservata a Chrome (Chrome 123+) per dati di campo: null non prova un ripristino, il testo della ragione non è stabile e Firefox/Safari richiedono controlli manuali. Confronta tassi notRestoredReasons e pageshow.persisted prima/dopo una correzione.
• SPA: le soft navigation lato client non sono eventi bfcache e non ricevono lo stesso trattamento (una fonte di discrepanze CrUX-RUM).
• Adozione (Web Almanac): l’uso di no-store cresce (~21%→23%) e l’uso di unload è maggiore sui siti più grandi (~28% desktop tra i primi 1 000): i siti grandi spesso bloccano il proprio bfcache.

Documentazione ufficiale

Documentazione di fonte primaria sul bfcache. Nota la distinzione delle fonti: il bfcache vive nei documenti Chrome / del motore di rendering (la voce istituzionale di Google in questo tema), non in Google Search Central: la separazione è essa stessa il punto.

Google / Chrome

• Back/forward cache — il documento canonico: definizione, meccanismo, statistica 1 su 10 / 1 su 5 e indicazioni su unload.
• Test back/forward cache — passaggi di test DevTools, blocchi principali e distinzione esplicita rispetto alla cache del browser e alla cache HTTP.
• Abilitare la bfcache per Cache-Control: no-store — modifica di policy del 2025, cifre 17% / 7% e cronologia del rollout.
• Dismissione dell’evento unload — perché unload viene dismesso e la migrazione Permissions-Policy.
• Back/forward cache notRestoredReasons API — diagnostica di campo su PerformanceNavigationTiming (Chrome 123+).
• Comprendere i Core Web Vitals e i risultati di Ricerca Google — documento di ranking di Google Search Central, citato qui come prova che non menziona mai il bfcache.

Microsoft / Edge

• Microsoft Edge policy: BackForwardCacheEnabled — definizione Edge, stessa avvertenza su unload e interruttore di policy aziendale.

MDN / standard web

• bfcache — MDN Glossary — definizione generale indipendente dal motore e distinzione dalla cache HTTP.
• Monitoring bfcache blocking reasons — MDN — uso pratico di notRestoredReasons.

Citazioni dalla fonte

Indicazioni documentate dalla fonte. Ogni link porta direttamente al passaggio citato nella pagina sorgente.

Google / Chrome — che cos’è il bfcache e perché conta

• «Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation.» (traduzione) «La cache back/forward, o bfcache, è un’ottimizzazione del browser che consente una navigazione istantanea indietro e avanti.» — web.dev. Vai alla citazione
• «1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!» (traduzione) «Una navigazione desktop su 10 e una mobile su 5 è una navigazione indietro o avanti. Con la bfcache attiva, ogni giorno i browser potrebbero eliminare il trasferimento di dati e il tempo di caricamento per miliardi di pagine web!» Vai alla citazione
• «All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.» (traduzione) «tutti i principali browser includono una bfcache, compresi Chrome dalla versione 96, Firefox e Safari.» Vai alla citazione

Google / Chrome — la regola di ottimizzazione numero 1

• «Never use the unload event. Ever!» (traduzione) «non usare mai l’evento unload. Mai!» — web.dev. Vai alla citazione

Chrome DevTools — il bfcache non è la cache HTTP

• «Back/forward cache differs from browser cache and HTTP cache.» (traduzione) «La cache back/forward è diversa dalla cache del browser e dalla cache HTTP.» — documentazione Chrome DevTools. Vai alla citazione

Microsoft Edge — stessa funzione, stessa avvertenza

• «When navigating away from a page, its current state (document tree, script, and so on) may be preserved in the back-forward cache. If the browser navigates back to the page, the page may be restored from the back-forward cache and displayed in the state it was in before being cached.» (traduzione) «Quando ci si allontana da una pagina, il suo stato corrente (albero del documento, script e così via) può essere conservato nella cache back/forward. Se il browser torna alla pagina, questa può essere ripristinata dalla cache e mostrata nello stato precedente alla memorizzazione.» — documentazione delle policy Microsoft Edge. Vai alla citazione

Patrick Stox (io) — il bfcache come leva CLS

• «Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.» (traduzione) «Verifica che le pagine siano idonee alla bfcache: la cache back/forward conserva nel browser le pagine già caricate e le ripristina all’istante, senza provocare spostamenti del layout.» — la mia guida CLS di Ahrefs. Leggi

Checklist per l’idoneità al bfcache

Un passaggio per confermare che le pagine possano entrare nella back/forward cache:

• Nessun listener unload in tutta la pagina (tuo o di script di terze parti). È il blocco principale.
• Sposta il codice di pulizia/analytics da unload a pagehide e visibilitychange.
• Un listener pageshow controlla event.persisted per aggiornare dati obsoleti e ricontare correttamente le visualizzazioni dopo un ripristino bfcache.
• Valuta l’header di risposta Permissions-Policy: unload=() per bloccare la registrazione di listener unload.
• Verifica Cache-Control: no-store: se lo imposti per difesa, conferma che serva ancora (Chrome 2025+ ammette condizionatamente molte pagine no-store, espulse al cambio di autenticazione/cookie e ancora bloccate dalle stesse API con connessioni aperte; non presumere che altri browser o versioni si comportino allo stesso modo); se conta la freschezza, preferisci no-cache o un max-age breve.
• Nessuna connessione aperta, timer o observer lasciato in sospeso al momento della navigazione: fetch/XHR in corso, transazioni IndexedDB aperte, WebSocket/WebRTC, MutationObserver/IntersectionObserver (chiudi/metti in pausa su pagehide/freeze e ristabilisci su pageshow/resume quando event.persisted è true).
• Nessun riferimento window.opener, policy delle permissions restrittive o frame bloccati che rendano la pagina non idonea: controlla la ragione per frame in DevTools/notRestoredReasons invece di supporre quale si applichi.
• Test di laboratorio: pagina in Chrome DevTools → Application → Back/forward cache → «Test back/forward cache.»
• Diagnostica di campo: notRestoredReasons su larga scala nel tuo RUM (solo Chrome; null non prova un ripristino e il testo della ragione non è un contratto stabile: osserva la tendenza per ragione, non codificare stringhe).
• Non presumere che un passaggio Chrome = idoneità ovunque: controlla Firefox e Safari, che applicano regole proprie.

Cheat sheet del bfcache

Che cosa lo blocca e correzione

Eventi da conoscere

Testalo

Dati rapidi

• Bfcache = pagina viva intera in memoria, non file, non cache delle risorse, non Cache Storage del service worker. Chrome conferma che è distinta dalla cache del browser e dalla cache HTTP.
• Non è un fattore di ranking Google: i documenti CWV di Search Central non lo menzionano. Un ripristino migliora LCP/CLS misurati per gli utenti che lo ottengono, ma non garantisce tasso di ripristino, CWV aggregati, ranking o conversioni.
• Supporto: Chrome 96+, Firefox, Safari, ciascuno con regole proprie.
• 1 su 10 desktop / 1 su 5 mobile navigazioni sono Indietro/Avanti.

Anti-pattern del bfcache (e miti correlati)

«Il bfcache è solo la mia cache HTTP/browser: lo configuro con Cache-Control.» No. Il bfcache è un’istantanea distinta dell’intera pagina in memoria; la documentazione Chrome la distingue dalla cache del browser e dalla cache HTTP. Gli header di caching contano solo nella misura in cui no-store in passato squalificava una pagina. Non «attivi» il bfcache con gli header di cache.

«Il bfcache è un fattore di ranking Google, quindi correggerlo aumenta il ranking.» Non è stabilito da alcuna fonte ufficiale Google Search. Il documento di ranking sui Core Web Vitals non menziona il bfcache. Il rapporto reale è indiretto (LCP/CLS di campo migliori sulle navigazioni Indietro/Avanti), un’affermazione più debole e precisa.

«Cache-Control: no-store blocca sempre e per sempre il bfcache.» Storicamente vero, e ancora la causa storica principale, ma non più categoricamente vero dopo il rollout completo 2025 del bfcache sicuro con no-store. Le guide precedenti alla modifica sono obsolete su questo punto preciso, ma lo è anche considerarlo completamente risolto: l’eccezione Chrome è condizionale (espulsione al cambio di autenticazione/cookie, ancora bloccata dalle stesse API con connessioni aperte) e specifica di Chrome, non un via libera universale.

«Una pagina che attiva pagehide con persisted: true è sicuramente stata memorizzata.» No: è intento, non prova. Il browser può ancora espellere la pagina prima che tu veda un ripristino. Solo pageshow.persisted === true conferma che un ripristino è realmente avvenuto.

«Se supera il test bfcache di Chrome DevTools è idonea ovunque.» Falso. Chrome, Firefox e Safari applicano restrizioni proprie; un passaggio in uno non garantisce l’idoneità negli altri.

«unload è un modo valido per eseguire codice di uscita/pulizia, quindi lo manterrò.» No: Chrome lo considera estremamente inaffidabile (sui dispositivi mobili spesso non viene eseguito affatto) e lo sta deprecando con una Permissions-Policy proprio perché è il maggiore blocco al bfcache. Usa pagehide + visibilitychange.

«Il bfcache aiuta la mia SPA come un sito multipagina.» Non senza qualifiche. Il bfcache è legato alle navigazioni reali del browser; un cambio di rotta «soft» lato client non è lo stesso evento e non riceve lo stesso trattamento, causando anche discrepanze CrUX-RUM sui siti ricchi di SPA.

«Il bfcache è risolto / una vecchia notizia, non vale la pena controllarlo.» I dati del Web Almanac lo contraddicono: l’uso di no-store sta crescendo e l’uso di unload resta notevolmente più alto sui siti più grandi e con più traffico, quelli che hanno più navigazioni Indietro/Avanti da perdere.

Strumenti per testare e diagnosticare il bfcache

• Chrome DevTools — pannello Back/forward cache. Application → Background services → Back/forward cache → «Test back/forward cache.» (traduzione) «Testa la cache back/forward.» Naviga automaticamente a chrome://terms/ e torna indietro, poi segnala successo o le ragioni esatte di blocco. È ideale per un controllo di laboratorio una tantum su un singolo URL.
• API notRestoredReasons (Chrome 123+). Leggi performance.getEntriesByType('navigation')[0].notRestoredReasons nel tuo RUM per vedere su larga scala le ragioni di blocco degli utenti reali, inclusi gli iframe della stessa origine, non solo in un test manuale di laboratorio.
• PageSpeed Insights / Lighthouse / CrUX. È qui che in un audit appare spesso per la prima volta una raccomandazione o un flag sul «back/forward cache» e dove emerge il vantaggio CWV di campo di un sito idoneo al bfcache.
• Header Permissions-Policy: unload=(). Non è uno strumento di test, ma la leva di applicazione: impostalo per impedire attivamente la registrazione di listener unload, compresi quelli di terze parti.
• Capitolo Performance del Web Almanac (HTTP Archive). Per confrontare la diffusione dei blocchi bfcache sul web per dispositivo e fascia di ranking del sito.

DevTools dice che un handler unload ha bloccato il ripristino

Sintomo: il test Back/forward cache nomina unload. Causa probabile: codice di prima o terze parti ha registrato un listener unload. Correzione: sostituisci la pulizia con pagehide/visibilitychange, aggiungi Permissions-Policy: unload=() dove appropriato e ripeti il test dopo ogni modifica agli script interessati.

Una pagina ripristinata mostra dati utente obsoleti

Sintomo: Indietro torna istantaneamente ma lo stato dell’account, l’inventario o un altro valore dinamico è obsoleto. Causa probabile: la pagina ha ripreso lo stato congelato senza aggiornare i dati sensibili al tempo. Correzione: ascolta pageshow, controlla event.persisted e aggiorna solo i dati richiesti. Conferma che caricamenti normali e ripristini si comportino correttamente.

Analytics perde o raddoppia le visualizzazioni Indietro/Avanti

Sintomo: le visualizzazioni di pagina differiscono dalle navigazioni reali nella cronologia. Causa probabile: analytics viene eseguito solo al caricamento originario oppure due volte senza distinguere il ripristino. Correzione: gestisci esplicitamente pageshow e usa event.persisted per contare una sola volta la navigazione ripristinata.

Il laboratorio passa ma il ripristino sul campo resta basso

Sintomo: un URL campionato passa DevTools mentre il RUM segnala molti mancati ripristini. Causa probabile: altri template, browser, stati reali degli utenti o connessioni aperte intermittenti aggiungono blocchi. Correzione: raccogli notRestoredReasons, raggruppa per ragione e template e riproduci il caso di campo dominante invece di estrapolare da un solo passaggio.

Dimostrare che una correzione bfcache è arrivata

Test di idoneità

Test da eseguire: DevTools → Application → Back/forward cache → Test back/forward cache. Risultato atteso: la pagina viene ripristinata con successo senza ragioni di blocco. Interpretazione del fallimento: rimane almeno un blocco di idoneità. Finestra di monitoraggio: immediata per Chrome nello stato testato. Trigger di rollback: la correzione rompe pulizia, sicurezza o comportamento applicativo richiesto.

Test del comportamento di ripristino

Test da eseguire: naviga altrove e premi Indietro, poi verifica che pageshow riceva event.persisted === true e che i dati sensibili al tempo si aggiornino. Risultato atteso: un ripristino istantaneo, dati corretti e una visualizzazione analytics. Interpretazione del fallimento: la pagina non è stata memorizzata oppure la gestione del ripristino è incompleta. Finestra di monitoraggio: immediata su stati rappresentativi con e senza login. Trigger di rollback: dati sensibili obsoleti o azioni duplicate dopo il ripristino.

Test delle ragioni sul campo

Test da eseguire: monitora PerformanceNavigationTiming.notRestoredReasons nel RUM. Risultato atteso: il blocco target diminuisce per i template interessati senza che un nuovo blocco dominante lo sostituisca. Interpretazione del fallimento: il campione di laboratorio non rappresentava la produzione oppure il problema appartiene a un’altra dipendenza. Finestra di monitoraggio: traffico reale Indietro/Avanti sufficiente per confrontare la stessa combinazione di template. Trigger di rollback: regressione applicativa o d’integrità dei dati materiale legata alla modifica.

Metriche bfcache da mantenere

Tasso di ripristino

Metrica: navigazioni Indietro/Avanti idonee ripristinate dal bfcache. Che cosa indica: quanto spesso gli utenti ricevono il vantaggio della navigazione istantanea. Come raccoglierla: voci di navigazione RUM e pageshow.persisted, segmentate per browser e template. Benchmark / intervallo realistico: stabilisci il tuo baseline, perché regole del browser, stato della pagina e mix di navigazione differiscono. Cadenza: ogni settimana e dopo modifiche al ciclo di vita.

Ragioni del mancato ripristino

Metrica: navigazioni nella cronologia raggruppate per notRestoredReasons. Che cosa indica: quali blocchi costano più ripristini reali. Come raccoglierla: API PerformanceNavigationTiming nei browser supportati. Benchmark / intervallo realistico: punta a zero per i blocchi controllati dal tuo codice, indicando la copertura di browser/API. Cadenza: triage settimanale.

Correttezza della navigazione ripristinata

Metrica: errori, incidenti di dati obsoleti e analytics/azioni duplicate dopo un ripristino. Che cosa indica: se una maggiore idoneità preserva la correttezza dell’applicazione. Come raccoglierla: eventi di errore RUM, monitoraggio applicativo e QA analytics associata a pageshow.persisted. Benchmark / intervallo realistico: zero problemi noti di correttezza o privacy. Cadenza: alert continuo e QA a ogni rilascio.

Risorse che vale la pena leggere

I miei contenuti correlati

• Che cos’è il Cumulative Layout Shift (CLS) e come migliorarlo — dove indico l’idoneità bfcache come tattica per migliorare CLS, con la checklist breve dei blocchi.
• Che cosa sono i Core Web Vitals (CWV) e come migliorarli — le metriche madri, con il bfcache come una leva CLS tra molte.
• Guida introduttiva alla SEO tecnica — dove le prestazioni web entrano nel quadro più ampio.

I miei interventi

• Come funziona la ricerca (SlideShare) — il mio percorso su scansione, renderizzazione, indicizzazione e posizionamento, per capire perché una funzione del motore di rendering come il bfcache stia fuori dai segnali di ranking della ricerca. (Vale il mio disclaimer permanente: «This is my understanding of systems… not going to be 100% complete or accurate.» (traduzione) «Questa è la mia comprensione dei sistemi: non sarà completa o accurata al 100%.»)

Ufficiali

• Back/forward cache (web.dev) — il documento canonico.
• Abilitare la bfcache per Cache-Control: no-store e Dismissione dell’evento unload (Chrome for Developers) — le due modifiche che rendono obsolete le guide vecchie.
• Comprendere i Core Web Vitals e i risultati di Ricerca Google (Google Search Central) — il documento di ranking che, significativamente, non menziona mai il bfcache.

Dal settore

• bfcache — MDN Glossary — definizione accurata e indipendente dal motore e distinzione dalla cache HTTP.
• Che cosa significa la cache back/forward per la velocità del sito? (DebugBear) — l’articolo più basato sui dati in questo campo, con un log di sito reale e un confronto LCP concreto (~100ms in cache contro ~427ms senza cache).
• Spiegazione della cache back/forward (SpeedVitals) — meccanica, idoneità, test e impatto CWV.
• Cache back/forward: che cos’è e come implementarla (NitroPack) — orientato all’implementazione, per pubblico CMS/hosting.
• Una svolta per le prestazioni: la cache back/forward del browser (Smashing Magazine) — buon approfondimento tecnico, ma precedente alla modifica no-store del 2025.
• Web Almanac — capitolo Prestazioni (2025) (HTTP Archive) — dati reali sulla prevalenza di unload e no-store per dispositivo e fascia di ranking.

Statistiche da citare

• Le navigazioni Indietro/Avanti sono comuni: una navigazione desktop su 10 e una mobile su 5 è una navigazione indietro o avanti — la scala dell’opportunità, non un caso limite. Fonte
• unload costa circa 18 punti percentuali del tasso di utilizzo bfcache su Chrome, motivo per cui è il blocco principale ed è in fase di dismissione. Fonte
• Cache-Control: no-store era il maggiore blocco storico — circa 17% delle navigazioni di cronologia mobile e 7% desktop — prima del rollout Chrome tra marzo e aprile 2025, che ha ammesso il bfcache per molte pagine no-store. Fonte
• Un ripristino bfcache è quasi istantaneo: DebugBear ha misurato circa 100ms di LCP per una pagina ripristinata contro ~427ms per un caricamento senza cache. Fonte
• I siti grandi si bloccano di più: tra i primi 1 000 siti circa il 28% delle pagine desktop e il 20% delle mobile usa ancora handler unload, contro ~11% / ~10% su tutti i siti; l’uso di no-store è in crescita (~21%→23%). Fonte

Mettiti alla prova: Back/Forward Cache (bfcache)

Cinque domande rapide su che cos’è il bfcache, che cosa lo blocca e come si collega alla SEO. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche