Chrome sta apportando una modifica per consentire l'utilizzo della cache di navigazione avanti/indietro (bfcache) per le pagine che utilizzano Cache-Control: no-store quando è possibile farlo in sicurezza. 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. Deve essere utilizzata 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 bfcache, invece di distruggere una pagina quando l'utente esce, rimandiamo la distruzione e mettiamo in pausa l'esecuzione di JS. Se l'utente torna indietro poco dopo, rendiamo di nuovo visibile la pagina e riattiviamo l'esecuzione di JS. Ciò consente all'utente di navigare tra le pagine quasi istantaneamente.
Sebbene non sia richiesto dalla specifica HTML, i browser in genere prendono Cache-Control: no-store come segnale per evitare di posizionare la pagina nella cache bfcache. Questo è il motivo principale per cui la cache bf non viene utilizzata, per circa il 17% delle navigazioni nella cronologia su dispositivi mobili e il 7% delle navigazioni nella cronologia su computer. Ciò significa che queste pagine non usufruiscono dei ripristini rapidi e devono ricaricare completamente la pagina, incluse eventuali chiamate di rete, esecuzione di JavaScript e visualizzazione.
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é la pagina completa viene ripristinata quasi come se fosse stata lasciata aperta per 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 prudente a questa modifica. Eseguiamo esperimenti fin dalla versione 116 di Chrome e fino a poco tempo fa venivano eseguiti sul 5% dei caricamenti di pagine.
Abbiamo aumentato la percentuale al 10% dei caricamenti di pagine il 2 ottobre e intendiamo aumentarla ulteriormente fino al 20% dei caricamenti di pagine a novembre, al 50% all'inizio del prossimo anno, per poi lanciare questa funzionalità completamente subito dopo e in seguito discutere di alcune disattivazioni.
Dati sensibili
Sebbene la nostra analisi indichi che la maggior parte delle navigazioni avanti o indietro non include dati sensibili e quindi dovrebbe essere idonea per la cache back-forward, in alcuni casi le pagine non devono essere inserite nella cache back-forward. Ad esempio, quando esci, non dovrebbe essere possibile recuperare una pagina di accesso navigando avanti o indietro.
Per evitare ciò, 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 bfcache:
Tieni presente che questo non è un elenco completo delle API che impediscono l'utilizzo di bfcache, ma delle API che bloccano bfcache nelle pagine Cache-Control: no-store anche se non sono in uso al momento dell'uscita dalla pagina.
Anche il timeout di bfcache per le pagine Cache-Control: no-store si riduce a 3 minuti (dai 10 minuti utilizzati per le pagine che non utilizzano Cache-Control: no-store) per ridurre ulteriormente i rischi.
Disattivazioni di Enterprise
Le aziende spesso hanno software e dispositivi condivisi difficili da aggiornare. 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 in corso...
Gli sviluppatori possono testare questa modifica con il seguente flag:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
Se si applica una qualsiasi delle precedenti eccezioni, ad esempio la modifica dei cookie, la pagina non potrà utilizzare bfcache con il motivo "Le pagine la cui risorsa principale ha Cache-Control: no-store non possono essere memorizzate nella cache back-forward.", visibile nel tester bfcache di Chrome DevTools.
Puoi utilizzare questa pagina di test 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 cache bf, potrebbero dover prendere in considerazione alcuni aspetti. Si tratta di considerazioni simili a quelle che altri siti potrebbero aver riscontrato durante il lancio iniziale di bfcache a dicembre 2021.
Impatto sul rendimento
Questa modifica è stata introdotta per migliorare l'esperienza sulle pagine per gli utenti del web. Abbiamo notato notevoli miglioramenti a Core Web Vitals quando abbiamo lanciato per la prima volta bfcache e ora vogliamo applicare gli stessi miglioramenti a un maggior numero di siti.
I proprietari di siti potrebbero notare un miglioramento dei Core Web Vitals durante l'implementazione e possono misurare l'utilizzo di bfcache in CrUX, inclusa la dashboard di CrUX.
Dati e analisi sull'impatto
Le pagine ripristinate dalla cache bfcache "ripristinano" la vecchia pagina (inclusa l'heap JavaScript) anziché ricaricarla. Molti fornitori di analisi di uso comune non misurano i ripristini della cache bf come nuove visualizzazioni di pagina, poiché attivano le visualizzazioni di pagina solo al caricamento iniziale.
Di conseguenza, i siti potrebbero registrare una riduzione dei caricamenti di pagine nei dati e analisi quando iniziano a utilizzare la cache bf per la prima volta. Ti consigliamo di considerarli come visualizzazioni di pagina impostando gli ascoltatori 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 al ripristino della pagina
Poiché ora i siti potrebbero rilevare l'utilizzo di bfcache quando prima non lo vedevano e la pagina verrebbe invece ricaricata completamente con dati aggiornati, gli sviluppatori potrebbero prendere in considerazione l'aggiornamento dei dati durante il ripristino di bfcache.
Gli aggiornamenti possono essere attivati in modo simile al logging di ulteriori visualizzazioni di pagina per l'analisi utilizzando l'evento pageshow e controllando 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 che l'utente non veda più un articolo che stava tornando a visualizzare.
Impatto sugli annunci
Analogamente all'impatto sull'analisi, i siti potrebbero registrare una riduzione delle impressioni degli annunci se gli annunci si caricano solo al caricamento della pagina. Gli annunci possono essere aggiornati in modo programmatico al ripristino di bfcache per garantire la parità con il caricamento della pagina completa, utilizzando nuovamente l'evento pageshow e controllando la proprietà persisted, ma potrebbe non essere sempre la cosa giusta da fare. Per informazioni su come attivare i ricaricamenti degli annunci, consulta la documentazione del tuo fornitore di annunci.
Ulteriori informazioni sulla cache bfcache
Per ulteriori informazioni sulla cache bfcache, consulta la nostra guida tecnica completa sulla cache bfcache.
Feedback
Siamo ansiosi di ricevere feedback su questa modifica, che possono essere forniti nel tracker dei problemi di Chrome utilizzando il componente bfcache.
Conclusione
Siamo entusiasti di offrire i vantaggi di 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 questo cambiamento e ad apportare le modifiche necessarie per evitare problemi.