Résumé

  • Le premier projet public Beacon du W3C, publié en octobre 2013, décrivait les ruses de mesure qui ralentissaient le départ d’une page : requête synchrone, chargement d’image et boucle vide.
  • Le projet de recommandation candidate d’août 2022 présente navigator.sendBeacon() comme le dépôt d’un petit message à sens unique, dont le navigateur organise l’envoi sans retenir le lecteur.

La scène se passe à la fermeture. Vous avez déjà franchi la moitié du seuil. Un employé sort un formulaire et demande d’attendre une seconde : il doit signaler à son bureau que vous êtes parti. Pour constater le départ, il empêche le départ. Les bureaux aiment parfois ce genre de logique circulaire; les lecteurs, moins.

Le premier projet de travail public Beacon du W3C, daté du 29 octobre 2013, nommait cette difficulté. Un script d’analyse voulait envoyer ses dernières données lorsque le document se déchargeait. Une requête asynchrone pouvait être abandonnée quand la page disparaissait. Certains développeurs utilisaient alors une requête XMLHttpRequest synchrone, faisaient charger une image, ou lançaient une boucle qui ne servait qu’à gagner du temps. Pour la personne qui venait de cliquer ailleurs, la navigation semblait ralentir.

Le premier texte proposait de laisser à l’agent utilisateur la responsabilité de transmettre le message. Sa méthode s’appelait alors beacon, avec une forme différente de celle qu’aura plus tard navigator.sendBeacon(). Voilà pourquoi il faut lire les documents dans l’ordre : en 2013, la question brûlante était la sortie prise en otage par un relevé minuscule; les détails ultérieurs de l’interface appartiennent au travail suivant.

Le relevé avait pourtant une raison d’exister. Une session peut produire un dernier événement, une mesure ou un diagnostic au moment où l’on ferme l’onglet. Tout envoyer immédiatement sollicite le réseau et la batterie. Tout garder jusqu’à la dernière seconde risque de faire disparaître le message avec la page. Le mauvais compromis faisait payer cette incertitude au lecteur, sous la forme d’un arrêt devant la porte.

Le projet de recommandation candidate du W3C du 3 août 2022 décrit une autre répartition. La page appelle navigator.sendBeacon(url, data) pour proposer de petites données à transmettre dans un seul sens. Le navigateur peut organiser et prioriser cet envoi, parfois le grouper avec d’autres opérations. Les mouvements du lecteur, les animations et le chargement suivant gardent leur place. Le coursier prend l’enveloppe; il ne demande pas au client de rester au comptoir jusqu’à l’arrivée.

L’exemple de 2022 surveille visibilitychange. Quand la page devient cachée, il peut préparer le rapport de session. Le texte explique pourquoi attendre unload est fragile sur mobile : une application passe en arrière-plan, puis le système peut fermer le processus sans cérémonie de sortie. Le signal « caché » arrive plus tôt et donne à la page le moment pratique pour remettre sa note au navigateur.

La valeur renvoyée par sendBeacon() mérite une lecture attentive. true indique que l’agent utilisateur a pu mettre les données dans sa file d’envoi. C’est l’accusé de prise en charge du coursier. La preuve d’une arrivée au serveur se cherche côté serveur. L’interface ne fournit pas de rappel pour traiter une réponse. Confondre la prise en charge et l’arrivée reviendrait à célébrer la livraison dès que la lettre entre dans la sacoche.

La taille du message compte aussi. Le projet de 2022 lie l’envoi au mécanisme fetch avec keepalive et limite les données acceptées en attente. Une page qui a besoin d’une méthode personnalisée, d’en-têtes particuliers ou d’une réponse doit utiliser l’échange adapté. Le coursier de Beacon transporte un pli, pas les meubles de l’appartement.

L’historique de publication du W3C situe le premier projet public en octobre 2013, une recommandation candidate stabilisée en avril 2017 et le projet candidat plus récent en août 2022. Ces jalons racontent l’évolution des textes. Le fil conducteur est plus simple à retenir qu’une suite de versions : une page veut envoyer un mot; le navigateur sait le prendre; le lecteur n’a plus à attendre.

Pour le public, le succès se voit à peine. La page suivante apparaît sans délai imposé par le rapport de la précédente. Pour l’éditeur, l’intérêt est très concret : il peut transmettre un petit événement sans coincer le visiteur au seuil. Le navigateur garde le travail à faire dans sa propre file, et la politesse revient à la navigation.

Un dernier mot peut être utile. Il n’a pas besoin de devenir le dernier obstacle.