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. Ainsi, les gestionnaires unload cesseront de se déclencher sur les pages, sauf si une page active explicitement la réactivation.

Calendrier d'abandon

Nous avons constaté que le comportement de déchargement serait probablement sujet à des modifications dès janvier 2019, lorsque nous avons annoncé notre intention d'implémenter un cache amélioré. 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 prise de contact, nous avons également commencé à proposer des moyens de tester l'effet de l'abandon du déchargement de Chrome 115:

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

Après ces phases de démarchage et d'essai, voici comment devrait se dérouler l'abandon progressif:

• 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 1% des utilisateurs provenant de Chrome 120 (fin novembre 2023).
  • Pour finir avec 100% des utilisateurs d'ici la fin du 3e trimestre 2024
• En outre, à 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 avec 1% des utilisateurs et en terminant avec 100% 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 laisserait pas assez de temps pour arrêter le déchargement. Notre objectif est d'utiliser cet abandon progressif pour déterminer le calendrier de la dernière phase (abandon forcé de la fonctionnalité de déchargement) au cours de laquelle ces fonctionnalités seront supprimées ou réduites.

Contexte

unload a été conçu pour se déclencher lors du déchargement du document. En théorie, elle peut être utilisée pour exécuter du code chaque fois qu'un utilisateur quitte une page, ou pour effectuer un rappel de fin de session.

Voici les scénarios dans lesquels cet événement a été le plus souvent utilisé:

• Enregistrement des données utilisateur: enregistrez les données avant de quitter la page.
• Effectuer des tâches de nettoyage: fermer les ressources ouvertes avant de quitter la page.
• Envoi de données analytiques: envoi de données sur les interactions des utilisateurs à la fin de la session.

Cependant, l'événement unload n'est pas 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 souvent mis en arrière-plan, puis fermés. Pour cette raison, les navigateurs choisissent de donner la priorité au cache amélioré sur les mobiles par rapport à unload, ce qui les rend encore plus peu fiables. Safari exploite également ce comportement sur les ordinateurs de bureau.

L'équipe Chrome estime que l'utilisation du modèle mobile consistant à donner la priorité au cache amélioré sur unload sur ordinateur serait gênante en le rendant plus peu fiable sur ce type d'appareil, alors qu'il s'agissait auparavant d'une fiabilité 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é pour mieux faire connaître le Web dans lequel nous vivons actuellement. L'événement unload donne un faux sentiment de contrôle sur le cycle de vie de l'application, qui est de plus en plus fausse quant à la façon dont nous naviguons sur le Web dans le monde informatique moderne.

Les systèmes d'exploitation mobiles figent ou déchargent fréquemment des pages Web pour économiser de la mémoire. De plus en plus de navigateurs pour ordinateur le font de plus en plus 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".

Retirer l'événement unload comme obsolète signifie que nous, les développeurs Web, devons veiller à ce que notre paradigme corresponde à celui du monde réel et ne pas dépendre de concepts obsolètes qui ne sont plus d'actualité, le cas échéant.

Alternatives aux événements unload

Nous vous recommandons d'utiliser la méthode suivante plutôt que unload:

• 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, l'actualise 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 amélioré, 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, vous devrez peut-être les restaurer lors de la restauration de la page.

L'événement beforeunload a un cas d'utilisation légèrement différent de unload, car il s'agit d'un événement pouvant être annulé. Il est souvent utilisé pour avertir les utilisateurs que des modifications non enregistrées n'ont pas été enregistrées lorsqu'ils quittent le site. Cet événement n'est pas non plus fiable, car il ne se déclenchera pas si un onglet en arrière-plan est fermé. Nous vous recommandons de limiter l'utilisation de beforeunload et de l'ajouter uniquement sous certaines conditions. Utilisez plutôt les événements ci-dessus pour la plupart des remplacements de 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 permettent de trouver des occurrences 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 peuvent donc être concernés par l'abandon à venir.

Outils pour les développeurs Chrome

Les outils pour les développeurs Chrome incluent un audit back-forward-cache qui vous aide à identifier les problèmes qui peuvent empêcher votre page d'être éligible au cache amélioré, y compris l'utilisation du gestionnaire unload.

Pour tester le cache amélioré, procédez comme suit:

1. Sur votre page, ouvrez les outils de développement, puis accédez à Application > Services d'arrière-plan > Cache amélioré.

2. Cliquez sur Tester le cache amélioré. Chrome vous redirige automatiquement vers chrome://terms/, puis sur votre page. Vous pouvez également cliquer sur les boutons "Précédent" et "Suivant" du navigateur.

Si votre page n'est pas éligible à la mise en cache avancée, l'onglet Cache amélioré affiche la liste des problèmes. Sous Actionable (Actionable), vous pouvez voir si vous utilisez unload:

API Reporting

Vous pouvez associer l'API Reporting à des règles 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 Reporting pour rechercher des décharges.

API notRestoredReasons Bfcache

La propriété notRestoredReasons, ajoutée à la classe PerformanceNavigationTiming, indique si les documents ont été bloqués ou non dans l'utilisation du cache amélioré lors de la navigation, et pourquoi. Pour consulter les instructions d'utilisation, cliquez ici. Voici un exemple d'avertissement d'objet de réponse pour 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 compter sur ces techniques à long terme et que vous devez envisager de migrer vers d'autres solutions 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. Vous pouvez ainsi vous préparer à l'abandon à venir. 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 leur entreprise. Ils peuvent être configurés via un panneau d'administration, tel que la console d'administration Google.
• Indicateurs Chrome: 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 sur la manière de définir ce paramètre pour votre site. Cela permet aux sites d'anticiper l'abandon de unload.

Cette fonctionnalité sera étendue dans Chrome 117 pour permettre aux sites d'effectuer l'inverse et de continuer à essayer de déclencher les gestionnaires unload, car Chrome modifie la valeur par défaut pour que ces derniers ne se déclenchent pas à l'avenir. Consultez ces exemples pour savoir comment continuer à autoriser les gestionnaires de déchargement à se déclencher 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. Si vous activez cette règle, unload continuera d'être activée par défaut pour toutes les origines. Si elle le souhaite, une page peut tout de même définir des règles plus strictes. Comme pour la désactivation des règles d'autorisation, cet outil permet de limiter les éventuelles modifications destructives, mais il ne doit pas être utilisé indéfiniment.

Indicateurs Chrome et commutateurs de ligne de commande

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

Définir chrome://flags/#deprecate-unload sur enabled entraîne le transfert de la valeur d'abandon par défaut et empêche le déclenchement des gestionnaires unload. Vous pourrez toujours les remplacer site par site via les règles d'autorisation, mais ils continueront de se déclencher par défaut.

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

Comparaison des options

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

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 dans la révision de cet article.

Image principale par Anja Bauermann sur Unsplash