# Brotli vs gzip: quanto pesa davvero

Sulla build EneUI Brotli qualità 11 risparmia il 12-15% in più di gzip livello 9. Numeri misurati, comando per rifarli e quando la compressione non serve.

> Pagina: https://ui.eneawork.it/blog/compressione-brotli-gzip
> Markdown: https://ui.eneawork.it/blog/compressione-brotli-gzip.md

*2026-11-01*

Brotli batte gzip sul testo: sui quattro file della build EneUI del 1 novembre 2026, Brotli a qualità 11 risparmia dal 12% al 15% in più di gzip a livello 9. Il guadagno è reale, ma piccolo rispetto al costo di compressione.

Abbiamo misurato i quattro file principali di client/dist il 1 novembre 2026 con zlib di Node: gzip a livello 9 e Brotli a qualità 11, in memoria, senza rete. Su index-B90Ihhpp.js 138.806 byte diventano 43.323 con gzip e 36.674 con Brotli. La produzione serve già Content-Encoding: br quando il client dichiara Accept-Encoding: br, gzip. Il catalogo EneUI misura 111.985 componenti, 1.556 blocchi e 12.808 icone da 1.472 librerie, letti da /api/stats il 1 novembre 2026. Formati: RFC 7932 per Brotli, RFC 1952 per gzip.

## I numeri

Brotli vince su ogni file, con il margine più largo sul JavaScript. Il totale dei quattro file passa da 103.362 byte con gzip a 89.167 con Brotli: 14.195 byte in meno, il 13,7%.

## Il comando per rifare la misura

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.html

Lo script legge i byte, comprime in memoria e stampa tre numeri per file: originale, gzip, Brotli. Serve Node e non serve la rete; il risultato cambia se cambi la qualità.

## Dove gzip conviene ancora

Brotli a qualità 11 costa CPU, quindi su un server che comprime a ogni richiesta conviene qualità 5, che guadagna molto meno. La strategia che paga è comprimere al build e servire il file .br già pronto.

## Quando la compressione non serve

## La limitazione

Quattro file di un progetto non sono un benchmark. Il rapporto dipende dal contenuto: l'HTML con molto testo guadagna più di un JavaScript già minificato, e la misura non dice nulla sul tempo di risposta con compressione al volo.

## Dove continuare

Il catalogo EneUI indicizza 111.985 componenti e 1.556 blocchi con preview. Il record image stream hero carica immagini che la compressione non tocca: è il caso in cui contano formato e dimensioni. Per il peso del bundle leggi un import che aumenta il bundle, per gli header Cache-Control spiegato, per il confronto tra build Next.js contro Vite.

## FAQ

### Brotli è sempre meglio di gzip?

Sui file di testo sì, a parità di sforzo; il vantaggio misurato qui è del 12-15%. Su file già compressi nessuno dei due serve, quindi la risposta cambia per tipo di contenuto.

### Che qualità di Brotli devo usare?

Qualità 11 per la compressione al build, qualità 5 per quella al volo. La 11 riduce ancora i byte ma costa molta CPU per richiesta.

### gzip è ancora supportato?

Sì, gzip resta il fallback per i client che non dichiarano br in Accept-Encoding. Serve come secondo formato nello stesso Vary: Accept-Encoding.

### La compressione cambia il TTFB?

Sì, se comprimi a ogni richiesta: la CPU entra nel tempo di risposta. Comprimendo al build il costo si paga una volta e il TTFB non cambia.

### Devo comprimere anche l'HTML?

Sì, l'HTML guadagna molto: 22.933 byte diventano 6.179 con gzip e 5.268 con Brotli. È il primo file che conviene comprimere.