Cette page a été traduite par l'API Cloud Translation.

Abandon de l'événement "unload"

Demián Renzulli

Barry Pollard

L'événement unload sera progressivement obsolète en modifiant progressivement la valeur par défaut afin que les gestionnaires unload cessent de se déclencher sur les pages, sauf si une page les réactive explicitement.

Calendrier d'abandon

Nous avons indiqué que le comportement de déchargement serait probablement modifié dès janvier 2019, lorsque nous avons annoncé notre intention d'implémenter un cache "Retour/Avance". Parallèlement au travail d'implémentation, nous avons mené une action de sensibilisation de grande envergure, qui a entraîné une baisse significative de l'utilisation du déchargement. Pour compléter cette communication, nous avons également commencé à proposer des moyens de tester l'impact de l'abandon du déchargement à partir de Chrome 115 :

Test réel via l'API Permission-Policy pour le déchargement dans Chrome 115 (juillet 2023)
Tests locaux en activant un indicateur dans Chrome 117 (septembre 2023)

Après ces phases de sensibilisation et d'essai, voici comment nous prévoyons de déployer la suppression progressive :

Phase délimitée dans laquelle le déchargement cessera progressivement de fonctionner pour les 50 sites les plus populaires (référence au moment de la rédaction de ce document).
- À partir de Chrome 120 (fin novembre 2023), 1 % des utilisateurs seront concernés.
- et concernera la totalité des utilisateurs d'ici la fin du troisième trimestre 2024.
De plus, à partir du troisième trimestre 2024, nous prévoyons de lancer une phase générique au cours de laquelle le déchargement cessera progressivement de fonctionner sur tous les sites, en commençant par 1 % des utilisateurs et en terminant par 100 % d'entre eux d'ici la fin du premier trimestre 2025.

Notez que nous proposons également un menu d'options de désactivation au cas où ce calendrier d'abandon progressif ne vous laisserait pas suffisamment de temps pour abandonner le déchargement. Notre objectif est d'utiliser cette abandon progressif pour définir le calendrier de la dernière phase (abandon définitif de la décharge) au cours de laquelle ces désactivations seront supprimées ou réduites.

Contexte

unload a été conçu pour se déclencher lorsque le document est déchargé. En théorie, il peut être utilisé pour exécuter du code chaque fois qu'un utilisateur quitte une page ou comme rappel de fin de session.

Voici les scénarios dans lesquels cet événement était le plus couramment utilisé :

Enregistrer les données utilisateur : enregistrez les données avant de quitter la page.
Effectuer des tâches de nettoyage : fermer les ressources ouvertes avant d'abandonner la page.
Envoyer des données analytiques : envoyer des données liées aux interactions des utilisateurs à la fin de la session.

Toutefois, l'événement unload est extrêmement peu fiable.

Sur les ordinateurs de bureau Chrome et Firefox, unload est raisonnablement fiable, mais cela a un impact négatif sur les performances d'un site en empêchant l'utilisation du cache amélioré.

Dans les navigateurs mobiles, unload ne s'exécute souvent pas, car les onglets sont fréquemment mis en arrière-plan, puis fermés. C'est pourquoi les navigateurs choisissent de donner la priorité au bfcache sur mobile par rapport à unload, ce qui les rend encore moins fiables. Safari utilise également ce comportement sur ordinateur.

L'équipe Chrome estime que l'utilisation du modèle mobile consistant à donner la priorité à bfcache sur unload sur ordinateur serait perturbatrice, car elle rendrait bfcache encore moins fiable sur ordinateur, alors qu'il était auparavant raisonnablement fiable dans Chrome (et Firefox). L'objectif de Chrome est plutôt de supprimer complètement l'événement unload. En attendant, il restera fiable sur ordinateur pour les utilisateurs qui ont explicitement désactivé l'abandon.

Pourquoi abandonner l'événement `unload` ?

L'abandon de unload est une étape clé dans la reconnaissance d'un Web bien plus vaste. L'événement unload donne un faux sentiment de contrôle du cycle de vie de l'application, qui est de moins en moins conforme à la façon dont nous naviguons sur le Web dans le monde de l'informatique moderne.

