If this comes to fruition, it means VisualEditor won't have to download
the easy-deflate.deflate pako's deflate module anymore before it can submit edits. This module currently has an upfront cost of 10 KB 8800 bytes (in practice 11.5K, see note) in bandwidth, 32 27 (pre-minified) KB in source code that requires parsing and execution. (based on easy-deflate.core + easy-deflate.deflate pako).
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.