@annevk @philipwalton @clelland
Forking off from this comment.
It's not that keepalive is fundamentally broken, it's that the there is reliable way to initiate these kinds of fetches from JS and there cannot be. You must either oversend or accept losing a lot of fetches (especially on mobile).
If we really wanted to keep using window.fetch, then we could perhaps add a defer-send option.
Such a fetch would
- not send immediately (and would behave like a beacon for its send timing)
- maybe never resolve its promise, certainly the caller should not expect it to happen but it might be OK to resolve those that are sent before the page is destroyed. It might be better to consistently never resolve, so that nobody depends on it.
The existing abort signal option would give us control over cancelling. We would probably want more options that only apply to deferred fetches to deal with timing.
Are there options on fetches that we would want to disallow for a deferred fetch?
@annevk @philipwalton @clelland
Forking off from this comment.
It's not that keepalive is fundamentally broken, it's that the there is reliable way to initiate these kinds of fetches from JS and there cannot be. You must either oversend or accept losing a lot of fetches (especially on mobile).
If we really wanted to keep using window.fetch, then we could perhaps add a
defer-sendoption.Such a fetch would
The existing abort
signaloption would give us control over cancelling. We would probably want more options that only apply to deferred fetches to deal with timing.Are there options on fetches that we would want to disallow for a deferred fetch?