La cache HTTP tiene risposte. La bfcache tiene la pagina, JavaScript compreso. no-store sulla pagina, storicamente, la esclude. Il restore non rivalida. Non è l’INP.
La cache HTTP conserva risposte. La bfcache (back/forward cache) conserva la pagina intera in memoria, heap JavaScript compreso. Non è lo stesso cassetto e non è l’INP. Verifica del 12 ottobre 2026 su web.dev/articles/bfcache, pagina aggiornata il 2 luglio 2026 (Barry Pollard; prima pubblicazione 25 maggio 2023).
In breve: il tasto Indietro può riaprire uno snapshot, senza rifare le richieste. Cache-Control: no-store sulla pagina, storicamente, tiene fuori dalla bfcache. no-cache e max-age=0 no. L’evento unload è il modo più sicuro per restarne fuori, su desktop, in Chrome e Firefox. Un restore non è una navigazione HTTP e non rivalida.
Cosa trovi in questo articolo
Due cache, non una
La guida Back/forward cache, rilettura 12 ottobre 2026: «The "cache" used by bfcache is different from the HTTP cache». La bfcache è uno snapshot dell’intera pagina in memoria, heap JavaScript incluso. La cache HTTP contiene solo le risposte di richieste già fatte. Il pezzo canonico su quelle risposte resta cache HTTP. Il cluster è Performance.
Stessa pagina: è raro che tutte le richieste di un documento escano dalla sola cache HTTP, quindi un restore da bfcache è più rapido anche della ripetizione meglio ottimizzata senza bfcache. Non è una metrica di campo. L’INP misura altro: il pezzo INP non è FID non va letto come una scheda sulla bfcache.
Quali header la bloccano
Cache-Control: no-store dice al browser di non mettere la risposta in nessuna cache HTTP. Si usa per pagine con dati sensibili, per esempio dietro login. La bfcache non è una cache HTTP, ma — scrive web.dev — storicamente, se no-store sta sulla risorsa pagina (non su un sotto-risorsa), i browser hanno scelto di non conservarla in bfcache. C’è un lavoro in corso per cambiare questo comportamento in Chrome in modo che rispetti la privacy. Finché la pagina lo scrive così, no-store restringe l’idoneità e va tenuto solo dove nessun tipo di cache è accettabile.
Per contenuti che devono essere freschi ma non sono sensibili, la stessa guida indica Cache-Control: no-cache oppure max-age=0: il browser rivalida prima di servire dalla cache HTTP, e questi due non tolgono l’idoneità alla bfcache. Attenzione al restore: la pagina torna dalla memoria, non dalla cache HTTP. no-cache e max-age=0 non scattano e non c’è rivalidazione prima del disegno. La guida lo ritiene comunque un’esperienza migliore, perché il restore è immediato e la pagina non resta a lungo in bfcache.
| Cache HTTP | bfcache (web.dev, agg. 2 luglio 2026) | |
|---|---|---|
| Cosa tiene | Risposte di richieste già fatte. | Snapshot della pagina, heap JavaScript incluso. |
no-store sulla pagina | Non conserva la risposta. | Storicamente esclude anche la bfcache. Cambio in corso su Chrome. |
no-cache / max-age=0 | Rivalida prima di riusare. | Non tolgono l’idoneità. Al restore non c’è rivalidazione. |
| Indietro / avanti | Può evitare qualche richiesta, quasi mai tutte. | Può ridisegnare lo snapshot senza ricaricare. |
Unload, pageshow, SPA
web.dev, stessa rilettura: il modo più importante per ottimizzare la bfcache in tutti i browser è non usare mai l’evento unload. Su desktop, Chrome e Firefox rendono non idonea una pagina che aggiunge un listener unload. Safari tenta di mettere in cache alcune pagine che hanno quel listener, ma per limitare i guasti non esegue unload quando l’utente esce: l’evento diventa inaffidabile. Su mobile, Chrome e Safari tentano la cache anche con unload, perché su mobile quell’evento è da sempre inaffidabile. Firefox tratta le pagine con unload come non idonee, tranne su iOS, dove — dice la pagina — tutti i browser usano WebKit.
pageshow scatta dopo load al primo caricamento e ogni volta che la pagina è ripristinata. event.persisted === true significa restore da bfcache. pagehide scatta sia allo scaricamento sia quando il browser prova a mettere la pagina in bfcache: persisted === false vuol dire che non sta per entrarci; true vuol dire che il browser intende mettercela, non che ci riuscirà. freeze e resume esistono solo nei browser Chromium.
La bfcache segue le navigazioni gestite dal browser. Non copre le «soft navigation» dentro una single-page app. Può comunque servire quando si torna a una SPA, invece di reinizializzarla da zero. Un iframe non ha una bfcache propria: se la pagina principale viene ripristinata, gli iframe tornano com’erano all’ingresso in cache. Un iframe che usa API bloccanti può tenere fuori anche il frame principale.
Errori da evitare
Leggere un hit di cache HTTP come prova che l’Indietro ha usato la bfcache.
Mettere
no-storesu ogni documento «per essere freschi»: per la freschezza non sensibile la guida indicano-cacheomax-age=0.Aspettarsi una rivalidazione al restore: non avviene.
Agganciare
unload«tanto su mobile non conta»: su desktop Chrome e Firefox quella pagina esce dalla bfcache.Misurare l’INP e credere di avere misurato il tasto Indietro.
In sintesi
bfcache è memoria di pagina, non la cache HTTP e non l’INP. no-store sulla pagina, oggi, la restringe; unload la chiude su desktop in Chrome e Firefox. Il restore non rivalida. Si rilegge web.dev/articles/bfcache: l’aggiornamento in calce è del 2 luglio 2026. Verifica del 12 ottobre 2026.
