feat(wasm): compress wasm binaries with gzip to improve load times
nberlette opened this issue · comments
About
Currently the start up time for the WASM implementation is brutal (for example, the typescript plugin file is around 6MB all by itself).
This could be partially mitigated by compressing/decompressing the files as needed - and it could be done using nothing more than the native CompressionStream
and DecompressionStream
APIs.
While the smallest file size (and best compression) is found with the Brotli algorithm, it's currently not supported by the streaming APIs. I've found the brotli compression side of things to be painfully slow (~15s to compress one of the dprint plugin files); I don't think that's an even tradeoff for the minimal gains of about 10-15% smaller compressed file size.
I'll be implementing this in an upcoming PR, along with .ipynb
support as mentioned in #3.
Decisions
These questions need to be answered before this can move forward into reality.
- should filenames have
.gz
or similar added to denote the compression? - should we use
"gzip"
,"deflate"
, or"deflate-raw"
?ℹ can't change this without fallout once this ships. choose wisely.
Checklist
Things that need to be implemented in order for this feature to ship.
- pipe incoming responses through a
CompressionStream
(./update-plugins.ts
)ℹ for incoming wasm from the
dprint.dev
plugin server (plugin updates) - pipe responses to the formatter through
DecompressionStream
(./dprint.ts
)ℹ for outgoing wasm requested from the client (via a Formatter instance)