-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to request beacon be compressed #72
Comments
/cc @ricea |
+1 to this from Etsy’s perspective! Particularly with RUM data the payload can be big, and this would allow us to use compression in more cases. |
+1 from Wikimedia as well. A few things come to mind: There is a perhaps not-so-obvious need for support on the server-side here. Which means if an intermediary library changes its There is also a perhaps not-so-obvious need for that same server to also retain ability to process uncompressed submissions as browsers presumably don't have to follow this option, at least until all browsers support it. That leaves us with how to spec this. Do we spec it as something the browser must implement and must follow if passed? That seems simplest, but means it's less obvious that the same code interpreted by browsers following an older version of the spec ignore the option. I wonder if it would make sense to spec it has a hint and let the browser decide. That would make it more obvious that receiving servers can't assume all inputs to be compressed, and also leaves some room for "user/device knows best"-type optimisations based on whatever hueristics browser vendors and users may come up with in the future (e.g. optimise for high bandwidth, or low CPU, or skip below size threshold etc.) On naming, if this will involve the |
Those are great points @Krinkle!
I think that is right, but it seems reasonable to me that companies would need to make a conscious decision to enable the compression feature via the parameter, and then would also be responsible for updating their observability systems to accept & un-encode the payload based on
This seems like another fair tradeoff to me. Not sure how widespread this is as a practice, but we already have to do a similar multi-type support in our data capture endpoints to accept both The complexity could potentially be alleviated by exposing the supported compression types and then using different URLs per send type - something like this?
However if your idea of browsers using it as a hint takes off, then that would make it much more complex of an API that would need to be exposed in order to do that kind of url switching in client code. I'm not sure though if that's a solid argument against treating it as a hint or not? Interestingly when I ran a test of @nicjansma 's example code in Chrome 96, currently when you send the compressed results through |
There are 2 ways we could go about this:
(2) seems more robust and ergonomic, especially if we want the browser to potentially beacon the data once the renderer is no more. /cc @mnot @reschke - as I vaguely remember conversations about the use of Content-Encoding as a request header field, but don't remember their details. |
Given that PendingBeacon is the next big thing, should we aim for this use case to be supported there instead? /cc @clelland |
@nicjansma - I'd also love your thoughts on whether the PendingBeacon proposal obsoletes this feature request |
Yes definitely! I was just reading over the proposal for PendingBeacons and it seems like it would solve quite a number of issues, it would be great to get compression support built into that API vs. a later bolt-on. |
I think that's fair to push this to PendingBeacon. As far as I can tell, there's nothing significant you could do with |
It would be interesting to consider an option for the beacon API where you could request the payload to be compressed before being sent.
With the
sendBeacon()
API today, if you want to do some sort of compression on the data before sending it, you would use the Compression Stream API, which is an async-only API.Here's an example of doing this at e.g. page load time:
Unfortunately if you wanted to do this at
pagehide
/beforeunload
/unload
, you can't utilize the Compression Stream API since it is async. You would be waiting for the stream callback (await
), but by then the page would be unloaded:If we could ask the browser to compress the payload before sending, it could look something like this:
And we could easily get it compressed from unload-style events (assuming the browser handles that async compression and beaconing later).
The text was updated successfully, but these errors were encountered: