Performance
Brotli vs gzip: what the difference actually weighs
On the EneUI build Brotli quality 11 saves 12-15% more than gzip level 9. Measured numbers, a command to repeat them and when compression does not help.
Key points
- Brotli at quality 11 beats gzip at level 9 by 12-15% on the files measured here.
- Across the four main files the compressed total drops from 103,362 to 89,167 bytes.
- Brotli quality 11 costs CPU: compress at build time, not on every request.
Brotli beats gzip on text: on the four files of the EneUI build of 1 November 2026, Brotli at quality 11 saves 12% to 15% more than gzip at level 9. The gain is real, but small next to the cost of compression.
The numbers
| File | Original | gzip 9 | Brotli 11 |
|---|---|---|---|
| assets/index-B90Ihhpp.js | 138,806 | 43,323 | 36,674 |
| assets/chunk-vendor-DXcH-vAE.js | 141,671 | 45,307 | 39,660 |
| assets/index-DTBUz1iZ.css | 42,147 | 8,553 | 7,565 |
| index.html | 22,933 | 6,179 | 5,268 |
Brotli wins on every file, with the widest margin on JavaScript. The total for the four files drops from 103,362 bytes with gzip to 89,167 with Brotli: 14,195 bytes fewer, 13.7%.
The command to repeat the measurement
node -e "const z=require('zlib'),f=require('fs');for(const p of process.argv.slice(1)){const b=f.readFileSync(p);console.log(p,b.length,z.gzipSync(b,{level:9}).length,z.brotliCompressSync(b,{params:{[z.constants.BROTLI_PARAM_QUALITY]:11}}).length)}" client/dist/index.htmlThe script reads the bytes, compresses in memory and prints three numbers per file: original, gzip, Brotli. It needs Node and no network; the result changes when you change the quality.
Where gzip still wins
Brotli at quality 11 costs CPU, so a server that compresses on every request is better off at quality 5, which gains much less. The strategy that pays is compressing at build time and serving the finished .br file.
When compression does not help
- Images, video and
woff2fonts are already compressed: a second pass adds bytes. - Responses under a kilobyte can grow, because the compression header costs.
- A proxy or a CDN may recompress and undo the choice made at build time.
The limitation
Four files from one project are not a benchmark. The ratio depends on the content: HTML with plenty of text gains more than already minified JavaScript, and the measurement says nothing about response time under on-the-fly compression.
Where to continue
The EneUI catalogue indexes 111,985 components and 1,556 blocks with previews. The record image stream hero loads images that compression never touches: there format and dimensions are what matter. For bundle weight read one import that grows the bundle, for headers Cache-Control explained, for the build comparison Next.js versus Vite.
Frequently asked questions
Is Brotli always better than gzip?
On text files yes, at equal effort; the gain measured here is 12-15%. On files that are already compressed neither helps, so the answer depends on the content type.
Which Brotli quality should I use?
Quality 11 for compression at build time, quality 5 for on-the-fly compression. Quality 11 shrinks the bytes further but costs a lot of CPU per request.
Is gzip still supported?
Yes, gzip remains the fallback for clients that do not declare br in Accept-Encoding. It belongs in the same response under Vary: Accept-Encoding.
Does compression change TTFB?
Yes, when you compress on every request: the CPU work enters the response time. Compressing at build time pays that cost once and leaves TTFB alone.
Should I compress HTML too?
Yes, HTML gains a lot: 22,933 bytes become 6,179 with gzip and 5,268 with Brotli. It is the first file worth compressing.