v135 · network / connectivity
fetchLater API
fetchLater() is a JavaScript API to request a deferred fetch. Once called in a document, a deferred request is queued by the browser in the PENDING state, and will be invoked by the earliest of the following conditions:
concepts
-
Queue a deferred request
The raw API form: set a URL, body, and
activateAfter, queue a single request, and watch the live capability pill report whether it actually landed inwindow.fetchLater. -
Analytics that survives an unload
The pending-beacon use case the API was designed for. Click events queue native
fetchLater()requests when available or send a real beacon/keepalive fallback to the backend receiver. -
Budget and priority lab
Queue requests with different payload sizes and watch the 64KB origin budget tick down. Trigger the
QuotaExceededErrorrejection by exceeding it — exactly the abuse safeguard Chrome ships. -
Session Heartbeat
A keep-alive heartbeat queued with fetchLater() that fires automatically on page unload or after a deadline — no beforeunload hack needed. Fallback controls send real keepalive/beacon requests to the backend.
-
Error Reporter
An error reporting pipeline that uses fetchLater() for durable delivery. Simulate six error types, watch them queue up with 30-second activateAfter deadlines, then trigger a page-hide flush. Compare how fetchLater vs keepalive vs synchronous fetch handle unload-time delivery.
why it shipped
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.