Abandon de l'événement "unload"

Demián Renzulli

Barry Pollard

Publié le 10 août 2023, dernière mise à jour le 29 juin 2026

L'événement unload sera progressivement abandonné 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 choisit explicitement de les réactiver.

Calendrier d'abandon

Nous avions 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 Back/Forward. Parallèlement au travail d'implémentation, nous avons mené une vaste campagne de sensibilisation qui a entraîné une baisse significative de l'utilisation de l'événement "unload". En complément de cette communication, nous avons également commencé à proposer des moyens de tester l'effet de l'abandon de l'événement "unload" à partir de Chrome 115 :

• Tests en conditions réelles à l'aide de l'API Permission-Policy pour le déchargement dans Chrome 115 (juillet 2023)
• Tests locaux en activant un flag dans Chrome 117 (septembre 2023)

Tout au long de l'année 2024, nous avons résolu plusieurs problèmes qui bloquaient le début du déploiement. En 2025, nous avons déployé l'arrêt des fonctionnalités sur les 50 principaux sites :

En 2026, nous avons commencé à déployer cette fonctionnalité pour toutes les origines, en huit étapes (soit environ 32 semaines), comme indiqué dans le tableau suivant.

Le déploiement complet est basé sur les chargements de page (avec une cohérence au fil du temps), plutôt que sur les utilisateurs ou les sites individuels, afin d'éviter d'impacter certains utilisateurs ou sites plus que d'autres, comme indiqué dans l'intention d'abandon.

Notez que nous proposons également un menu d'options de désactivation si ce calendrier de suppression ne vous laisse pas suffisamment de temps pour migrer depuis l'événement "unload".

Arrière-plan

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 quelques scénarios dans lesquels cet événement était le plus souvent 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 de quitter la page.
• Envoi des données analytiques : envoi des données liées aux interactions des utilisateurs à la fin de la session.

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

Sur Chrome et Firefox pour ordinateur, unload est raisonnablement fiable, mais il a un impact négatif sur les performances d'un site en empêchant l'utilisation de bfcache (cache Précédent/Suivant).

Sur 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 plutôt qu'à 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 qui donne la priorité au bfcache sur unload sur ordinateur perturberait l'expérience utilisateur en rendant le bfcache moins fiable sur ordinateur également, 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. D'ici là, il restera fiable sur ordinateur dans Chrome pour ceux qui ont explicitement désactivé l'arrêt.

Pourquoi abandonner l'événement unload ?

La suppression de unload est une étape clé dans la reconnaissance du Web tel qu'il est aujourd'hui. L'événement unload donne une fausse impression de contrôle du cycle de vie de l'application, ce qui est de moins en moins vrai dans la façon dont nous naviguons sur le Web dans le monde informatique moderne.

Les systèmes d'exploitation mobiles se figent ou déchargent fréquemment les pages Web pour économiser de la mémoire. Les navigateurs pour ordinateur de bureau le font également 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 sans "quitter" formellement les pages.

La suppression de l'événement unload, considéré comme obsolète, reconnaît que nous, en tant que développeurs Web, 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 valables, s'ils l'ont jamais été.

Alternatives aux événements unload

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

• visibilitychange : permet de 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 la dernière heure fiable pour enregistrer les données de l'application et les données 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 ne se déclenche pas lorsque la page est réduite ou qu'un autre onglet est sélectionné. Notez que, comme pagehide ne rend pas une page inéligible au cache back/forward, il est possible qu'une page puisse être restaurée après le déclenchement de cet événement. Si vous supprimez des ressources lors de cet événement, il est possible qu'elles doivent être restaurées 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 annulable. Elle est souvent utilisée pour avertir les utilisateurs des modifications non enregistrées lorsqu'ils quittent la 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 ne l'ajouter que de manière conditionnelle. Utilisez plutôt les événements mentionnés précédemment pour la plupart des remplacements unload.

Pour en savoir plus, consultez ces conseils sur l'interdiction d'utiliser le gestionnaire unload.

Détecter l'utilisation de unload

