Re: [w3ctag/design-reviews] Early Design Review: Pending Beacon API (Issue #776)

@npdoty 
>Just a +1 for including some explanation of how or why this would benefit users.

> It seems like the implicit reasoning here (as with previous Beacon APIs) is that websites want to send potentially large amounts of data particularly when a user navigates away from a page. Doing this in the background perhaps makes current abusive behavior (attempts to block navigation altogether until the data is sent) less annoying. But as a side effect, it means that the network traffic happens when the user is doing something else. The page that collected and sent the traffic is more opaque to the user, and any slowdowns that happen won't be attributed back to the page causing them, so more pages may feel comfortable collecting and sending more data.

The criticisms apply to `keep-alive` fetch and somewhat to `sendBeacon`.

`sendBeacon` is [explicltly specced](https://w3c.github.io/beacon/#sendbeacon-method) not to contend for network or CPU with the next page-load, pending beacon should do something similar, although I don't think we have called that out in the explainer. It is also allowed to delay sending while the page is visible, to save network/battery.

They both impose a quota on how much data there can be outstanding. The quota is shared with the pending beacons too. Discussion is still [ongoing](https://github.com/WICG/pending-beacon/issues/76) on how exactly to make that work but this should be a neutral change in that regard.

`keep-alive` fetch is eager when called with the request starting immediately.

`keep-alive` fetch must read the entire response. We don't expect beacon responses to be large (since they cannot be accessed from JS) but if they are, there may be an occasional win there in not reading them.

Pending beacon allows updating the payload (most likely cancel and replace) this means they will send less data overall than `sendBeacon`.

Also, vs `keep-alive` fetch, knowing that the request is a beacon, not requiring a response means that browsers have flexibility on how/when to send these. I think we'd want to see it being a real problem before trying any of these but browsers could delay sending beacons for a few seconds if another page has just started loading or just send them rate-limited. I would expect that responses will be minimal since they cannot be accessed from JS but there may also be something to be gained not reading responses past the headers and closing the connection when the payload is confirmed accepted. The same argument is a positive for `sendBeacon`.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/776#issuecomment-1526898444
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/776/1526898444@github.com>