Description
Some of our console assets are getting big. The biggest part of the bundle is getting near 1 MB minified but not gzipped.
One solution is to do more code-splitting, but that requires thinking and tweaking to get it right, whereas (as the screenshot indicates) gzipping the assets cuts them down by like 80%, which eliminates the issue in a generic way that doesn't complicate our code at the app level. It would be nice if Dropshot could gzip all responses in a generic way, because that would mean we don't have to do anything here. See oxidecomputer/dropshot#221. However, if that's not coming soon, we can pretty easily handle this ourselves.
How it works
- As part of the asset upload step, gzip all the files, making sure to add
.gz
on the end of the names
console/.github/workflows/upload-assets.yaml
Lines 27 to 31 in ddc1bb9
- In Omicron, when we look for a static asset, we look for the
.gz
version first, and if we find it, serve that with theContent-Encoding: gzip
header. Otherwise, serve the uncompressed file (assuming it's there). The key is we are using the extension to determine what to do.
https://github.com/oxidecomputer/omicron/blob/846dbfd7867619a1c2a29a5527040d4595946890/nexus/src/external_api/console_api.rs#L385-L392
Brotli?
Brotli is better than gzip and very well-supported by browsers we care about, though slower (not a problem because these are prebuilt). But it's only better by maybe 15%, so I'm not sure it's worth the complication. The good news is we can easily experiment and see what kind of gains we'd get for it.