I think I can guess from corporate incentives why Chrome supports fetchLater and some others don't.

It's currently being added to WebKit: https://github.com/WebKit/WebKit/pull/73271

Regarding corporate incentives: I was involved in the design of this API, so I know the history. It was proposed many years ago as a solution to make it easier for RUM analytics providers to measure Core Web Vitals metrics that needed to account for more than just page load (e.g. layout shifts and slow interactions can happen any time, not just during page load).

The RUM providers we worked with were reluctant to wait until page unload to send telemetry data because it resulted in too many lost beacons, so what they do instead is send beacons every few seconds with the most up-to-date payload.

The `fetchLater()` API enables them to send just one beacon, which is good for users and also reduces their server load.

▲

ricardobeat a day ago | parent [-]

Why was 'fetchLater' chosen over a reliable way to trigger fetch from 'unload' or a similar event, or inversely, adding a 'sendLater' option to sendBeacon? Feels like a bolted-on API for a very specific use case, when the same thing could be built from better primitives?

It's a bit sad that browsers now have two different, "standard" APIs created entirely for the purpose of user tracking, as if things weren't already bloated enough.

▲

philipwalton a day ago | parent [-]

These exact questions came up (from Apple) during design review. If you're interested you can read the discussion here: https://github.com/WebKit/standards-positions/issues/85#issu...

	▲	fn-mote a day ago \| parent [-]
		Spot-on amazing linking exactly to the relevant discussion. I’m really glad to see this not evolve into a flame war as well.