fetchLater() API

Developers often need to send (or beacon) data back to the server, particularly at the end of a user's visit to a page — for example, for analytics services. There are several ways to do this: from adding 1 pixel <img> elements to the page, to XMLHttpRequest, to the dedicated Beacon API, and the Fetch API itself.

The issue is that all of these methods suffer from reliability problems for end-of-visit beaconing. While the Beacon API and the keepalive property of the Fetch API will send data, even if the document is destroyed (to the best efforts that can be made in this scenario), this only solves part of the problem.

The other — more difficult — part to solve concerns deciding when to send the data, since there is not an ideal time in a page's lifecycle to make the JavaScript call to send out the beacon:

• The unload and beforeunload events are unreliable, and outright ignored by several major browsers.
• The pagehide and visibilitychange events are more reliable, but still have issues on mobile platforms.

This means developers looking to reliably send out data via a beacon need to do so more frequently than is ideal. For example, they may send a beacon on each change, even if the final value for the page has not yet been reached. This has costs in network usage, server processing, and merging or discarding outdated beacons on the server.

Alternatively, developers can choose to accept some level of missing data — either by:

• Beaconing after a designated cut-off time and not collecting later data.
• Beaconing at the end of the page lifecycle but accepting that sometimes this will not be reliable.

The fetchLater() API extends the Fetch API to allow setting fetch requests up in advance. These deferred fetches can be updated before they have been sent, allowing the payload to reflect the latest data to be beaconed.

The browser then sends the beacon when the tab is closed or navigated away from, or after a set time if specified. This avoids sending multiple beacons but still ensures a reliable beacon within reasonable expectations (i.e., excluding when the browser process shuts down unexpectedly during a crash).

Deferred fetches can also be aborted using an AbortController if they are no longer required, avoiding further unnecessary costs.

Deferred fetches are batched and sent once the tab is closed; at this point, there is no way for the user to abort them. To avoid situations where documents abuse this bandwidth to send unlimited amounts of data over the network, the overall quota for a top-level document is capped at 640KiB.

Callers of fetchLater() should be defensive and catch QuotaExceededError errors in almost all cases, especially if they embed third-party JavaScript.

Since this cap makes deferred fetch bandwidth a scarce resource, which needs to be shared between multiple reporting origins (for example, several RUM libraries) and subframes from multiple origins, the platform provides a reasonable default division of this quota. In addition, it provides deferred-fetch and deferred-fetch-minimal Permissions Policy directives to allow dividing it differently when desired.

See fetchLater() quotas for more details and examples.

Window.fetchLater()

Used to queue a resource for sending at a later point.

DeferredRequestInit

Represents the set of options that can be used to configure a deferred fetch request.

FetchLaterResult

Represents the result of requesting a deferred fetch.

deferred-fetch

Controls top-level quota for the fetchLater() API.

deferred-fetch-minimal

Controls shared cross-origin subframe quota for the fetchLater() API.

• fetchLater() quotas
• Fetch API