Différents outils peuvent vous aider à trouver les occurrences de l'événement unload sur les pages. Cela permet aux sites de déterminer s'ils utilisent cet événement (dans leur propre code ou à l'aide de bibliothèques) et s'ils peuvent donc être affectés par la prochaine obsolescence.

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 qui peuvent empêcher votre page d'être éligible au cache Précédent/Suivant, y compris l'utilisation du gestionnaire unload.

Pour tester le cache back/forward, procédez comme suit :

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

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

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

API Reporting

L'API Reporting peut être utilisée conjointement avec une règle 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 trouver les déchargements.

API Bfcache notRestoredReasons

La propriété notRestoredReasons, ajoutée à la classe PerformanceNavigationTiming, indique si les documents ont été empêchés d'utiliser le bfcache lors de la navigation, et pourquoi. Voici un exemple d'avertissement concernant l'objet de réponse d'un écouteur unload existant :

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

Contrôler l'accès à unload

Chrome abandonne progressivement l'événement unload. En attendant, vous pouvez utiliser différents outils pour contrôler ce comportement et vous préparer à l'arrêt de cette fonctionnalité. N'oubliez pas que vous ne devez pas vous appuyer sur ces techniques à long terme. Vous devez plutôt prévoir de migrer 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 et vous préparer à leur prochaine obsolescence. Il existe différents types de règles :

• Règle relative aux autorisations : il s'agit d'une API de plate-forme permettant aux propriétaires de sites de contrôler l'accès aux fonctionnalités, au niveau d'un site ou d'une page individuelle, à l'aide d'en-têtes HTTP.
• Règles Enterprise : outils permettant aux administrateurs informatiques de configurer Chrome pour leur organisation ou entreprise. Vous pouvez les configurer à l'aide d'un panneau d'administration, comme la console d'administration Google.
• Flags Chrome : ils permettent à un développeur individuel de modifier le paramètre de suppression de unload pour tester l'impact sur différents sites.

Règles sur les autorisations

Une autorisation a été ajoutée à partir de Chrome 115 pour permettre aux sites de désactiver les gestionnaires unload et de bénéficier immédiatement du bfcache afin d'améliorer les performances du site. Consultez ces exemples pour savoir comment configurer cette option pour votre site. Cela permet aux sites d'anticiper l'abandon de unload.

Cette fonctionnalité a été étendue dans Chrome 117 pour permettre aux sites de faire l'inverse et de choisir de continuer à essayer de déclencher les gestionnaires unload comme ils le font actuellement, car Chrome changera le comportement par défaut pour que ceux-ci ne se déclenchent pas à l'avenir. Consultez ces exemples pour savoir comment continuer à autoriser le déclenchement des gestionnaires d'événement "unload" pour votre site. Bien que nous encouragions les propriétaires de sites à ne plus utiliser les gestionnaires unload en raison de leur manque de fiabilité, nous prévoyons de prendre en charge cette option de désactivation pendant encore longtemps pour les sites qui en ont besoin. Notez que la réactivation ne rend pas les gestionnaires unload plus fiables sur mobile. Elle restaure simplement l'état actuel.

Règle d'entreprise

Les entreprises dont les logiciels dépendent de l'événement unload pour fonctionner correctement peuvent utiliser la règle ForcePermissionPolicyUnloadDefaultEnabled pour empêcher la suppression progressive des appareils qu'elles contrôlent. Si vous activez cette règle, unload restera activé par défaut pour toutes les origines. Une page peut toujours définir une règle plus stricte si elle le souhaite. Comme la désactivation de la règle d'autorisation, il s'agit d'un outil permettant d'atténuer les éventuels changements cassants. Nous encourageons à nouveau les propriétaires de sites à ne plus dépendre des gestionnaires unload, mais Chrome prévoit de prendre en charge cette désactivation pour les entreprises pendant encore longtemps pour les sites qui en ont besoin.

Flags 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 à l'aide des options Chrome et des commutateurs de ligne de commande :

Si vous définissez chrome://flags/#deprecate-unload sur enabled, le comportement par défaut de l'obsolescence sera appliqué et les gestionnaires unload ne se déclencheront pas. Elles peuvent toujours être remplacées site par site à l'aide de la règle d'autorisation, mais 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 :

Conclusion

Les gestionnaires unload seront bientôt obsolètes. Ils ne sont pas fiables depuis longtemps et ne sont pas garantis d'être déclenchés dans tous les cas où un document est détruit. De plus, les gestionnaires unload ne sont pas compatibles avec le bfcache.

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

Remerciements

Merci à Kenji Baheux, Fergal Daly, Adriana Jara et Jeremy Wagner pour leurs précieux commentaires.

Image principale par Anja Bauermann sur Unsplash