Authors: Darren Willis, Fergal Daly, Ming-Ying Chung - Google
This repository hosts multiple technical explainers for a system for sending beacons when pages are discarded, rather than requiring developers explicitly send beacons themselves.
This document offers an overview of the system and its explainers.
Web developers have a need for ‘beaconing’ - that is, sending a bundle of data to a backend server, without expecting a particular response, ideally at the ‘end’ of a user’s visit to a page. There are currently four major methods of beaconing used around the web (there may be other methods; the followings are the main ones):
<img>
tags inside dismissal events.XMLHttpRequest
(but it doesn’t work as part of dismissal events).navigator.sendBeacon()
API.fetch()
API with the keepalive: true
flag.The above methods all suffer from reliability problems, stemming from one core issue: There is not an ideal time in a page’s lifecycle to make the JavaScript call to send out the beacon.
unload
and beforeunload
are unreliable,
and outright ignored by several major browsers.pagehide
and visibilitychange
have issues on mobile platforms.To simplify the above issues and make beaconing more reliable, this repository proposes adding a stateful JavaScript API, where a page can register that it wants a beacon issued when the Document is unloaded or hidden.
Developers can populate beacon(s) with data as the user uses the page, and the browser ensures beacon(s) are reliably sent at some point in time. This frees developers from worrying about which part of the page lifecycle to send their beacon calls in.
The followings are critical:
The followings are good-to-have:
Previous proposals:
Deferred fetching PR - whatwg/fetch