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. Il risultato è una navigazione quasi istantanea tra le pagine per l'utente.
Sebbene non sia richiesto dalle specifiche HTML, i browser in genere considerano Cache-Control: no-store un indicatore per evitare di inserire la pagina nella 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.
Il 2 ottobre abbiamo aumentato questa percentuale al 10% dei caricamenti di pagina e intendiamo incrementarla ulteriormente al 20% a novembre e al 50% all'inizio del prossimo anno, per poi lanciarla completamente poco dopo, con alcune esclusioni discusse di seguito.
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 bf, in alcuni casi le pagine non devono essere inserite nella cache bf. 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 della cache back-forward per le pagine Cache-Control: no-store è stato ridotto a 3 minuti (da 10 minuti utilizzati per le pagine che non utilizzano Cache-Control: no-store) per ridurre ulteriormente il rischio.
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
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 bfcache. Nel tester bfcache di Chrome DevTools verrà visualizzato il messaggio "Le pagine la cui risorsa principale ha Cache-Control: no-store non possono accedere alla cache back-forward".
Puoi utilizzare questa pagina di test bfcache per eseguire test con e senza questo flag.
Che 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
Stiamo apportando questa modifica per migliorare l'esperienza sulle pagine per gli utenti sul web. Abbiamo notato miglioramenti significativi ai Core Web Vitals quando abbiamo lanciato per la prima volta bfcache e ora vogliamo estendere questi miglioramenti ad altri 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 bfcache 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 sugli 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 tramite programmazione al ripristino della bfcache per garantire la parità con i caricamenti completi della pagina, sempre utilizzando l'evento pageshow e controllando la proprietà persisted, ma questa potrebbe non essere sempre la soluzione migliore. Consulta la documentazione del tuo fornitore di annunci su come attivare i ricaricamenti degli 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 in questa pagina aiutino gli sviluppatori a comprendere questo cambiamento e ad apportare le modifiche necessarie per evitare problemi.