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`~~ [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/resources/lib/pako/| 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).
NOTE: "8800 bytes" was said in T236210, but that's for the pre-minified version as provided by the pako project. It appears MediaWiki includes the full version and relies solely on ResourceLoader to minify it. Search [[https://en.wikipedia.org/w/load.php?lang=en&modules=mediawiki.deflate&skin=vector | the downloaded code ]] for "arraySet", the function arguments would be shortened in the pre-minified version. The ResourceLoader-minified module is ~11.5K after gzip.
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}
* {T236210}