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.
- 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 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, 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 était le plus couramment 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 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 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 avant/arrière).
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 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 passent fréquemment d'un onglet à un autre et ferment les anciens onglets sans "quitter officiellement les pages".
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: 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'étathiddencomme le dernier moment fiable pour enregistrer les données de l'application et de l'utilisateur.pagehide: permet de 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énementpagehiden'est pas déclenché lorsque la page est simplement réduite ou que vous passez à un autre onglet. Notez que, commepagehidene 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 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 au cache avant/arrière, l'onglet Cache avant/arrière affiche une liste de problèmes. Sous Actionable (Actionable), vous pouvez voir si vous utilisez unload:
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. Vous pouvez ainsi vous préparer à l'abandon à venir. Il existe différents types de règles :
- Politique d'autorisation: 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 spécifique, via l'utilisation 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
unloadpour 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 bfcache afin d'améliorer les performances de leur site. Consultez ces exemples pour savoir comment configurer cela 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'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 option ne sera pas disponible indéfiniment et doit permettre aux sites de migrer vers d'autres gestionnaires que 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.
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. 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 commutateurs de ligne de commande.
Comparaison des options
Le tableau suivant récapitule les différentes utilisations des options abordées précédemment :
| Déplacer l'abandon | Déplacer l'abandon (avec des exceptions) | Empêcher l'abandon pour gagner du temps pour une migration | |
|---|---|---|---|
| Règles d'autorisation (s'applique aux pages/sites) |
Oui | Oui | Oui |
| Règle d'entreprise (s'applique aux appareils) |
Non | Non | Oui |
| Flags 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. Elles sont peu fiables depuis longtemps et ne sont pas forcément déclenchées dans tous les cas où 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