Pubblicato il 10 agosto 2023, ultimo aggiornamento: 28 aprile 2026
L'evento unload verrà gradualmente ritirato modificando gradualmente il comportamento predefinito in modo che i gestori unload smettano di attivarsi sulle pagine, a meno che una pagina non decida esplicitamente di riattivarli.
Tempistiche del ritiro
Abbiamo notato che il comportamento di unload sarebbe stato probabilmente soggetto a modifiche già a partire da gennaio 2019, quando abbiamo annunciato la nostra intenzione di implementare una cache back-forward. Parallelamente al lavoro di implementazione, abbiamo condotto un'ampia attività di sensibilizzazione che ha portato a un calo significativo dell'utilizzo di unload. Per integrare questa attività di sensibilizzazione, abbiamo anche iniziato a offrire modi per testare l'effetto del ritiro di unload da Chrome 115:
- Test in produzione utilizzando l'API Permission-Policy per unload in Chrome 115 (luglio 2023)
- Test locali attivando un flag in Chrome 117 (settembre 2023)
Nel corso del 2024 abbiamo risolto diversi problemi che impedivano l'inizio dell'implementazione e nel corso del 2025 abbiamo implementato il ritiro nei primi 50 siti.
| Traguardo | Data del traguardo | Primi 50 siti | % di altre origini |
|---|---|---|---|
| 135 | 26 marzo 2025 | 1 (www.google.com) |
0 |
| 139 | 30 luglio 2025 | 5 | 0 |
| 140 | 27 agosto 2025 | 10 | 0 |
| 141 | 24 settembre 2025 | 25 | 0 |
| 142 | 22 ottobre 2025 | 50 | 0 |
Ora che abbiamo completato il ritiro per i primi 50 siti, abbiamo ottenuto un'ulteriore approvazione per implementarlo in tutte le origini, in 8 traguardi (circa 32 settimane), come descritto nella tabella seguente.
| Traguardo | Data del traguardo | Primi 50 siti | % di caricamenti di pagine di Chrome per tutti i siti |
|---|---|---|---|
| 146 | 10 marzo 2026 | 50 | 1 |
| 147 | 7 aprile 2026 | 50 | 5 |
| 148 | 5 maggio 2026 | 50 | 10 |
| 149 | 2 giugno 2026 | 50 | 20 |
| 150 | 30 giugno 2026 | 50 | 40 |
| 151 | 28 luglio 2026 | 50 | 60 |
| 152 | 25 agosto 2026 | 50 | 80 |
| 153 | 22 settembre 2026 | 50 | 100 |
L'implementazione completa si basa sui caricamenti di pagine (con coerenza nel tempo), anziché su singoli utenti o siti, per evitare di influire su utenti o siti più di altri, come descritto in Intent to Deprecate.
Tieni presente che offriamo anche un menu di opzioni di disattivazione nel caso in cui queste tempistiche di ritiro non forniscano tempo sufficiente per la migrazione da unload. Il nostro obiettivo è utilizzare questo ritiro graduale per informare le tempistiche dell'ultima fase (ritiro definitivo di unload), in cui queste opzioni di disattivazione verranno rimosse o ridotte.
Sfondo
unload è stato progettato per attivarsi quando il documento viene scaricato. In teoria, può essere utilizzato per eseguire codice ogni volta che un utente esce da una pagina o come callback di fine sessione.
Gli scenari in cui questo evento era di uso comune includono:
- Salvataggio dei dati utente: salva i dati prima di uscire dalla pagina.
- Esecuzione di attività di pulizia: chiusura delle risorse aperte prima di abbandonare la pagina.
- Invio di dati di analisi: invio di dati relativi alle interazioni degli utenti alla fine della sessione.
Tuttavia, l'evento unload è estremamente inaffidabile.
Su Chrome e Firefox per computer, unload è ragionevolmente affidabile, ma ha un impatto negativo sulle prestazioni di un sito impedendo l'utilizzo della cache back-forward.
Nei browser per dispositivi mobili, unload spesso non viene eseguito perché le schede vengono spesso messe in background e poi chiuse. Per questo motivo, i browser scelgono di dare la priorità alla cache back-forward sui dispositivi mobili rispetto a unload, rendendoli ancora più inaffidabili. Safari utilizza questo comportamento anche sui computer.
Il team di Chrome ritiene che l'utilizzo del modello mobile di assegnazione della priorità alla cache back-forward rispetto a unload sui computer sarebbe dirompente rendendolo ancora più inaffidabile, mentre in precedenza era ragionevolmente affidabile in Chrome (e Firefox). L'obiettivo di Chrome è invece rimuovere completamente l'evento unload. Fino ad allora, rimarrà affidabile sui computer per gli utenti che hanno disattivato esplicitamente il ritiro.
Perché ritirare l'evento unload?
Il ritiro di unload è un passo fondamentale verso un riconoscimento molto più ampio del web in cui viviamo oggi. L'evento unload dà una falsa sensazione di controllo del ciclo di vita dell'app, che è sempre meno vera nel mondo dell'informatica moderna.
I sistemi operativi mobile spesso bloccano o scaricano le pagine web per risparmiare memoria e anche i browser desktop lo fanno sempre più spesso per gli stessi motivi. Anche senza interventi del sistema operativo, gli utenti stessi cambiano spesso scheda e chiudono le schede precedenti senza "uscire formalmente dalle pagine".
La rimozione dell'evento unload come obsoleto riconosce che noi sviluppatori web dobbiamo assicurarci che il nostro paradigma corrisponda a quello del mondo reale e non dipenda da concetti obsoleti che non sono più validi, se mai lo sono stati.
Alternative agli eventi unload
Anziché unload, ti consigliamo di utilizzare:
visibilitychange: per determinare quando cambia la visibilità di una pagina. Questo evento si verifica quando l'utente cambia scheda, riduce a icona la finestra del browser o apre una nuova pagina. Considera lo statohiddenl'ultimo momento affidabile per salvare i dati dell'app e dell'utente.pagehide: per determinare quando l'utente ha lasciato la pagina. Questo evento si verifica quando l'utente esce dalla pagina, ricarica la pagina o chiude la finestra del browser. L'eventopagehidenon viene attivato quando la pagina viene ridotta a icona o quando si passa a un'altra scheda. Tieni presente che, poichépagehidenon rende una pagina non idonea per la cache back-forward, è possibile che una pagina venga ripristinata dopo l'attivazione di questo evento. Se pulisci le risorse in questo evento, potrebbe essere necessario ripristinarle al ripristino della pagina.
L'evento beforeunload ha un caso d'uso leggermente diverso da unload in quanto è un evento annullabile. Viene spesso utilizzato per avvisare gli utenti delle modifiche non salvate quando escono. Anche questo evento non è affidabile perché non viene attivato se una scheda in background viene chiusa. Ti consigliamo di limitare l'utilizzo di beforeunload e di aggiungerlo solo in modo condizionale. Utilizza invece gli eventi menzionati in precedenza per la maggior parte delle sostituzioni di unload.
Per maggiori dettagli, consulta questi consigli su come non utilizzare mai il gestore unload.
Rilevare l'utilizzo di unload
Esistono diversi strumenti che ti aiutano a trovare le occorrenze dell'evento unload nelle pagine. In questo modo, i siti possono scoprire se utilizzano questo evento, nel proprio codice o utilizzando librerie, e quindi potrebbero essere interessati dal ritiro imminente.
Chrome DevTools
Chrome DevTools include un back-forward-cache audit per aiutarti a identificare i problemi che potrebbero impedire alla tua pagina di essere idonea per la cache back-forward, incluso l'utilizzo del gestore unload.
Per testare la cache back-forward:
Nella pagina, apri DevTools, quindi vai a Applicazione > Servizi in background > Cache back-forward.
Fai clic su Testa la cache back-forward . Chrome ti porta automaticamente a
chrome://terms/e torna alla tua pagina. In alternativa, puoi fare clic sui pulsanti Indietro e Avanti del browser.
Se la tua pagina non è idonea per la memorizzazione nella cache back-forward, la scheda Cache back-forward mostra un elenco di problemi. In Azione puoi vedere se utilizzi unload:
API di reporting
L'API di reporting può essere utilizzata in combinazione con un criterio di autorizzazione di sola lettura per rilevare l'utilizzo di unload da parte degli utenti del tuo sito web.
Per maggiori dettagli, consulta Utilizzare l'API di reporting per trovare gli scaricamenti
API notRestoredReasons della cache back-forward
La proprietà notRestoredReasons—aggiunta alla classe PerformanceNavigationTiming—segnala se i documenti sono stati bloccati dall'utilizzo della bfcache durante la navigazione e perché. Ecco un esempio di come appare l'oggetto di risposta che avvisa di un listener unload esistente:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-listener"}
],
src: null,
url: "https://www.example.com/page/"
}
Controllare l'accesso a unload
Chrome ritirerà gradualmente l'evento unload. Nel frattempo, puoi utilizzare diversi strumenti per controllare questo comportamento e prepararti per il ritiro imminente. Tieni presente che non devi fare affidamento su queste tecniche a lungo termine e devi pianificare la migrazione alle alternative il prima possibile.
Le seguenti opzioni ti consentono di attivare o disattivare i gestori unload per testare il funzionamento del tuo sito senza di essi, in modo da prepararti per il ritiro imminente. Esistono diversi tipi di criteri:
- Criteri relativi alle autorizzazioni: si tratta di un'API della piattaforma che consente ai proprietari dei siti di controllare l'accesso alle funzionalità, a livello di sito o di singola pagina, utilizzando le intestazioni HTTP.
- Criteri aziendali: strumenti per gli amministratori IT per configurare Chrome per la loro organizzazione o attività. Possono essere configurati utilizzando un pannello di amministrazione, come la Console di amministrazione Google.
- Flag di Chrome: consentono a un singolo sviluppatore di modificare l'impostazione di ritiro di
unloadper testare l'impatto su vari siti.
Criteri relativi alle autorizzazioni
A partire da Chrome 115 è stato aggiunto un criterio relativo alle autorizzazioni per consentire ai siti di disattivare l'utilizzo dei gestori unload e di usufruire immediatamente della cache back-forward per migliorare le prestazioni del sito. Consulta questi esempi su come impostare questa opzione per il tuo sito. In questo modo, i siti possono anticipare il ritiro di unload.
Questo è stato esteso in Chrome 117 per consentire ai siti di fare il contrario e di continuare a provare ad attivare i gestori unload come fanno ora, man mano che Chrome modifica il comportamento predefinito in modo che non vengano attivati in futuro. Consulta questi esempi su come continuare a consentire l'attivazione dei gestori unload per il tuo sito. Sebbene invitiamo i proprietari dei siti a non utilizzare i gestori unload a causa della loro inaffidabilità, prevediamo di supportare questa opzione di disattivazione per un futuro considerevole per i siti che devono utilizzarla. Inoltre, la riattivazione non rende i gestori unload più affidabili sui dispositivi mobili, ma ripristina solo lo stato attuale.
Criteri aziendali
Le aziende che dispongono di software che dipende dall'evento unload per funzionare correttamente possono utilizzare il criterio ForcePermissionPolicyUnloadDefaultEnabled policy per impedire il ritiro graduale per i dispositivi sotto il loro controllo. Se attivi questo criterio, unload continuerà a essere attivato per impostazione predefinita per tutte le origini. Una pagina può comunque impostare un criterio più restrittivo, se lo desidera. Come l'opzione di disattivazione dei criteri relativi alle autorizzazioni, questo è uno strumento per mitigare potenziali modifiche che causano interruzioni. Anche in questo caso, invitiamo i proprietari dei siti a non utilizzare più i gestori unload, ma Chrome prevede di supportare questa opzione di disattivazione aziendale per un futuro considerevole per i siti che devono utilizzarla.
Flag di Chrome e opzioni della riga di comando
Oltre ai criteri aziendali, puoi disattivare il ritiro per i singoli utenti utilizzando i flag di Chrome e le opzioni della riga di comando:
Se imposti chrome://flags/#deprecate-unload su enabled, il comportamento predefinito di ritiro verrà portato avanti e i gestori unload non verranno attivati. Possono comunque essere sostituite sito per sito utilizzando i criteri relativi alle autorizzazioni, ma continueranno a essere attivate per impostazione predefinita.
Queste impostazioni possono essere controllate anche tramite le opzioni della riga di comando.
Confronto tra le opzioni
La seguente tabella riassume i diversi utilizzi delle opzioni discusse in precedenza:
| Anticipare il ritiro | Anticipare il ritiro (con eccezioni) | Impedire il ritiro per avere tempo per la migrazione | |
|---|---|---|---|
| Criteri relativi alle autorizzazioni (si applicano a pagine/siti) |
Sì | Sì | Sì |
| Criteri aziendali (si applicano ai dispositivi) |
No | No | Sì |
| Flag di Chrome (si applicano ai singoli utenti) |
Sì | No | No |
| Opzioni della riga di comando di Chrome (si applicano ai singoli utenti) |
Sì | No | Sì |
Conclusione
I gestori unload sono in fase di ritiro. Sono inaffidabili da molto tempo e non è garantito che vengano attivati in tutti i casi in cui un documento viene eliminato. Inoltre, i gest0ri unload non sono compatibili con la bfcache.
I siti che utilizzano i gestori unload devono prepararsi per questo ritiro imminente testando eventuali gestori unload esistenti, rimuovendoli o eseguendo la migrazione oppure, come ultima risorsa, ritardando il ritiro se è necessario più tempo.
Ringraziamenti
Grazie a Kenji Baheux, Fergal Daly, Adriana Jara e Jeremy Wagner per aver contribuito alla revisione di questo articolo.
Immagine promozionale di Anja Bauermann su Unsplash