Pourquoi beforeunload vs pagehide décide si vos analytics survivent

Pourquoi beforeunload vs pagehide compte pour l'envoi des analytics ?

Bien choisir entre beforeunload vs pagehide décide si un événement analytics atteint réellement le serveur avant qu'un utilisateur ne quitte la page. MDN documente que beforeunload ne se déclenche pas de façon fiable, surtout sur mobile : un utilisateur qui bascule vers une autre app puis ferme plus tard le navigateur depuis le gestionnaire d'apps ne déclenche jamais l'événement. Utilisez pagehide ou visibilitychange pour envoyer les données plutôt que beforeunload, et réservez beforeunload pour la seule tâche qu'il assure encore, avertir un utilisateur de modifications non enregistrées. Se tromper sur ce point est l'une des raisons les plus discrètes pour lesquelles une configuration de suivi des utilisateurs réels sous-compte les sorties.

Que fait vraiment l'événement beforeunload ?

L'événement beforeunload se déclenche juste avant qu'une page se décharge et peut afficher une boîte de dialogue de confirmation native du navigateur pour avertir un utilisateur de modifications non enregistrées. MDN recommande lui-même de n'ajouter l'écouteur que lorsqu'il y a des modifications non enregistrées à protéger, puis de le retirer une fois ces modifications sauvegardées, plutôt que de le laisser attaché pendant toute la durée de vie de la page. Ce cas d'usage restreint est aussi le seul pour lequel il reste adapté, car sa fiabilité en tant que signal de sortie général n'existe pas.

Pourquoi beforeunload est-il peu fiable sur mobile ?

Beforeunload est peu fiable sur mobile parce qu'un navigateur fermé depuis le gestionnaire de tâches, ou une application mise en arrière-plan et jamais rouverte, saute complètement l'événement, ce que MDN signale directement avec le scénario changement d'app puis fermeture. Un onglet de bureau fermé via les commandes de fenêtre déclenche l'événement ; la même séquence sur un téléphone, mettre l'app en arrière-plan puis la fermer depuis le gestionnaire d'apps, saute complètement l'événement. Tout appel analytics qui dépend uniquement du déclenchement de beforeunload perd des données exactement sur la plateforme où les sessions se terminent de cette façon.

Comment beforeunload affecte-t-il le back-forward cache ?

L'effet de beforeunload sur le back-forward cache diffère selon le navigateur : Firefox ne place pas une page dans le bfcache si un écouteur beforeunload y est attaché, tandis que le guide bfcache de web.dev note que beforeunload n'exclut plus une page du bfcache dans les autres navigateurs modernes, même si c'était le cas auparavant. Web.dev qualifie toujours l'événement de "peu fiable, donc évitez de l'utiliser sauf nécessité absolue", et recommande d'ajouter l'écouteur de façon conditionnelle, uniquement tant que des modifications non enregistrées existent, plutôt qu'à chaque chargement de page. Une page qui saute le bfcache se recharge entièrement lors d'une navigation arrière au lieu d'être restaurée instantanément depuis la mémoire.

Que fait différemment l'événement pagehide ?

L'événement pagehide se déclenche lorsque le navigateur masque la page actuelle tout en présentant une autre page de l'historique de session, comme un clic sur le bouton retour, et contrairement à beforeunload et unload, un écouteur pagehide ne rend pas une page inadmissible au bfcache. MDN recommande visibilitychange en premier comme signal le plus fiable, avec pagehide en repli pour les navigateurs où visibilitychange n'est pas disponible. Attachez la logique d'envoi à pagehide lorsqu'une page a besoin d'un écouteur sans risque pour le bfcache qui se déclenche quand même aux mêmes moments de navigation que beforeunload était censé capturer, ce qui est aussi le moment où une horloge de délai d'expiration de session continuerait sinon de tourner contre une page que personne ne regarde.

Où sendBeacon s'intègre-t-il aux côtés de pagehide ?

sendBeacon s'intègre aux côtés de pagehide comme mécanisme de livraison, puisqu'il met en file une requête POST asynchrone que le navigateur continue d'essayer d'envoyer même pendant que la page disparaît, sans retarder la navigation que l'utilisateur effectue déjà. MDN recommande de l'associer à l'événement visibilitychange comme déclencheur principal et à pagehide comme repli, plutôt que de le déclencher depuis unload ou beforeunload. Un seul appel sendBeacon est limité à environ 64 Kio ; une charge utile plus grande nécessite plutôt fetch() avec l'option keepalive.

Comment un script analytics doit-il combiner ces événements ?

