Pubblicato: 21 ottobre 2024, ultimo aggiornamento: 9 settembre 2025
Chrome sta apportando una modifica per consentire l'utilizzo della cache indietro/avanti (bfcache) per le pagine che utilizzano Cache-Control: no-store quando è sicuro farlo. Scopri cosa significa per gli sviluppatori.
Sfondo
L'impostazione di Cache-Control: no-store come intestazione HTTP indica che la pagina non deve essere memorizzata nella cache HTTP. Questo tag deve essere utilizzato per le pagine contenenti dati sensibili, ad esempio per le pagine in cui un utente ha eseguito l'accesso, ma la direttiva no-store viene spesso utilizzata nelle pagine senza dati sensibili.
Con la bfcache, anziché eliminare una pagina quando l'utente esce, posticipiamo l'eliminazione e mettiamo in pausa l'esecuzione di JavaScript. Se l'utente torna indietro poco dopo, rendiamo nuovamente visibile la pagina e riprendiamo l'esecuzione di JavaScript. In questo modo, l'utente può navigare quasi istantaneamente tra le pagine.
Sebbene non sia richiesto dalle specifiche HTML, i browser in genere considerano Cache-Control: no-store come un segnale per evitare di inserire la pagina nella bfcache. Questo è il motivo principale per cui la bfcache non viene utilizzata, per circa il 17% delle navigazioni nella cronologia sui dispositivi mobili e il 7% sui computer. Ciò significa che queste pagine non usufruiscono dei ripristini rapidi e devono ricaricarsi completamente, incluse eventuali chiamate di rete, esecuzione di JavaScript e rendering.
Spesso Cache-Control: no-store viene impostato per evitare problemi di memorizzazione nella cache quando il sito cambia, ma questo motivo è meno pertinente quando viene utilizzata la bfcache, poiché l'intera pagina viene ripristinata quasi come se fosse rimasta aperta tutto il tempo.
In che modo Chrome sta modificando questo comportamento
Chrome ha annunciato l'intenzione di modificare questo comportamento, ma sta adottando un approccio cauto a questa modifica. Abbiamo condotto esperimenti a partire da Chrome 116, aumentando gradualmente la percentuale di caricamenti di pagina, che dovrebbe raggiungere il 100% a marzo e aprile 2025.
Dati sensibili
Sebbene la nostra analisi mostri che la maggior parte delle navigazioni indietro o avanti non includono dati sensibili e quindi dovrebbero essere idonee per la cache back-forward, ci sono casi in cui le pagine non devono essere inserite nella cache back-forward. Ad esempio, dopo aver eseguito la disconnessione, non dovrebbe essere possibile recuperare una pagina a cui è stato eseguito l'accesso navigando avanti e indietro.
Per evitare questo problema, Chrome rimuove una pagina dalla bfcache in caso di modifiche ai cookie o ad altri metodi di autorizzazione.
Inoltre, l'utilizzo delle seguenti API per le pagine che utilizzano Cache-Control: no-store continuerà a rendere queste pagine non idonee per la cache back-forward:
Tieni presente che questo non è un elenco completo delle API che impediscono l'utilizzo della bfcache, ma delle API che bloccano la bfcache sulle pagine Cache-Control: no-store anche se non vengono utilizzate al momento dell'uscita dalla pagina.
Anche il timeout della cache back-forward per le pagine Cache-Control: no-store è ridotto a 3 minuti (rispetto ai 10 minuti utilizzati per le pagine che non utilizzano Cache-Control: no-store) per ridurre ulteriormente il rischio.
Disattivazione di Enterprise
Le aziende spesso hanno software difficili da aggiornare e dispositivi condivisi. Il criterio AllowBackForwardCacheForCacheControlNoStorePageEnabled può essere disattivato per continuare a impedire l'utilizzo della cache back-forward per le pagine Cache-Control: no-store.
Test della modifica
Gli sviluppatori possono testare questa modifica con il seguente flag:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
Se si applica una delle eccezioni precedenti, ad esempio la modifica dei cookie, la pagina non potrà utilizzare la cache back-forward e in Chrome DevTools bfcache tester verrà visualizzato il messaggio "Le pagine la cui risorsa principale ha Cache-Control: no-store non possono entrare nella cache back-forward".
Puoi utilizzare questa pagina di test della bfcache per eseguire test con e senza questo flag.
Cosa devono sapere gli sviluppatori
Sebbene gli sviluppatori non debbano apportare modifiche per consentire ai propri utenti di usufruire di questo maggiore utilizzo della bfcache, ci sono alcune cose che potrebbero dover prendere in considerazione. Queste considerazioni sono simili a quelle che altri siti potrebbero aver riscontrato nel lancio iniziale della bfcache a dicembre 2021.
Gli sviluppatori dovrebbero comunque cercare di ridurre l'utilizzo di Cache-Control: no-store?
La bfcache è attivata per Cache-Control: no-store nelle circostanze limitate menzionate in precedenza e solo per Chrome. Altri browser potrebbero comunque bloccare l'utilizzo della bfcache quando viene utilizzato Cache-Control: no-store.
La best practice rimane quella di ridurre al minimo l'utilizzo di Cache-Control: no-store anziché fare affidamento su queste euristiche.
Impatto sulle prestazioni
Il motivo di questa modifica è migliorare l'esperienza sulle pagine per gli utenti del web. Abbiamo notato miglioramenti significativi ai Segnali web essenziali quando abbiamo lanciato bfcache e ora vogliamo estendere questi miglioramenti a un maggior numero di siti.
I proprietari dei siti potrebbero notare un miglioramento dei Segnali web essenziali con l'implementazione di questa funzionalità e possono misurare l'utilizzo della bfcache in CrUX, incluso in CrUX Vis.
Impact Analytics
Le pagine ripristinate dalla bfcache "ripristinano" la vecchia pagina (incluso l'heap JavaScript) anziché ricaricarla. Molti fornitori di analisi popolari non misurano i ripristini della bfcache come nuove visualizzazioni di pagina, in quanto attivano le visualizzazioni di pagina solo al caricamento iniziale.
Pertanto, i siti potrebbero registrare una riduzione dei caricamenti di pagina nelle analisi quando iniziano a utilizzare la bfcache per la prima volta. Ti consigliamo di considerarli come visualizzazioni di pagina impostando i listener per l'evento pageshow e controllando la proprietà persisted:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
Gestire gli aggiornamenti durante il ripristino della pagina
Poiché ora i siti potrebbero visualizzare l'utilizzo della bfcache quando prima non lo vedevano e quando la pagina veniva invece ricaricata completamente con dati aggiornati, gli sviluppatori potrebbero voler prendere in considerazione l'aggiornamento dei dati al ripristino della bfcache.
Gli aggiornamenti possono essere attivati in modo simile alla registrazione di visualizzazioni di pagina aggiuntive per l'analisi utilizzando l'evento pageshow e selezionando la proprietà persisted.
Tieni presente che non tutti i contenuti devono essere aggiornati e gli utenti potrebbero preferire tornare ai contenuti che hanno visto in precedenza. Ad esempio, l'aggiornamento di un elenco di articoli potrebbe comportare la scomparsa di un articolo che l'utente stava per visualizzare di nuovo.
Impatto sugli annunci
Analogamente all'impatto di Analytics, i siti potrebbero registrare una riduzione delle impressioni degli annunci se questi vengono caricati solo al caricamento della pagina. Gli annunci possono essere aggiornati in modo programmatico al ripristino della bfcache per garantire la parità con i caricamenti della pagina completa, utilizzando di nuovo l'evento pageshow e controllando la proprietà persisted, ma potrebbe non essere sempre la cosa giusta da fare. Consulta la documentazione del tuo fornitore di annunci su come attivare i ricaricamenti degli annunci.
Scopri di più sulla cache back-forward
Per ulteriori informazioni sulla cache back-forward, consulta la nostra guida tecnica completa.
Feedback
Siamo ansiosi di ricevere feedback su questa modifica, che può essere fornito nel tracker dei problemi di Chrome utilizzando il componente bfcache.
Conclusione
Siamo felici di estendere i vantaggi della bfcache a molte altre pagine per migliorare l'esperienza utente. Abbiamo valutato attentamente questa modifica e il nostro approccio mira a implementarla nel modo più sicuro possibile. Ci auguriamo che le informazioni fornite qui aiutino gli sviluppatori a comprendere questa modifica e ad apportare le modifiche necessarie per evitare problemi quando si verifica.