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):

• Adding <img> tags inside dismissal events.
• Sending a sync XMLHttpRequest (but it doesn’t work as part of dismissal events).
• Using the navigator.sendBeacon() API.
• Using the 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:

1. Support a reliable mechanism for delaying operation until page is unloaded, or evicted from bfcached.
2. Behave like a keepalive fetch request when 1's mechanism triggers.
3. Allow pending requests to be updated to reduce network usage.
4. Allow to specify a duration to accelerate beacon sending after page is bfcached.

The followings are good-to-have:

1. When browser crashes, app is forced to close, etc, the browser should make an effort to send the beacons the next time it is launched.
2. The beacon data, including URL and body, should be modifiable.

• fetchLater() API: The latest API proposal, currently under specification.

Previous proposals:

• [DEPRECATED] fetch() with PendingRequest API: The transitional API proposal and discussions happened between PendingBeacon API and fetchLater API.
• [DEPRECATED] PendingBeacon API: The initial experimental API, available as Chrome Origin Trial from M107 to M115.

• Deferred fetching - whatwg/fetch: PR, Spec Preview
• Reserve/free quota for fetchLater - whatwg/html: PR

See Alternative Approaches.

• WebKit Standards Positions
• Mozilla Standards Positions
• TAG Design Review
• Yours - Open an issue