search

whatwg / compression

Compression Standard
https://compression.spec.whatwg.org/
Other
85 stars 21 forks source link

Blocking APIs in Workers? #38

Open ricea opened 3 years ago

ricea commented 3 years ago

From a usability perspective, a blocking API is very attractive. However, the impact on interactivity would be unacceptable on the main thread.

An interesting possibility is to provide a blocking API only in workers.

Maybe something like

[Exposed=Worker] static Uint8Array blockingCompress(DOMString format, BufferSource input);

See also https://github.com/WICG/compression/issues/8 for an equivalent non-blocking method and https://github.com/WICG/compression/issues/37 for motivation.

nicjansma commented 2 years ago

One place where a blocking API could be helpful is for cases of using compression in unload, i.e. beaconing data for analytics usage. RUM libraries like boomerang.js hook into pagehide etc, and we often beacon data at the end of the page session.

However, we don't know of an easy way to utilize the Compression Streams API in this scenario as the async nature means we won't get the compressed bytes for passing to .sendBeacon() in the pagehide handler in time -- the page has unloaded waiting for the callback/await.

I've added an idea to the Beacon API tracker to see if it could compress on its own https://github.com/w3c/beacon/issues/72, but it could also possibly be solved with a sync API here. Though having the sendBeacon() API allow for this may be more ideal, as it it could handle the compression off-thread and off the critical path of the page unloading.