Il Tuo Script di Analytics Probabilmente Disattiva la Cache Avanti/Indietro
La cache avanti/indietro rende quasi istantanee le navigazioni con il tasto Indietro, ma un solo listener unload la disattiva per l'intera pagina. Gli script di tracciamento sono i colpevoli abituali — e ora CrUX misura il danno.
La navigazione più veloce sul web è quella in cui non si carica assolutamente nulla. La cache avanti/indietro (bfcache) offre esattamente questo — e una singola riga nello script del tuo fornitore di analytics può disattivarla per ogni pagina del tuo sito.
bfcache è un'ottimizzazione del browser che mantiene in memoria uno snapshot completo di una pagina — heap JavaScript incluso — quando l'utente la abbandona. Premi il tasto Indietro e il browser ripristina quello snapshot e riprende l'esecuzione, producendo un caricamento quasi istantaneo senza alcuna richiesta di rete. Le navigazioni avanti e indietro rappresentano una stima del 10–20% di tutte le navigazioni, quindi non si tratta di un caso limite.
Un Solo Listener Squalifica l'Intera Pagina
L'idoneità alla bfcache è fragile per progettazione. Il browser non congela una pagina che ha registrato un event listener unload, perché unload implica che la pagina si aspetta di essere smantellata. Su desktop, Chrome e Firefox rendono qualsiasi pagina con un listener unload non idonea alla bfcache — nessuna eccezione, nessun credito parziale.
Il listener non deve necessariamente essere il tuo. Script di terze parti che registrano unload dall'interno della tua pagina, o persino all'interno di un subframe, squalificano il documento di primo livello. Lighthouse include un audit dedicato no-unload-listeners proprio perché il codice incriminato è così spesso codice che l'autore del sito non ha mai scritto.
beforeunload non è più squalificante nei browser moderni, ma è inaffidabile ed è comunque meglio evitarlo a meno che un utente non abbia modifiche non salvate.
Gli Script di Tracciamento Sono il Colpevole Abituale
L'evento unload è il posto classico in cui lanciare un beacon finale — svuotare una sessione, inviare un evento "pagina chiusa" — quindi gli script di tracciamento comportamentale e pubblicitari vi ricorrono di continuo.
fbevents.js di Facebook registra un handler unload e compare su circa il 9% di tutte le pagine web secondo HTTP Archive. Il tag di PayPal inietta un iframe che aggiunge un evento unload, bloccando la bfcache su molti flussi di checkout. Script in subframe come hCaptcha hanno fatto lo stesso. Nessuno di questi richiede una modifica al tuo codice per iniziare a costarti caro — basta un fornitore che pubblica un aggiornamento.
Ora CrUX Ti Mostra il Conto
Un tempo questo era invisibile nei dati sul campo. Dal dataset di marzo 2024, il Chrome User Experience Report (CrUX) riporta una suddivisione navigation_types — inclusa la frazione di visite servite dalla cache avanti/indietro — così puoi vedere quanti utenti reali si perdono il percorso istantaneo.
La correlazione è netta. L'analisi di CrUX ha rilevato una forte relazione statistica (ρ=0.87) tra un'alta frazione back_forward_cache e instant_lcp_density — la quota di caricamenti con LCP sotto i 200 ms. Dopo che l'aggiornamento di Google di marzo 2026 ha aumentato il peso nel ranking di LCP, INP e CLS, un blocco bfcache autoinflitto è uno svantaggio misurabile al 75° percentile, non un errore di arrotondamento.
Come Rilevarlo e Risolverlo
Apri i DevTools, vai su Application → Back/forward cache e clicca Run Test. Chrome elenca ogni motivo di blocco, inclusi gli handler unload aggiunti da terze parti.
Per rilevare i ripristini da bfcache nel tuo codice, non usare mai unload. Usa pageshow e controlla persisted:
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// restored from bfcache — no fresh page load fired
}
})
Per impedire che terze parti ti squalifichino, imposta un header di risposta che vieta completamente i listener unload:
Permissions-Policy: unload=()
Questo neutralizza gli handler unload di qualsiasi script — tag dei fornitori, estensioni o il tuo stesso codice legacy — così la pagina resta idonea alla bfcache indipendentemente da ciò che viene caricato.
Il Tracker Che Non La Tocca Mai
La soluzione strutturale è usare strumentazione che non ha alcun motivo di ascoltare unload in primo luogo. Un tracker privacy-first registra una pageview con una singola richiesta keepalive e lascia che la richiesta sopravviva alla pagina da sola — nessun beacon di smantellamento, nessun handler unload, niente che il browser debba segnalare:
fetch('/collect', {
method: 'POST',
keepalive: true,
body: JSON.stringify({ site_id, path: location.pathname })
})
Quando un tracker ha bisogno di reagire a una pagina mandata in background, il segnale corretto è visibilitychange o pagehide, entrambi i quali si attivano senza rendere la pagina non idonea alla bfcache. Il tracker di Monoid pesa circa 2 KB, non imposta cookie e si aggancia a history.pushState per i cambi di rotta delle SPA anziché al ciclo di vita della pagina — quindi non ha alcun listener unload da registrare e niente con cui disattivare la tua cache avanti/indietro.
L'analytics di sorveglianza penalizza le performance in modi che non emergono in un test di laboratorio. Un blocco bfcache è uno dei più silenziosi: nessun errore, nessun rendering lento, solo un tasto Indietro che ricarica dalla rete quando avrebbe dovuto ripristinare dalla memoria.
Comments
Loading comments…