L'evento unload verrà gradualmente ritirato modificando gradualmente il valore predefinito in modo che i gestori unload smettano di essere attivati nelle pagine, a meno che una pagina non li riattivi esplicitamente.
Tempistiche del ritiro
Abbiamo notato che il comportamento di svuotamento della cache potrebbe essere 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 campagna di sensibilizzazione che ha comportato un calo significativo dell'utilizzo dello scarico. A complemento di questa iniziativa, abbiamo anche iniziato a offrire modi per testare l'effetto del ritiro di unload da Chrome 115:
- Test in produzione tramite l'API Permissions-Policy per lo scollegamento in Chrome 115 (luglio 2023)
- Test locali attivando un flag in Chrome 117 (settembre 2023)
Dopo queste fasi di informazione e prova, prevediamo di implementare il ritiro graduale nel seguente modo:
- Una fase basata sugli ambiti in cui lo scollegamento cesserà gradualmente di funzionare per i 50 siti più popolari (riferimento al momento della stesura di questo articolo).
- A partire dall'1% degli utenti di Chrome 120 (fine novembre 2023).
- Termine con il 100% degli utenti entro la fine del terzo trimestre del 2024
- Inoltre, a partire dal terzo trimestre del 2024, intendiamo avviare una fase generica in cui lo scollegamento cesserà gradualmente di funzionare su tutti i siti, iniziando con l'1% degli utenti e terminando con il 100% degli utenti entro la fine del primo trimestre del 2025.
Tieni presente che offriamo anche un menu di opzioni di disattivazione nel caso in cui questo programma di ritiro graduale non offra tempo sufficiente per eseguire la migrazione dall'estrazione. Il nostro obiettivo è utilizzare questo ritiro graduale per comunicare le tempistiche dell'ultima fase (ritiro forzato del caricamento) in cui questi opt-out verranno rimossi o ridotti.
Sfondo
unload è stato progettato per essere attivato durante lo scollegamento del documento. 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 è stato utilizzato più di frequente includono:
- Salvare i 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 di bfcache (cache back/forward).
Nei browser mobile, 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 bfcache sui dispositivi mobili rispetto a unload, rendendoli ancora meno affidabili. Safari utilizza questo comportamento anche su computer.
Il team di Chrome ritiene che l'utilizzo del modello mobile che dà la priorità a bfcache rispetto a unload su computer causerebbe interruzioni rendendolo meno affidabile anche lì, 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 su computer per chi ha disattivato esplicitamente il ritiro.
Perché ritirare l'evento unload?
Il ritiro di unload è un passaggio chiave per un riconoscimento molto più ampio del web che oggi utilizziamo. L'evento unload dà un falso senso di controllo sul ciclo di vita dell'app, che non corrisponde sempre più a come navighiamo sul web 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 di più per gli stessi motivi. Anche senza interventi del sistema operativo, gli utenti stessi passano spesso da una scheda all'altra e chiudono le schede precedenti senza "uscire dalle pagine" formalmente.
La rimozione dell'evento unload come obsoleto è un riconoscimento del fatto che noi, in qualità di sviluppatori web, dobbiamo assicurarci che il nostro paradigma corrisponda a quello del mondo reale e non fare affidamento su concetti obsoleti che non sono più validi, se mai lo sono stati.
Alternative agli eventi unload
Invece di 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 statohiddencome l'ultimo momento affidabile per salvare i dati dell'app e dell'utente.pagehide: per determinare quando l'utente ha abbandonato la pagina. Questo evento si verifica quando l'utente esce dalla pagina, la ricarica o chiude la finestra del browser. L'eventopagehidenon viene attivato quando la pagina viene semplicemente minimizzata 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 possa essere ripristinata dopo l'attivazione di questo evento. Se stai ripulendo le risorse in questo evento, potrebbero dover essere ripristinate al momento del 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 da una pagina. Questo evento non è affidabile perché non viene attivato se una scheda in background viene interrotta. Ti consigliamo di limitare l'utilizzo di beforeunload e di aggiungerlo solo in modo condizionale. Utilizza invece gli eventi sopra indicati per la maggior parte delle sostituzioni di unload.
Per maggiori dettagli, consulta questo consiglio su come non utilizzare mai il gestore unload.
Rileva l'utilizzo di unload
Esistono diversi strumenti per aiutarti a trovare le occorrenze dell'evento unload nelle pagine. In questo modo, i siti possono scoprire se utilizzano questo evento, nel proprio codice o tramite librerie, e quindi potrebbero essere interessati dal ritiro imminente.
Chrome DevTools
Chrome DevTools include un audit back-forward-cache per aiutarti a identificare i problemi che potrebbero impedire la memorizzazione della pagina nella cache back-forward, incluso l'utilizzo dell'handler unload.
Per testare la cache back-forward:
Nella pagina, apri DevTools, quindi vai a Applicazione > Servizi in background > Cache avanti/indietro.
Fai clic su Testa la cache back-forward. Chrome ti reindirizzerà automaticamente a
chrome://terms/e poi di nuovo 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, nella scheda Memorizzazione nella cache back-forward viene visualizzato un elenco di problemi. Nella sezione 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 Reporting per trovare gli scarichi
API Bfcache notRestoredReasons
La proprietà notRestoredReasons, aggiunta alla classe PerformanceNavigationTiming, riporta informazioni su se l'utilizzo della bfcache è stato bloccato per i documenti durante la navigazione e il motivo. Le istruzioni per l'utilizzo sono disponibili qui. Ecco un esempio di avviso dell'oggetto di risposta di un ascoltatore unload esistente:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-handler"}
],
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 al ritiro imminente. Tieni presente che non dovresti fare affidamento su queste tecniche a lungo termine e che dovresti pianificare la migrazione alle alternative il prima possibile.
Le seguenti opzioni ti consentono di attivare o disattivare gli handler unload per testare il funzionamento del tuo sito senza di essi, in modo da prepararti al ritiro imminente. Esistono diversi tipi di norme:
- Norme relative alle autorizzazioni: si tratta di un'API di piattaforma che consente ai proprietari di siti di controllare l'accesso alle funzionalità a livello di sito o di singola pagina tramite l'utilizzo delle intestazioni HTTP.
- Criteri di Enterprise: strumenti per gli amministratori IT per configurare Chrome per la loro organizzazione o attività. Possono essere configurati tramite un pannello di amministrazione, come la Console di amministrazione Google.
- Flag di Chrome: consente a un singolo sviluppatore di modificare l'impostazione di ritiro
unloadper testare l'impatto su vari siti.
Norme relative alle autorizzazioni
A partire da Chrome 115 è stato aggiunto un criterio di autorizzazione per consentire ai siti di disattivare l'utilizzo degli handle unload e di usufruire immediatamente della bfcache per migliorare le prestazioni del sito. Consulta questi esempi su come impostare questa funzionalità per il tuo sito. In questo modo, i siti possono prepararsi in anticipo al ritiro di unload.
Questa funzionalità verrà estesa in Chrome 117 per consentire ai siti di fare il contrario e di attivare la continuazione del tentativo di attivare gli handler unload, poiché Chrome modificherà l'impostazione predefinita in modo che questi non vengano attivati in futuro. Consulta questi esempi su come continuare a consentire l'attivazione degli handler di svuotamento per il tuo sito. Questa attivazione non rimarrà attiva per sempre e deve essere utilizzata per consentire ai siti di eseguire la migrazione dagli handle unload.
Norme aziendali
Le aziende che dispongono di software che dipende dall'evento unload per funzionare correttamente possono utilizzare il criterio ForcePermissionPolicyUnloadDefaultEnabled per impedire il ritiro graduale per i dispositivi sotto il loro controllo. Se attivi questo criterio, unload continuerà a essere attivo per impostazione predefinita per tutte le origini. Una pagina può comunque impostare criteri più stringenti, se lo desidera. Come la disattivazione dei criteri relativi alle autorizzazioni, si tratta di uno strumento per mitigare potenziali modifiche che causano interruzioni, ma non deve essere utilizzato a tempo indeterminato.
Flag di Chrome e parametri a riga di comando
Oltre che tramite i criteri aziendali, puoi disattivare il ritiro per i singoli utenti tramite i flag di Chrome e gli switch della riga di comando:
Se imposti chrome://flags/#deprecate-unload su enabled, verrà applicata l'impostazione predefinita di ritiro e verrà impedito l'avvio degli handler unload. Possono comunque essere sostituiti su base sito tramite i criteri di autorizzazione, ma continueranno a essere attivati per impostazione predefinita.
Queste impostazioni possono essere controllate anche tramite gli switch a riga di comando.
Confronto delle opzioni
La seguente tabella riassume i diversi utilizzi delle opzioni discusse in precedenza:
| Anticipare il ritiro | Anticipare il ritiro (con eccezioni) | Evitare il ritiro per garantire il tempo necessario per una migrazione | |
|---|---|---|---|
| Norme relative 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. Non sono affidabili da molto tempo e non è garantito che vengano attivati in tutti i casi in cui un documento viene eliminato. Inoltre, i gestori unload non sono compatibili con la cache back-forward.
I siti che attualmente utilizzano gestori unload devono prepararsi a questo ritiro imminente verificando la presenza di eventuali gestori unload esistenti, rimuovendoli o eseguendo la migrazione o, 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 a rivedere questo articolo.
Immagine hero di Anja Bauermann su Unsplash