You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
The text was updated successfully, but these errors were encountered:
@zephraph pointed out we don't even have to do the .gz check if we just assume all the console assets are gzipped. Definitely worth trying — I can't think of a reason we'd need to have a non-gzipped asset in the console assets directory, and if we run into such a reason we can add in the functionality.
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
.gz
on the end of the namesconsole/.github/workflows/upload-assets.yaml
Lines 27 to 31 in ddc1bb9
.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.
The text was updated successfully, but these errors were encountered: