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 celles-ci les réactivent explicitement.
Calendrier d'abandon
Nous avons remarqué que le comportement de déchargement serait susceptible d'être modifié 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 vaste campagne de sensibilisation, 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'effet de l'abandon du déchargement depuis Chrome 115:
- Lors des tests sauvages via l'API Permission-Policy pour le déchargement dans Chrome 115 (juillet 2023)
- Tests en local avec l'activation d'un indicateur dans Chrome 117 (septembre 2023)
À la suite de ces phases de prospection et d'essai, voici comment nous prévoyons le déploiement de l'abandon progressif:
- Phase limitée au cours de laquelle le déchargement cessera progressivement de fonctionner pour les 50 principaux sites populaires (référence au moment de la rédaction de ce document).
- À partir de 1% des utilisateurs à partir de Chrome 120 (fin novembre 2023).
- Terminer avec 100% des utilisateurs d'ici la fin du 3e trimestre 2024
- De plus, à partir du 3e trimestre 2024, nous prévoyons d'entamer une phase générique pendant 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'ici la fin du 1er trimestre 2025.
Notez que nous proposons également un menu d'options de désactivation au cas où le calendrier d'abandon progressif ne laisserait pas assez de temps pour abandonner le déchargement. Notre objectif est d'utiliser cet abandon progressif pour indiquer le calendrier de la dernière phase (abandon forcé du déchargement) au cours de laquelle ces options de désactivation 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, 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 des cas de figure où cet événement a été le plus couramment utilisé:
- Enregistrement des données utilisateur: enregistrez les données avant de quitter la page.
- Effectuer des tâches de nettoyage: fermez les ressources ouvertes avant d'abandonner 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 est extrêmement peu fiable.
Sur les ordinateurs Chrome et Firefox, unload est relativement 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 s'exécutent souvent en arrière-plan, puis se ferment. C'est pourquoi les navigateurs choisissent de privilégier le cache amélioré sur mobile par rapport à unload, ce qui le rend encore plus fiable. Safari utilise également ce comportement sur les ordinateurs.
L'équipe Chrome pense que l'utilisation du modèle mobile consistant à privilégier le cache amélioré par rapport à unload sur ordinateur serait perturbateur en le rendant plus fiable à cet endroit, alors que cela était raisonnablement fiable dans Chrome (et Firefox auparavant). L'objectif de Chrome est plutôt de supprimer complètement l'événement unload. En attendant, elle restera disponible sur ordinateur pour les utilisateurs qui ont explicitement refusé l'abandon.
Pourquoi arrêter l'événement unload ?
L'abandon de unload est une étape clé dans la reconnaissance du Web dans lequel nous vivons actuellement. L'événement unload donne une fausse impression de contrôle sur le cycle de vie de l'application, qui devient de plus en plus inexacte quant à la façon dont nous parcourons le Web dans le monde informatique moderne.
Les systèmes d'exploitation mobiles gèlent ou déchargent fréquemment les pages Web afin d'économiser de la mémoire. De plus, 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 onglets sans "quitter les pages".
Supprimer l'événement unload comme obslété est une reconnaissance qu'en tant que développeurs Web, nous devons nous assurer que notre paradigme correspond au monde réel et de ne pas dépendre de concepts obsolètes qui ne se vérifient plus, voire plus.
Alternatives aux événements unload
Nous vous recommandons d'utiliser le code suivant à la place de unload:
visibilitychange: pour déterminer à quel moment 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: pour déterminer à quel moment 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énementpagehiden'est pas déclenché lorsque la page est simplement réduite ou que l'utilisateur passe à un autre onglet. Notez que, commepagehidene rend pas une page inéligible au cache amélioré, il est possible qu'elle soit 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 peut être annulé. Elle est souvent utilisée pour avertir les utilisateurs des modifications non enregistrées lorsqu'ils quittent la page. De plus, cet événement est irréalisable, car il ne se déclenche pas si un onglet d'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
Il existe différents outils pour vous aider à 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 sont donc susceptibles d'être affectés par l'abandon à venir.
Phare
Lighthouse inclut un audit no-unload-listeners qui avertit les développeurs si du code JavaScript sur leurs pages (y compris celui provenant de bibliothèques tierces) ajoute un écouteur d'événements unload.
Outils pour les développeurs Chrome
Les outils pour les développeurs Chrome incluent un audit back-foward-cache pour vous aider à 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:
Sur la page, ouvrez les outils de développement, puis accédez à Application > Services d'arrière-plan > Cache amélioré.
Cliquez sur Tester le cache amélioré 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 à la mise en cache amélioré, l'onglet Cache amélioré affiche la liste des problèmes. Sous Actionable, 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 usUtiliser l'API Reporting pour rechercher les décharges.
API Bfcache notRestoredReasons
La propriété notRestoredReasons, ajoutée à la classe PerformanceNavigationTiming, indique si les documents n'ont pas pu utiliser le cache amélioré lors de la navigation, et pourquoi. Consultez les instructions d'utilisation ici. Voici un exemple de l'avertissement d'objet de réponse d'un écouteur unload existant:
{
blocked: true,
children: [],
id: "",
name: "",
reasons: [ "Internal Error", "Unload handler" ],
src: "",
url: "a.com"
}
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 utiliser ces techniques à long terme et que vous devriez plutôt envisager de passer à d'autres techniques dès que possible.
Les options suivantes vous permettent d'activer ou de désactiver les gestionnaires unload afin de 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 relatives aux autorisations: cette API de plate-forme permet aux propriétaires de sites de contrôler l'accès aux fonctionnalités, au niveau d'un site ou d'une page individuelle, via l'utilisation 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, comme la console d'administration Google.
- Indicateurs Chrome: cela permet à 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 depuis 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 les performances des sites. Consultez ces exemples de configuration pour votre site. Cela permet aux sites d'anticiper l'abandon de unload.
Cette fonctionnalité sera étendue dans Chrome 117 afin de permettre aux sites d'effectuer l'inverse et d'accepter de continuer à essayer de déclencher des gestionnaires unload, car Chrome modifie la valeur 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. Cette option ne sera pas conservée éternellement et doit être utilisée pour laisser le temps aux sites d'abandonner 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é par défaut pour toutes les origines. Une page peut tout de même définir une règle plus stricte si elle le souhaite. Comme pour la désactivation des règles relatives aux autorisations, cet outil vise à limiter les éventuelles modifications destructives, mais il ne doit pas être utilisé indéfiniment.
Indicateurs Chrome et commutateurs de ligne de commande
Outre la règle d'entreprise, vous pouvez désactiver l'abandon pour des utilisateurs spécifiques à l'aide des indicateurs Chrome et des boutons de ligne de commande:
Si vous définissez chrome://flags/#deprecate-unload sur enabled, la valeur par défaut d'abandon sera appliquée et les gestionnaires unload ne pourront pas se déclencher. Elles peuvent toujours être remplacées site par site via les règles relatives aux autorisations, mais elles 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:
| Abandonner | Abandon (avec exceptions) | Empêcher l'abandon pour garantir la date de la migration | |
|---|---|---|---|
| Règles relatives aux autorisations (s'applique aux pages et aux 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 |
| Commutateurs 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 dans tous les cas où un document est détruit. De plus, les gestionnaires unload ne sont pas compatibles avec le cache amélioré.
Les sites qui utilisent actuellement des gestionnaires unload doivent se préparer à cet abandon imminent 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 la révision de cet article.
Image principale d'Anja Bauermann sur Unsplash