Abandon de l'événement "unload"

Demián Renzulli

Barry Pollard

Publié le 10 août 2023. Dernière mise à jour : 28 avril 2026

L'événement unload sera progressivement abandonné en modifiant progressivement le comportement 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 avons noté 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 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 du déchargement. Pour compléter cette campagne, nous avons également commencé à proposer des moyens de tester l'effet de l'abandon du déchargement à 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 indicateur dans Chrome 117 (septembre 2023)

Tout au long de l'année 2024, nous avons résolu plusieurs problèmes qui empêchaient le lancement du déploiement. En 2025, nous avons déployé l'abandon sur les 50 principaux sites.

Maintenant que nous avons terminé l'abandon pour les 50 principaux sites, nous avons obtenu une autorisation supplémentaire pour déployer cette fonctionnalité sur toutes les origines, en huit étapes (environ 32 semaines), comme indiqué dans le tableau suivant.

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

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

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é :

• Enregistrement des données utilisateur : enregistrez les données avant de quitter la page.
• Exécution de tâches de nettoyage : fermez les ressources ouvertes avant d'abandonner la page.
• Envoi d'analyses : envoyez des données liées aux interactions utilisateur à la fin de la session.

Toutefois, 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 du bfcache (cache back/forward).

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. Pour cette raison, 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 pense que l'utilisation du modèle mobile de priorité du bfcache sur unload sur ordinateur serait perturbante car elle le rendrait également moins fiable, 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 pour ceux qui ont explicitement désactivé l'abandon.

Pourquoi abandonner l'événement unload ?

L'abandon de unload est une étape clé d'une reconnaissance beaucoup plus large du Web dans lequel nous vivons actuellement. 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 notre façon de naviguer sur le Web dans le monde informatique moderne.

Les systèmes d'exploitation mobiles figent ou déchargent fréquemment les pages Web pour économiser de la mémoire, et les 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 sans "quitter" officiellement les pages.

La suppression de l'événement unload 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 déjà été.

Alternatives aux événements unload

Au lieu de unload, il est recommandé 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 les données de l'application et de l'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'elle passe à un autre onglet. Notez que, comme pagehide ne rend pas une page inéligible au cache back/forward, il est possible qu'une page soit restaurée après le déclenchement de cet événement. Si vous nettoyez des ressources dans 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. Il est souvent utilisé pour avertir les utilisateurs des modifications non enregistrées lors de la navigation. 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é. Il est recommandé 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 la façon de ne jamais utiliser le gestionnaire unload.

Détecter l'utilisation de unload

Il existe différents outils pour vous aider à trouver les occurrences de l'événement unload sur les pages. Cela permet aux sites de découvrir 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 l'abandon à venir.

Outils pour les développeurs Chrome

Les outils pour les développeurs Chrome incluent un back-forward-cache audit pour vous aider à identifier les problèmes qui peuvent empêcher votre page d'être éligible au cache back/forward, 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/ et revient à 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 back/forward, l'onglet Cache back/forward affiche une liste de problèmes. Sous Actionnable, 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 de l'objet de réponse qui avertit 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 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 appuyer sur ces techniques à long terme et que vous devez 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, afin de vous préparer à l'abandon à venir. Il existe différents types de règles :

• Règles sur les 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 d'entreprise : outils permettant aux administrateurs informatiques de configurer Chrome pour leur organisation ou leur entreprise. Ils peuvent être configurés à l'aide d'un panneau d'administration, comme la console d'administration Google.
• Indicateurs Chrome : cela permet à un développeur individuel de modifier le paramètre d'abandon unload pour tester l'impact sur différents sites.

Règles sur les 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 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 de devancer l'abandon unload.

Cette fonctionnalité a été étendue dans Chrome 117 pour permettre aux sites de faire l'inverse et de continuer à essayer de déclencher des gestionnaires unload comme ils le font actuellement, car Chrome modifie le comportement par défaut pour qu'ils ne se déclenchent plus à l'avenir. Consultez ces exemples pour savoir comment continuer à autoriser le déclenchement des gestionnaires de déchargement pour votre site. Bien que nous encourageons 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 désactivation pendant un avenir considérable pour les sites qui en ont besoin. De plus, la réactivation ne rend pas les gestionnaires unload plus fiables sur mobile. Elle ne fait que rétablir le statu quo 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 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 une règle plus stricte si elle le souhaite. Comme la désactivation des règles d'autorisation, il s'agit d'un outil permettant d'atténuer les changements potentiels. Encore une fois, nous encourageons les propriétaires de sites à ne plus dépendre des gestionnaires unload, mais Chrome prévoit de prendre en charge cette désactivation d'entreprise pendant un avenir considérable pour les sites qui en ont besoin.

Indicateurs Chrome et commutateurs de ligne de commande

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

Définir chrome://flags/#deprecate-unload sur enabled avancera le comportement par défaut d'abandon et empêchera le déclenchement des gestionnaires unload. Ils peuvent toujours être remplacés site par site à l'aide des règles d'autorisation, mais 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 sont peu 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, unload gestionnaires sont incompatibles avec le bfcache.

Les sites qui utilisent des gestionnaires unload doivent se préparer à cet abandon à venir 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 leur aide dans la relecture de cet article.

Image héros par Anja Bauermann sur Unsplash