Skip to content

Serve compressed console assets #946

Closed
@david-crespo

Description

@david-crespo

Some of our console assets are getting big. The biggest part of the bundle is getting near 1 MB minified but not gzipped.

image

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

  1. As part of the asset upload step, gzip all the files, making sure to add .gz on the end of the names
    - name: Build for Nexus
    run: yarn build-for-nexus
    - run: mkdir -p releases/console
    - name: Make <sha>.tar.gz
    run: tar czf releases/console/${{ github.sha }}.tar.gz --directory=dist .
  2. In Omicron, when we look for a static asset, we look for the .gz version first, and if we find it, serve that with the Content-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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions