Amélioration de la fermeture des pages dans XMLHttpRequest() synchrones

Réduire les navigations retardées

Joe Medley

Il est courant qu'une page ou une application contienne des données analytiques ou d'autres données non envoyées au moment où l'utilisateur la ferme. Pour éviter toute perte de données, certains sites utilisent un appel synchrone à XMLHttpRequest() afin que la page ou l'application reste ouverte jusqu'à ce que ses données soient transmises au serveur. Il existe non seulement de meilleurs moyens d'économiser des données, mais cette technique nuit également à l'expérience utilisateur en retardant la fermeture de la page pendant plusieurs secondes.

Cette pratique doit changer, et les navigateurs répondent. La spécification XMLHttpRequest() est déjà prévu pour abandon et suppression. Chrome 80 franchit la première étape en interdisant les appels synchrones dans plusieurs gestionnaires d'événements, en particulier beforeunload, unload, pagehide et visibilitychange, lorsqu'ils sont déclenchés lors du refus. De plus, WebKit a récemment reçu un commit mettant en œuvre le même changement de comportement.

Dans cet article, je vais décrire brièvement les options pour ceux qui ont besoin de temps pour mettre à jour leurs sites et décrire les alternatives à XMLHttpRequest().

Désactivations temporaires

Chrome ne souhaite pas simplement retirer la prise sur XMLHttpRequest(). C'est pourquoi quelques options de désactivation temporaires sont disponibles. Pour les sites sur Internet, une phase d'évaluation est disponible. Vous allez ainsi ajouter aux en-têtes de page un jeton spécifique à l'origine qui active les appels XMLHttpRequest() synchrones. Cette option prend fin peu de temps avant l'expédition de Chrome 89, parfois en mars 2021. Les clients Enterprise de Chrome peuvent également utiliser l'indicateur de règle AllowSyncXHRInPageDismissal, qui se termine au même moment.

Autres solutions

Quelle que soit la manière dont vous renvoyez les données au serveur, il est préférable d'éviter d'attendre le déchargement de la page pour envoyer toutes les données en même temps. En plus de créer une mauvaise expérience utilisateur, la décharge n'est pas fiable sur les navigateurs modernes et elle risque de perdre des données en cas de problème. Plus précisément, les événements de déchargement ne se déclenchent souvent pas sur les navigateurs mobiles, car il existe de nombreuses façons de fermer un onglet ou un navigateur sur les systèmes d'exploitation mobiles sans déclencher l'événement unload. Avec XMLHttpRequest(), l'utilisation de petites charges utiles était un choix. Maintenant, c'est une exigence. Dans les deux cas, la limite d'importation est de 64 Ko par contexte, conformément à la spécification.

Récupérer le message keepalive

L'API Fetch offre un moyen efficace de gérer les interactions avec les serveurs et une interface cohérente utilisable avec les différentes API de la plate-forme. Parmi ses options figure keepalive, qui garantit qu'une requête se poursuit, que la page qui l'a ouverte reste ouverte ou non:

window.addEventListener('unload', {
  fetch('/siteAnalytics', {
    method: 'POST',
    body: getStatistics(),
    keepalive: true
  });
}

La méthode fetch() offre un meilleur contrôle des données envoyées au serveur. Ce que je ne montre pas dans cet exemple, c'est que fetch() renvoie également une promesse qui se résout avec un objet Response. Comme j'essaie d'éviter le déchargement de la page, j'ai choisi de ne rien faire.

SendBeacon()

SendBeacon() utilise en fait l'API Fetch en arrière-plan. C'est pourquoi la limite de charge utile est identique à 64 Ko et elle garantit également qu'une requête se poursuit après le déchargement d'une page. Son principal avantage est sa simplicité. Il vous permet d'envoyer vos données avec une seule ligne de code:

window.addEventListener('unload', {
  navigator.sendBeacon('/siteAnalytics', getStatistics());
}

Conclusion

Avec la disponibilité accrue de fetch() dans tous les navigateurs, il est possible que XMLHttpRequest() soit supprimé de la plate-forme Web à un moment donné. Les fournisseurs de navigateurs s'accordent à dire qu'il devrait être supprimé, mais cela prendra du temps. Abandonner l'un de ses pires cas d'utilisation est une première étape qui améliorera l'expérience utilisateur pour tous.

Photo par Matthew Hamilton, publiée sur Unsplash