We currently have .js and .js.gz — Brotli will be even smaller and the extra CPU cost doesn't matter because we're doing it at build time. We would need to add support for brotli files to Nexus here.
I had Claude compare different compression algos:
What do we get for it?
Measured on a fresh production build (.js + .css only — the actual first-load payload; sourcemaps excluded since they're only fetched when devtools open). Raw total: 2.62 MB.
| Encoding |
Size |
% of raw |
vs gzip-9 |
| gzip -6 (current) |
823 KB |
31.4% |
baseline |
| gzip -9 |
822 KB |
31.4% |
−0.2% |
| deflate (zlib -9) |
821 KB |
31.3% |
−0.1% |
| zstd -19 |
764 KB |
29.1% |
−7.0% |
| zstd -22 |
764 KB |
29.1% |
−7.0% |
| brotli q11 |
708 KB |
27.0% |
−13.8% |
For the dominant first-load chunk index.js (622 KB raw): gzip 185 KB → zstd-19 164 KB → brotli 156 KB (−16% vs gzip).
On deflate (your question)
Skip it. "deflate" Content-Encoding is the same DEFLATE algorithm as gzip with a zlib wrapper instead of the gzip header — it came out 0.1% smaller than gzip-9 (just header-byte savings). No reason to add it.
Level sensitivity
- gzip: -6 vs -9 is a rounding error (~0.2%). The current
-6 default is fine; no point bumping.
- zstd: -3 is worse than gzip (855 KB); only high levels help, and -19 ≈ -22 here. Use -19 if used at all.
- brotli: q5→q9→q10→q11 = 773→760→720→708 KB. q11 is the clear pick. Build cost is trivial since it's once per deploy in CI — q11 over all files (incl. maps) took ~12s sequential; js+css alone is ~2s.
Browser support
- brotli (
br): universal in all modern browsers over HTTPS (the console is HTTPS). Safe, highest value.
- zstd (
zstd): Chrome 123+ / Firefox 126+ (both 2024), not Safari. Fewer clients advertise it, so it'd be a fallback tier between brotli and gzip.
Recommendation
Add brotli q11 alongside gzip — ~14% smaller payloads (~113 KB off total, ~16% off the big chunk) at near-zero build/serving cost, with universal browser support. zstd-19 is a reasonable optional middle tier given the negotiation handles fallback, but it's a smaller, Safari-less win. Drop deflate.
We currently have .js and .js.gz — Brotli will be even smaller and the extra CPU cost doesn't matter because we're doing it at build time. We would need to add support for brotli files to Nexus here.
I had Claude compare different compression algos:
What do we get for it?
Measured on a fresh production build (
.js+.cssonly — the actual first-load payload; sourcemaps excluded since they're only fetched when devtools open). Raw total: 2.62 MB.For the dominant first-load chunk
index.js(622 KB raw): gzip 185 KB → zstd-19 164 KB → brotli 156 KB (−16% vs gzip).On deflate (your question)
Skip it. "deflate" Content-Encoding is the same DEFLATE algorithm as gzip with a zlib wrapper instead of the gzip header — it came out 0.1% smaller than gzip-9 (just header-byte savings). No reason to add it.
Level sensitivity
-6default is fine; no point bumping.Browser support
br): universal in all modern browsers over HTTPS (the console is HTTPS). Safe, highest value.zstd): Chrome 123+ / Firefox 126+ (both 2024), not Safari. Fewer clients advertise it, so it'd be a fallback tier between brotli and gzip.Recommendation
Add brotli q11 alongside gzip — ~14% smaller payloads (~113 KB off total, ~16% off the big chunk) at near-zero build/serving cost, with universal browser support. zstd-19 is a reasonable optional middle tier given the negotiation handles fallback, but it's a smaller, Safari-less win. Drop deflate.