Agreed the line can be blurry, but I want to stress that the goal of this project is NOT to push Chrome-only APIs on users.

The mental model we've been using on the team is:

If you hired an expert web development consultant to build X, what would they recommend as a best practice? When does it make sense to use the new API (because it provides real benefits) vs. when does it make sense to wait until it's available everywhere?

To use your `fetchLater()` example, this is a case where the `fetchLater()` API legitimately solves a very real problem for people trying to build accurate analytics or telemetry features, see: https://nicj.net/beaconing-in-practice/

And lots of companies actually are already using `fetchLater()` in production now because of its increased reliability.

▲

2 minutes ago | parent | next [-]

[deleted]

▲

cma 2 hours ago | parent | prev [-]

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

	▲	philipwalton 44 minutes ago \| parent [-]
		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.