Ritiro dell'evento di unload

Demián Renzulli

Barry Pollard

L'evento unload verrà ritirato gradualmente modificando l'impostazione predefinita in modo che i gestori unload interrompano l'attivazione sulle pagine, a meno che una pagina non decida esplicitamente di riattivarli.

Tempistiche del ritiro

Abbiamo notato che il comportamento dell'unload sarebbe probabilmente soggetto a modifiche nel gennaio 2019, quando abbiamo annunciato l'intenzione di implementare una cache back-forward. Parallelamente al lavoro di implementazione, abbiamo condotto un ampio contatto che ha comportato un calo significativo dell'utilizzo dell'unload. A completamento di questo contatto, abbiamo anche iniziato a offrire dei modi per testare l'effetto del ritiro dell'unload da Chrome 115:

• Test d'azione tramite l'API Authorization-Policy per l'unload in Chrome 115 (luglio 2023)
• Test locali tramite l'attivazione di un flag in Chrome 117 (settembre 2023)

Dopo queste fasi di contatto e prova, ecco come prevediamo l'implementazione del ritiro temporaneo:

• Una fase con ambito in cui l'unload smetterà gradualmente di funzionare per i 50 siti più popolari (riferimento al momento della scrittura).
  • A partire dall'1% di utenti di Chrome 120 (fine di novembre 2023).
  • Terminare 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 l'unload cesserà gradualmente di funzionare su tutti i siti, iniziando con l'1% di utenti e terminando con il 100% di 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 periodo di ritiro graduale non offra tempo sufficiente per abbandonare l'unload. Il nostro obiettivo è utilizzare questo ritiro soft per definire le tempistiche relative all'ultima fase (ritiro definitivo dell'unload) in cui queste disattivazioni verranno rimosse o ridotte.

Sfondo

unload è stato progettato per attivarsi quando viene eseguito l'unload del documento. In teoria, può essere utilizzato per eseguire il codice ogni volta che un utente esce da una pagina o come callback di fine sessione.

Gli scenari in cui questo evento è stato più comunemente utilizzato includono:

• Salvataggio dei dati degli utenti: salva i dati prima di uscire dalla pagina.
• Esecuzione di attività di pulizia: chiudi le risorse aperte prima di abbandonare la pagina.
• Invio di dati di analisi: l'invio di dati relativi alle interazioni degli utenti al termine della sessione.

Tuttavia, l'evento unload è estremamente inaffidabile.

Su Chrome e Firefox per computer desktop, unload è ragionevolmente affidabile, ma influisce negativamente sulle prestazioni di un sito perché impedisce l'utilizzo di bfcache (cache back/forward).

Sui browser mobile spesso la lingua unload non viene eseguita perché le schede vengono spesso eliminate in background e poi terminate. Per questo motivo, i browser scelgono di dare la priorità alla cache bfcache sui dispositivi mobili rispetto a unload, il che li rende ancora più inaffidabili. Questo comportamento viene utilizzato anche su computer.

Il team di Chrome ritiene che l'utilizzo del modello mobile di dare la priorità a bfcache rispetto a unload su computer sarebbe invasivo, rendendolo più inaffidabile anche in questo caso, quando in precedenza questa impostazione era ragionevolmente affidabile in Chrome (e Firefox). L'obiettivo di Chrome è invece quello di rimuovere completamente l'evento unload. Fino ad allora, i dati rimarranno affidabili sui computer per gli utenti che hanno esplicitamente disattivato il ritiro.

Perché ritirare l'evento unload?

Il ritiro di unload è un passaggio fondamentale per un riconoscimento molto più ampio del web in cui viviamo ora. L'evento unload dà un falso senso di controllo del ciclo di vita delle app, che è sempre più falso sul modo in cui navighiamo sul web nell'ambiente informatico moderno.

I sistemi operativi mobile spesso si bloccano o scaricano le pagine web per risparmiare memoria e anche i browser desktop fanno sempre di più per gli stessi motivi. Anche senza interventi del sistema operativo, gli utenti stessi spesso cambiano scheda e bloccano le vecchie schede senza "abbandonare le pagine".

La rimozione dell'evento unload come obsoleto è un riconoscimento che noi, in qualità di sviluppatori web, dobbiamo assicurarci che il nostro paradigma corrisponda a quello del mondo reale e non dipendiamo da concetti obsoleti che non sono più validi, se mai lo hanno fatto.

Alternative agli eventi unload

Al posto di unload è consigliabile 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 stato hidden l'ultima data/ora affidabile per salvare i dati dell'app e degli utenti.
• pagehide: per determinare quando l'utente è uscito dalla pagina. Questo evento si verifica quando l'utente esce dalla pagina, ricarica la pagina o chiude la finestra del browser. L'evento pagehide non viene attivato quando la pagina viene semplicemente ridotta a icona o passa a un'altra scheda. Tieni presente che, poiché pagehide non 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 eseguendo la pulizia di risorse in questo evento, potrebbe essere necessario ripristinarle al momento del ripristino della pagina.

L'evento beforeunload ha un caso d'uso leggermente diverso rispetto a unload in quanto è un evento annullabile. Viene spesso utilizzato per avvisare gli utenti in caso di modifiche non salvate quando escono dalla pagina. Questo evento è inoltre inaffidabile, in quanto non si attiva 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 riportati sopra 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 apparizioni dell'evento unload nelle pagine. In questo modo i siti possono scoprire se stanno utilizzando questo evento (nel proprio codice o tramite librerie) e quindi potrebbero essere interessati dall'imminente ritiro.

Chrome DevTools

Chrome DevTools include un controllo back-forward-cache che consente di identificare i problemi che potrebbero impedire l'idoneità della pagina per la cache back-forward, incluso l'utilizzo del gestore unload.

Per testare la cache back-forward, segui questi passaggi:

1. Nella pagina, apri DevTools, quindi vai ad Applicazione > Servizi in background > Cache back/forward.

2. Fai clic su Testa cache back-forward. Chrome ti porta automaticamente a chrome://terms/ e torna alla tua pagina. In alternativa, puoi fare clic sui pulsanti Avanti e Indietro del browser.

Se la tua pagina non è idonea per la memorizzazione nella cache back-forward, nella scheda Cache back/forward viene visualizzato un elenco dei problemi. In Azioni, puoi verificare se stai utilizzando unload:

API di reporting

L'API di reporting può essere utilizzata insieme a 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 unload

API Bfcache notRestoredReasons

La proprietà notRestoredReasons, aggiunta alla classe PerformanceNavigationTiming, segnala se ai documenti è stato bloccato l'utilizzo di bfcache durante la navigazione e perché. Le istruzioni per l'utilizzo sono disponibili qui. Ecco un esempio di come appare l'avviso sull'oggetto di risposta di un listener unload esistente:

{
   children: [],
   id: null,
   name: null,
   reasons: [
     {"reason", "unload-handler"}
   ],
   src: null,
   url: "https://www.example.com/page/"
}

Controlla l'accesso a unload

Chrome ritirerà gradualmente l'evento unload. Nel frattempo, puoi utilizzare diversi strumenti per controllare questo comportamento e prepararti all'imminente ritiro. Tieni presente che non dovresti fare affidamento su queste tecniche a lungo termine e dovresti pianificare la migrazione alle alternative il prima possibile.

Le seguenti opzioni ti consentono di attivare o disattivare i gestori di unload per testare come funzionerebbe il tuo sito senza di loro, in modo da prepararti all'imminente ritiro. Esistono diversi tipi di norme:

• Norme relative 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 singola pagina, tramite l'utilizzo di intestazioni HTTP.
• Criteri aziendali: strumenti che consentono agli amministratori IT di configurare Chrome per la propria 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 di unload per testare l'impatto su vari siti.

Norme sulle autorizzazioni

Un criterio sulle autorizzazioni è stato aggiunto da Chrome 115 per consentire ai siti di disattivare l'utilizzo dei gestori unload e trarre immediatamente vantaggio dalla cache bfcache per migliorare le prestazioni del sito. Consulta questi esempi su come impostare questa preferenza per il tuo sito. In questo modo i siti possono anticipare il ritiro di unload.

La modifica verrà estesa in Chrome 117 per consentire ai siti di eseguire l'operazione invertita e per attivare la possibilità di continuare a provare ad attivare i gestori di unload, in quanto Chrome ne modifica l'impostazione predefinita in modo che non vengano attivati in futuro. Consulta questi esempi su come continuare a consentire l'attivazione dei gestori dell'unload per il tuo sito. Questa attivazione non verrà conservata per sempre e dovrebbe essere utilizzata per consentire ai siti di migrare dai gestori unload.

Criterio aziendale

Le aziende con software che dipende dall'evento unload per funzionare correttamente possono utilizzare il criterio ForcePermissionPolicyUnloadDefaultEnabled per impedire il ritiro graduale dei dispositivi sotto il loro controllo. Se attivi questo criterio, l'app unload continuerà a essere attivata per impostazione predefinita per tutte le origini. Una pagina può comunque impostare norme più rigide, se lo desidera. Come la disattivazione dei criteri relativi alle autorizzazioni, si tratta di uno strumento per mitigare potenziali modifiche che provocano un errore, ma non deve essere utilizzato a tempo indeterminato.

Flag di Chrome e opzioni della riga di comando

Oltre che per il criterio aziendale, puoi disattivare il ritiro per singoli utenti tramite i flag di Chrome e le opzioni della riga di comando:

L'impostazione di chrome://flags/#deprecate-unload su enabled annullerà il ritiro predefinito e impedirà l'attivazione dei gestori unload. È comunque possibile eseguirne l'override sito per sito tramite le norme relative alle autorizzazioni, ma continueranno ad attivarsi per impostazione predefinita.

Queste impostazioni possono essere controllate anche dalle opzioni della riga di comando.

Confronto opzioni

La seguente tabella riassume i diversi utilizzi delle opzioni discusse in precedenza:

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 distrutto. Inoltre, i gestori unload non sono compatibili con bfcache.

I siti che attualmente utilizzano i gestori unload devono prepararsi a questo imminente ritiro testando gli eventuali gestori di unload esistenti rimuovendoli o eseguendone la migrazione oppure, come ultima risorsa, ritardando il ritiro se si ha bisogno di più tempo.

Ringraziamenti

Grazie a Kenji Baheux, Fergal Daly, Adriana Jara e Jeremy Wagner per l'aiuto nella lettura di questo articolo.

Immagine hero di Anja Bauermann su Unsplash