Standardisation effort has recently begun on exposing compression mechanisms, which browser have held natively for decades, to JavaScript execution.
If this comes to fruition, it means VisualEditor won't have to download the `easy-deflate.deflate` module anymore before it can submit edits. This module currently has an upfront cost of 10 KB in bandwidth, 32 KB in source code that requires parsing and execution. (based on `easy-deflate.core + easy-deflate.deflate`).
In a nut shell:
* Add a small suffix to our `easy-deflate` module that wraps it in a CompressionStream-compatible interface.
* Deprecate and remove direct access to the non-CompressionStream globals. Possibly by proxy of deprecating the module itself and re-exposing under a new name (e.g. `compression-stream`)
* Make the `compression-stream` a "skippable" module based on a CompressionStream feature-test (e.g. `!!window.CompressionStream`). Similar to how we did in the past with the `json`, `dom-level-2` and `es5-shim` modules. Thus allowing VisualEditor to them on them, and yet cause no download if they are natively supported.
Links:
* <https://ricea.github.io/compression/>
* <https://github.com/ricea/compressstream-explainer>
* <https://github.com/mozilla/standards-positions/issues/207>
* <https://twitter.com/jaffathecake/status/1180060812783882240>
See also:
* {T68914}