Les systèmes d'exploitation mobiles figent ou déchargent fréquemment des pages Web pour économiser de la mémoire. Les navigateurs pour ordinateurs le font de plus en plus également pour les mêmes raisons. Même sans intervention du système d'exploitation, les utilisateurs eux-mêmes changent fréquemment d'onglet et ferment les anciens onglets sans "quitter des pages de manière formelle".

La suppression de l'événement unload en tant qu'événement obsolète est une reconnaissance du fait que, en tant que développeurs Web, nous devons nous assurer que notre paradigme correspond à celui du monde réel et ne pas dépendre de concepts obsolètes qui ne sont plus valides (s'ils l'ont jamais été).

Alternatives aux événements `unload`

Au lieu de unload, nous vous recommandons d'utiliser :

visibilitychange: pour déterminer quand la visibilité d'une page change. Cet événement se produit lorsque l'utilisateur change d'onglet, réduit la fenêtre du navigateur ou ouvre une nouvelle page. Considérez l'état hidden comme le dernier moment fiable pour enregistrer des données d'application et utilisateur.
pagehide: pour déterminer quand l'utilisateur a quitté la page. Cet événement se produit lorsque l'utilisateur quitte la page, la recharge ou ferme la fenêtre du navigateur. L'événement pagehide n'est pas déclenché lorsque la page est simplement réduite ou que vous passez à un autre onglet. Notez que, comme pagehide ne rend pas une page inéligible au cache des pages précédentes et suivantes, il est possible qu'une page puisse être restaurée après le déclenchement de cet événement. Si vous nettoyez des ressources dans cet événement, elles devront peut-être être restaurées lors de la restauration de la page.

Le cas d'utilisation de l'événement beforeunload est légèrement différent de celui de unload, car il s'agit d'un événement annulable. Il est souvent utilisé pour avertir les utilisateurs de modifications non enregistrées lorsqu'ils quittent une page. Cet événement n'est pas non plus fiable, car il ne se déclenche pas si un onglet en arrière-plan est fermé. Nous vous recommandons de limiter l'utilisation de beforeunload et de l'ajouter uniquement de manière conditionnelle. Utilisez plutôt les événements ci-dessus pour la plupart des remplacements unload.

Pour en savoir plus, consultez ces conseils pour ne jamais utiliser le gestionnaire unload.

Détecter l'utilisation de `unload`

Différents outils vous aident à trouver les apparitions de l'événement unload sur les pages. Cela permet aux sites de savoir s'ils utilisent cet événement (dans leur propre code ou via des bibliothèques) et s'ils peuvent être affectés par l'abandon à venir.

Outils pour les développeurs Chrome

Les outils pour les développeurs Chrome incluent un audit back-forward-cache pour vous aider à identifier les problèmes susceptibles d'empêcher votre page d'être éligible au cache avant/arrière, y compris l'utilisation du gestionnaire unload.

Pour tester le cache avant/arrière, procédez comme suit :

Sur votre page, ouvrez DevTools, puis accédez à Application > Services en arrière-plan > Cache avant/arrière.
Cliquez sur Tester le cache "Retour/Avancer". Chrome vous redirige automatiquement vers chrome://terms/, puis vers votre page. Vous pouvez également cliquer sur les boutons "Précédent" et "Suivant" du navigateur.

Si votre page n'est pas éligible au cache avant/arrière, l'onglet Cache avant/arrière affiche une liste de problèmes. Sous Actionable (Action directe), vous pouvez voir si vous utilisez unload :

Outils pour les développeurs Chrome : outil de test du cache amélioré montrant qu'un gestionnaire de déchargement a été utilisé

API Reporting

L'API Reporting peut être utilisée conjointement avec une stratégie d'autorisation en lecture seule pour détecter l'utilisation de unload par les utilisateurs de votre site Web.

Pour en savoir plus, consultez Utiliser l'API de création de rapports pour rechercher des déchargements.

API `notRestoredReasons` Bfcache

La propriété notRestoredReasons, ajoutée à la classe PerformanceNavigationTiming, indique si l'utilisation du bfcache a été bloquée pour les documents lors de la navigation et pourquoi. Pour connaître la procédure à suivre, cliquez ici. Voici un exemple de l'avertissement de l'objet de réponse d'un écouteur unload existant :

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

Contrôler l'accès à `unload`

Chrome abandonnera progressivement l'événement unload. En attendant, vous pouvez utiliser différents outils pour contrôler ce comportement et vous préparer à l'abandon à venir. N'oubliez pas que vous ne devez pas vous fier à ces techniques à long terme et que vous devez planifier la migration vers les alternatives dès que possible.

