A stateful API for beacons that has the browser control the time beacons are sent. Existing beacon APIs are all based around a developer constructing and sending a beacon, and there's no good time for that "send" call to be made. (Handlers such as 'unload' are often ignored, for example.) This API delegates the sending to the browser itself, so it can support beacons on page unload or on page hide, without the developer having to implement send calls at exactly the right times.


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; 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), and pageHide and visibilityChanged have issues on mobile platforms. To simplify this issue and make beaconing more reliable, we propose adding a stateful Javascript API where a page can register that it wants a beacon (or beacons) issued when it unloads or the page is 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.

Status in Chromium


No active development (tracking bug)

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

  • No signal
  • No signal
  • No signals


Intent to Prototype url

Intent to Prototype thread

Last updated on 2022-05-09