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.
![Calendrier d'abandon de unload.](https://developer.chrome.com/static/docs/web-platform/deprecating-unload/image/unload-deprecation-timeline.png?authuser=6&hl=fr)
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".
Nous savons que, en tant que développeurs Web, nous supprimons l'événement unload
comme obsolète. Nous devons nous assurer que notre paradigme correspond au monde réel et ne pas dépendre de concepts obsolètes qui ne sont plus valables, le cas échéant.
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'étathidden
comme 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énementpagehide
n'est pas déclenché lorsque la page est simplement réduite ou que l'utilisateur passe à un autre onglet. Notez que, commepagehide
ne 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. Cet événement n'est pas non plus fiable, 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.
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 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
:
![Outil de test du cache amélioré des outils pour les développeurs Chrome montrant qu'un gestionnaire de déchargement a été utilisé](https://developer.chrome.com/static/docs/web-platform/deprecating-unload/image/chrome-devtools-forward-8640f1ef515a1.png?authuser=6&hl=fr)
API Reporting
Vous pouvez utiliser l'API Reporting en association avec 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 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:
{
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 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
unload
pour 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
En plus de la règle d'entreprise, vous pouvez désactiver l'abandon pour des utilisateurs spécifiques via les indicateurs Chrome et les 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