API Reliability

[mingyc]

Current spec proposal https://github.com/whatwg/fetch/pull/1647 does not include anything about reliability.

The question about "How reliable fetchLater should be" has been brought up again during Chromium implementation. Quoted from the discussion:

My feeling is that the proposed fetchLater API is not suitable for mission critical applications.
For example, there is no way to detect network error. So if the network is not available (it is
common on mobile networks), the requested data will just be lost. And there is no way to detect 
such failure.

Considering this fetchLater API is not for mission critical applications, I think it is reasonable
to accept the risk of data lost if the renderer crashes while [updating a pending request]
(https://github.com/WICG/pending-beacon/blob/f4f4b31/docs/fetch-later-api.md#update-a-pending-request).

I don’t know what level of robustness web developers want. But if we want to implement a more
robust API, I think the design of the API will be similar to [Background Fetch API]
(https://wicg.github.io/background-fetch/). (There seems no way to update requests in the 
Background Fetch API though.)

Note that retry & recovery from storage are also in the following issues:

• Retry: https://github.com/WICG/pending-beacon/issues/40
• Crash Recovery: https://github.com/WICG/pending-beacon/issues/34

[screenspan]

I'd like to share some feedback regarding how reliably fetchLater posts data, hoping this is the right issue for that.

Using the Chrome Origin Trial, we from Speed Kit found:

• 97.9% of over 38 million tracking beacons from mobile and desktop devices were successfully sent after 60 seconds (i.e. using the activateAfter option), which was higher than sending beacons on unload, beforeunload, pagehide, or visibilitychange.
• Reliability was slightly higher on desktop Chrome (99%) than on mobile Chrome (97.3%).

That said, we did not test reliability together with preloading (e.g. via Speculation Rules), nor did we try to change or cancel fetchLater requests, nor did we experiment with different activateAfter times.

[nicjansma]

I've had a chance now to look at fetchLater()'s reliability as well, and compared it to my previous experiments with Pending Beacon.

Details here:

https://nicj.net/beaconing-in-practice-fetchlater/

TL;DR:

• My previous reliability concerns with Pending Beacon's reliability were likely due to not using .sendNow() when doing { timeout: 0 }.
• If sending data during onload, fetchLater() is slightly more reliable than sendBeacon() (< 1% difference)
• If sending data during pagehide or visibilitychange[hidden], sendBeacon() is slightly more reliable than fetchLater() (~1% better). It’s probably worthwhile to look into this a bit further why.
• fetchLater() gives some developer ergonomics with activateAfter that results in more reliable beacons than listening to unload handlers

I’m really excited for the fetchLater() API. It’s giving developers better ergonomics for sending data, and a more reliable way to send beacons at the end of the page lifetime.