L'evento unload verrà ritirato gradualmente modificando gradualmente il valore predefinito in modo che i gestori unload non vengano più attivati sulle pagine, a meno che una pagina non ne attivi esplicitamente la riattivazione.
Tempistiche di ritiro
Abbiamo notato che il comportamento di unload sarebbe probabilmente soggetto a modifiche già a gennaio 2019, quando abbiamo annunciato il nostro intenzione di implementare una cache back-forward. Parallelamente al lavoro di implementazione, abbiamo condotto un'ampia sensibilizzazione che ha portato a un calo significativo dell'utilizzo dell'unload. Per integrare questa comunicazione, abbiamo anche iniziato a offrire dei metodi per testare l'effetto del ritiro dell'unload da Chrome 115:
- Test in natura tramite l'APIPermission-Policy per unload in Chrome 115 (luglio 2023)
- Test locali attivando un flag in Chrome 117 (settembre 2023)
In seguito a queste fasi di contatto e prova, ecco come prevediamo che verrà implementato il ritiro temporaneo:
- Una fase con ambito in cui l'unload cesserà gradualmente di funzionare per i 50 siti più popolari (riferimento al momento della scrittura).
- A partire dall'1% degli utenti di Chrome 120 (fine novembre 2023).
- Finirà 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 l'unload cesserà gradualmente di funzionare su qualsiasi sito, 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 la tempistica di ritiro temporanea non offra tempo sufficiente per la migrazione dall'unload. Il nostro obiettivo è utilizzare questo ritiro temporaneo per stabilire le tempistiche dell'ultima fase (ritiro definitivo dell'unload) in cui queste disattivazioni verranno rimosse o ridotte.
Contesto
unload è stato progettato per attivarsi durante 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 alla fine della sessione.
Gli scenari in cui questo evento è stato utilizzato più di frequente 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 e analisi: invio di dati relativi alle interazioni degli utenti alla fine della sessione.
Tuttavia, l'evento unload è estremamente inaffidabile.
Su Chrome e Firefox per i computer desktop, unload è ragionevolmente affidabile, ma influisce negativamente sulle prestazioni di un sito, impedendo l'utilizzo di bfcache (cache back/forward).
Sui browser mobile unload spesso non viene eseguito perché le schede vengono spesso eseguite in background e poi terminate. Per questo motivo i browser scelgono di dare la priorità alla cache back-forward sui dispositivi mobili rispetto a unload, il che li rende ancora più inaffidabili. Safari utilizza questo comportamento anche su computer.
Il team di Chrome ritiene che l'utilizzo del modello mobile che consente di dare priorità alla cache back-forward rispetto a unload sui computer sarebbe un problema, rendendolo più inaffidabile anche in questo caso, quando in precedenza era ragionevolmente affidabile in Chrome (e Firefox). Lo scopo di Chrome è però 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 fondamentale per un riconoscimento molto più grande del web in cui viviamo ora. L'evento unload trasmette un falso senso di controllo sul ciclo di vita dell'app, che è sempre più falso sul modo in cui navighiamo sul web nel mondo informatico moderno.
I sistemi operativi mobile spesso bloccano o scaricano le pagine web per risparmiare memoria e ora anche i browser desktop lo fanno sempre più spesso per gli stessi motivi. Anche senza interventi del sistema operativo, gli utenti stessi passano spesso le schede Tab e disattivano le vecchie schede senza formalmente "abbandonare le pagine".
Rimuovere l'evento unload come "obselete" è un riconoscimento del fatto che noi sviluppatori web dobbiamo assicurarci che il nostro paradigma corrisponda a quello del mondo reale e non dipendere da concetti obsoleti che non sono più validi, se lo hanno fatto.
Alternative agli eventi unload
È consigliabile utilizzare invece di unload:
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 attendibile per salvare i dati dell'app e degli utenti.pagehide: per determinare quando l'utente esce dalla 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 ridotta a icona o viene passata a un'altra scheda. Tieni presente che, poichépagehidenon rende una pagina non idonea per la cache back-forward, è possibile che venga ripristinata dopo l'attivazione di questo evento. Se stai eseguendo la pulizia di una risorsa in questo evento, potrebbe essere necessario ripristinarla al momento del ripristino della pagina.
L'evento beforeunload ha un caso d'uso leggermente diverso da unload, in quanto si tratta di un evento annullabile. Viene spesso utilizzato per avvisare gli utenti delle modifiche non salvate quando escono. Inoltre, questo evento non è realistico, in quanto non si attiva se una scheda di sfondo viene interrotta. Ti consigliamo di limitare l'utilizzo di beforeunload e aggiungerlo solo in modo condizionale. Utilizza invece gli eventi precedenti per la maggior parte delle sostituzioni di unload.
Per maggiori dettagli, leggi 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.
Faro
Lighthouse dispone di un controllo no-unload-listeners che avvisa gli sviluppatori se qualsiasi codice JavaScript nelle loro pagine (incluso quello delle librerie di terze parti) aggiunge un listener di eventi unload.
Chrome DevTools
Chrome DevTools include un controllo di back-foward-cache per aiutarti a identificare i problemi che potrebbero impedire alla tua pagina di essere memorizzata nella cache back-forward, incluso l'utilizzo del gestore unload.
Per testare la cache back-forward:
Nella pagina, apri DevTools, quindi vai ad Applicazione > Servizi in background > Cache back-forward.
Fai clic su Verifica cache back-forward. Chrome ti riporta automaticamente a
chrome://terms/e 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, la scheda Cache back/forward mostra un elenco di problemi. In Strategico, puoi vedere se stai utilizzando 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 l'articolo sull'utilizzo dell'API di reporting per trovare gli unload.
API Bfcache notRestoredReasons
La proprietà notRestoredReasons, aggiunta alla classe PerformanceNavigationTiming, segnala le informazioni che indicano se nei documenti è stato bloccato l'utilizzo della bfcache durante la navigazione e perché. Le istruzioni per l'uso sono disponibili qui. Ecco un esempio di avviso dell'oggetto risposta di un listener unload esistente:
{
blocked: true,
children: [],
id: "",
name: "",
reasons: [ "Internal Error", "Unload handler" ],
src: "",
url: "a.com"
}
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 devi 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 i gestori unload per testare come funzionerebbe il tuo sito senza di essi e prepararti al ritiro imminente. Esistono diversi tipi di norme:
- Norme relative alle autorizzazioni: si tratta di un'API delle piattaforme che consente ai proprietari di siti di controllare l'accesso alle funzionalità, a livello di sito o di 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 configurate tramite un pannello di amministrazione, come la Console di amministrazione Google.
- Flag di Chrome: consente a un singolo sviluppatore di modificare l'impostazione relativa al ritiro di
unloadper testare l'impatto su vari siti.
Norme relative alle autorizzazioni
In Chrome 115 è stato aggiunto un criterio di autorizzazione per consentire ai siti di disattivare l'uso dei gestori unload e trarre vantaggio immediatamente dalla cache back-forward per migliorare le prestazioni del sito. Consulta questi esempi di istruzioni per eseguire l'impostazione per il tuo sito. In questo modo i siti possono anticipare il ritiro di unload.
Questa funzionalità verrà estesa in Chrome 117 per consentire ai siti di fare il contrario e di attivare l'opzione per continuare a provare ad attivare i gestori unload, poiché Chrome cambia l'impostazione predefinita in modo che non si attivino 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 deve essere utilizzata per consentire ai siti di uscire dai gestori unload.
Norme aziendali
Le aziende che dispongono di un software che dipende dall'evento unload per funzionare correttamente possono utilizzare il criterio ForcePermissionPolicyUnloadDefaultEnabled per evitare il ritiro graduale dei dispositivi sotto il loro controllo. Se attivi questo criterio, unload continuerà a essere abilitato per impostazione predefinita per tutte le origini. Una pagina può comunque impostare norme più restrittive, se vuole. Analogamente alla disattivazione delle norme relative alle autorizzazioni, questo strumento è utile per limitare le potenziali modifiche che provocano errori, ma non deve essere utilizzato a tempo indeterminato.
Flag e opzioni della riga di comando di Chrome
Oltre ai criteri aziendali, puoi disattivare la deprecazione per i singoli utenti tramite i flag di Chrome e le swtiche delle righe di comando:
Se imposti chrome://flags/#deprecate-unload su enabled, verranno avanti i valori predefiniti relativi al ritiro e impedirai l'attivazione dei gestori unload. Sarà comunque possibile eseguirne l'override sito per sito tramite le norme sulle autorizzazioni, ma continueranno a essere attivati per impostazione predefinita.
Queste impostazioni possono essere controllate anche da opzioni della riga di comando.
Confronto opzioni
La seguente tabella riassume i diversi utilizzi delle opzioni discusse in precedenza:
| Prosegui il ritiro | Proseguire con il ritiro (con eccezioni) | Impedisci il ritiro per garantire il tempo necessario per una migrazione | |
|---|---|---|---|
| Norme relative alle autorizzazioni (si applica a pagine/siti) |
Sì | Sì | Sì |
| Criterio aziendale (si applica ai dispositivi) |
No | No | Sì |
| Flag di Chrome (si applicano ai singoli utenti) |
Sì | No | No |
| Opzioni della riga di comando di Chrome (si applica ai singoli utenti) |
Sì | No | Sì |
Conclusione
I gestori unload sono in fase di ritiro. Sono stati inaffidabili 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 gestori unload devono prepararsi a questo imminente ritiro testando gli eventuali gestori unload esistenti, rimuovendoli o migrandoli o, come ultima alternativa, ritardando il ritiro se occorre più tempo.
Ringraziamenti
Grazie a Kenji Baheux, Fergal Daly, Adriana Jara e Jeremy Wagner per il supporto per la revisione di questo articolo.
Immagine hero di Anja Bauermann su Unsplash