Les options suivantes vous permettent d'activer ou de désactiver les gestionnaires unload pour tester le fonctionnement de votre site sans eux afin de vous préparer à l'abandon prochain. Il existe différents types de règles :

Règles d'autorisation: il s'agit d'une API de plate-forme permettant aux propriétaires de sites de contrôler l'accès à des fonctionnalités, au niveau d'un site ou d'une page individuelle, à l'aide d'en-têtes HTTP.
Règles d'entreprise : outils permettant aux administrateurs informatiques de configurer Chrome pour leur organisation ou entreprise. Ils peuvent être configurés via un panneau d'administration, comme la console d'administration Google.
Options Chrome : elles permettent à un développeur individuel de modifier le paramètre d'abandon de unload pour tester l'impact sur différents sites.

Règles relatives aux autorisations

Une règle d'autorisation a été ajoutée à partir de Chrome 115 pour permettre aux sites de désactiver l'utilisation des gestionnaires unload et de bénéficier immédiatement du cache amélioré pour améliorer leurs performances. Consultez ces exemples pour savoir comment configurer cela pour votre site. Cela permet aux sites de se préparer à l'abandon de unload.

Cette fonctionnalité sera étendue dans Chrome 117 pour permettre aux sites d'effectuer l'opération inverse et de continuer à essayer de déclencher des gestionnaires unload, car Chrome modifie la valeur par défaut pour qu'ils ne soient plus déclenchés à l'avenir. Consultez ces exemples pour savoir comment continuer à autoriser le déclenchement des gestionnaires de déchargement pour votre site. Cette activation ne sera pas conservée indéfiniment et doit être utilisée pour laisser le temps aux sites de ne plus utiliser les gestionnaires unload.

Règles d'entreprise

Les entreprises dont les logiciels dépendent de l'événement unload pour fonctionner correctement peuvent utiliser la règle ForcePermissionPolicyUnloadDefaultEnabled pour éviter l'abandon progressif des appareils sous leur contrôle. En activant cette règle, unload continuera d'être activé par défaut pour toutes les origines. Une page peut toujours définir des règles plus strictes si elle le souhaite. Comme la désactivation de la règle d'autorisations, il s'agit d'un outil permettant de limiter les modifications potentiellement dommageables, mais il ne doit pas être utilisé indéfiniment.

Options Chrome et options de ligne de commande

En plus de la règle d'entreprise, vous pouvez désactiver l'abandon pour des utilisateurs individuels à l'aide des indicateurs Chrome et des options de ligne de commande :

Définir chrome://flags/#deprecate-unload sur enabled permet d'appliquer la valeur par défaut d'abandon et d'empêcher le déclenchement des gestionnaires unload. Ils peuvent toujours être ignorés par site via la règle d'autorisations, mais ils continueront de se déclencher par défaut.

Ces paramètres peuvent également être contrôlés par des options de ligne de commande.

Comparaison des options

Le tableau suivant récapitule les différentes utilisations des options abordées précédemment :

	Faire avancer l'abandon	Déplacer l'abandon (avec des exceptions)	Empêcher l'abandon pour gagner du temps pour une migration
Règles relatives aux autorisations (s'applique aux pages/sites)	Oui	Oui	Oui
Règle d'entreprise (s'applique aux appareils)	Non	Non	Oui
Indicateurs Chrome (s'applique aux utilisateurs individuels)	Oui	Non	Non
Options de ligne de commande Chrome (s'applique aux utilisateurs individuels)	Oui	Non	Oui

Conclusion

Les gestionnaires unload seront bientôt obsolètes. Ils ne sont plus fiables depuis longtemps et leur déclenchement n'est pas garanti chaque fois qu'un document est détruit. De plus, les gestionnaires unload ne sont pas compatibles avec bfcache.

Les sites qui utilisent actuellement des gestionnaires unload doivent se préparer à cet abandon à venir en testant tous les gestionnaires unload existants, en les supprimant ou en les migrant ou, en dernier recours, en retardant l'abandon si nécessaire.

Remerciements

Merci à Kenji Baheux, Fergal Daly, Adriana Jara et Jeremy Wagner pour leur aide à la révision de cet article.

Image principale par Anja Bauermann sur Unsplash