Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently our unshortened URLs are compressed via LZMA (json-url library), which is unusably slow if we store all of the results. Our short URLs, before being sent to the server to be shortened, are compressed using deflate (pako), which has a bit worse than half its compression ratio if we do so.
Experimenting here with some brotli/zstd libraries. Brotli 8 and zstd 8 seem like reasonable levels, yielding similar compression ratios as json-url LZMA and similar performance to pako's deflate.
zstd is faster in this particular setup, but seems to break when reloaded by vite's hot module reloading in dev mode.
Important considerations include bundle size (brotli usually ships a large dictionary with its compressor; I think this includes it; would like to see the results without it) and future compatibility (
"Content-Encoding", "br"
exists;node:zlib
supports brotli and cloudflare workers ships it withnodejs_compat_v2
if we ever needed to decode on the server side; none of these are currently true of zstd).[draft previews]