Un script analytics devrait écouter visibilitychange et vérifier document.visibilityState === "hidden" comme déclencheur d'envoi principal, ajouter pagehide comme repli pour les navigateurs ou situations où visibilitychange ne se déclenche pas, et appeler sendBeacon dans les deux gestionnaires pour envoyer la charge utile sans bloquer la navigation. Le script léger de Flowsery pèse moins de 10 Ko précisément pour que cette logique d'écouteurs ajoute un poids négligeable à une page qui essaie déjà de partir. Sauter directement à beforeunload pour cette tâche est le raccourci qui coûte le plus de données sur mobile, et c'est le même raccourci qui dégonfle discrètement un comptage de taux de rebond vs taux de sortie quand le dernier événement d'une page n'atteint jamais le serveur.

Questions fréquentes

Beforeunload est-il encore utile à quelque chose ?

Beforeunload reste utile pour avertir un utilisateur de modifications non enregistrées via une boîte de dialogue de confirmation native du navigateur. La recommandation de MDN lui-même est d'attacher l'écouteur uniquement tant que des modifications non enregistrées existent et de le retirer une fois qu'elles sont sauvegardées, plutôt que de l'utiliser comme signal général de sortie de page.

Pourquoi pagehide ne bloque-t-il pas le back-forward cache comme le faisait autrefois beforeunload ?

Pagehide ne bloque pas le bfcache parce qu'il a été conçu dans le cadre de la Page Lifecycle API spécifiquement pour signaler une transition de page sans les effets de bord que portent unload et beforeunload. MDN affirme clairement que, contrairement à unload et beforeunload, un écouteur pagehide ne rend pas une page inadmissible au bfcache.

Visibilitychange devrait-il remplacer entièrement pagehide ?

Visibilitychange devrait être le signal principal, avec pagehide conservé en repli, selon la propre recommandation de MDN. Certains navigateurs ou contextes ne déclenchent pas visibilitychange dans tous les scénarios de sortie, donc pagehide rattrape les cas que visibilitychange manque plutôt que de le remplacer entièrement.

Que se passe-t-il si un appel analytics utilise fetch au lieu de sendBeacon à la sortie de la page ?

Un simple appel fetch lancé pendant la sortie de la page peut être annulé avant que le navigateur ait fini de l'envoyer, puisque la page est déjà en train de se décharger. sendBeacon existe précisément pour éviter cela : le navigateur accepte la requête et continue d'essayer de la livrer, que la page ait déjà disparu ou non, jusqu'à sa limite d'environ 64 Kio.

Le back-forward cache affecte-t-il les analytics d'une quelconque manière ?

Le back-forward cache restaure une page depuis la mémoire lors d'une navigation arrière ou avant au lieu de la recharger, ce qui signifie que le JavaScript de la page ne s'exécute pas à nouveau et qu'aucune logique de vue de page dépendant d'un chargement neuf ne se déclenche à nouveau. Un événement pageshow avec event.persisted === true est le signal qu'une restauration a eu lieu, ce que la logique analytics doit vérifier séparément d'un premier chargement.

Pourquoi Firefox traite-t-il beforeunload différemment des autres navigateurs pour le bfcache ?

Firefox exclut une page du bfcache si un écouteur beforeunload y est attaché, une position plus stricte que celle des navigateurs qui ont cessé d'exclure les pages avec beforeunload du bfcache après l'avoir fait auparavant. Le choix le plus sûr entre navigateurs reste d'ajouter un écouteur beforeunload uniquement lorsque des modifications non enregistrées existent, car cela maintient l'écouteur hors de la page pendant les navigations où l'admissibilité au bfcache compte le plus.

Que se passe-t-il si une charge utile d'analytics dépasse la limite de 64 Kio de sendBeacon ?

Un appel sendBeacon, plafonné à environ 64 Kio, rejette purement et simplement une charge plus grande, qui n'atteint donc jamais le serveur. Passer à fetch avec l'option keepalive permet de gérer les charges au-delà de cette limite tout en survivant à une page déjà en train de se décharger.

L'événement unload est-il un repli plus sûr que beforeunload ?

Unload est pire, pas plus sûr. MDN le qualifie d'extrêmement peu fiable sur mobile, et il bloque toujours le back-forward cache sur Chrome et Firefox de bureau, exactement le coût que pagehide cherche à éviter. Mieux vaut le traiter comme du code hérité à éviter plutôt que comme un repli à utiliser.

Ajouter des écouteurs pagehide et visibilitychange alourdit-il une page ?

Flowsery livre son script en dessous de 10 Ko précisément pour que cette logique d'écouteurs ajoute un poids négligeable à une page déjà en train de partir. Le vrai coût se trouve dans la taille de la charge sendBeacon, pas dans les écouteurs eux-mêmes.

Comment l'envoi sur pagehide affecte-t-il le suivi du délai d'expiration de session ?

Pagehide se déclenche au moment précis où une page se cache derrière une autre dans l'historique de session, soit exactement le moment où une horloge de délai d'expiration de session continuerait sinon de tourner contre une page que plus personne ne regarde. Envoyer les données à cet instant clôt la session au bon moment plutôt que d'accumuler du temps inactif contre un onglet déjà quitté.