gzip vs Brotli: quanto vale davvero la differenza, e perché un terzo dei siti pubblici non comprime ancora nulla
- vuetelemetry
- Guide
- 7 min di lettura
Brotli comprime il testo meglio di gzip, con un margine reale ma più piccolo di quanto suggerisca il marketing. Il dato più importante è altrove: su 336 enti pubblici misurati, 107 di quelli che hanno risposto inviano la home page senza alcuna compressione.
Il confronto viene di solito presentato come una scelta, e per una nuova installazione lo è. Per la maggior parte dei siti esistenti non lo è, perché la vera domanda è se venga compresso qualcosa.
Cosa abbiamo misurato, e quanto costa
Abbiamo misurato 336 enti pubblici portoghesi il 6 settembre 2026, una richiesta ciascuno, leggendo solo le intestazioni di risposta e la dimensione dell'HTML trasmesso. Hanno risposto in 291. 107 di loro, il 36,8 %, inviavano la home page senza alcuna codifica del contenuto.
Il costo non è teorico. Tra i siti che comprimono, la home page mediana pesa 29 312 byte trasmessi. Tra quelli che non comprimono, la mediana è di 109 705 byte. Sono 3,7 volte più dati per lo stesso tipo di pagina, e diciotto dei siti non compressi superano i 200 kB di solo HTML, il più pesante con 536 245 byte.
Il confronto vero e proprio
Ora il confronto vero e proprio. gzip è supportato ovunque dagli anni Novanta ed è la scelta predefinita sicura. Brotli, standardizzato nel 2016, è supportato da tutti i browser attuali su HTTPS e produce di solito un risultato più piccolo sul testo, con il guadagno concentrato su HTML, CSS e JavaScript e non sui formati già compressi.
- curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding
- Nessuna riga content-encoding: non viene compresso nulla
- content-encoding: br significa che è stato negoziato Brotli, gzip significa il ripiego
- Testate su HTTPS: i browser non offrono Brotli in HTTP semplice
- Limitate la compressione ai tipi di testo; immagini e video non guadagnano nulla
Il modo onesto di esprimere la differenza è che Brotli vince sul testo e che il margine varia con il contenuto e con il livello di compressione scelto. Chi vi cita un'unica percentuale universale vi cita un benchmark, non il vostro sito. Misurate il vostro: basta una richiesta.
I livelli contano più dell'algoritmo
L'impostazione del livello conta più della scelta dell'algoritmo, ed è lì che si trovano quasi tutti gli errori di configurazione. Brotli offre i livelli da 0 a 11. Il livello 11 è così lento che usarlo su risposte generate dinamicamente può costare più tempo di server di quanto ne faccia risparmiare nel trasferimento. La soluzione abituale è un livello alto per le risorse statiche compresse una volta in fase di build, e un livello moderato per tutto ciò che viene generato a ogni richiesta.
gzip ha la stessa struttura con i livelli da 1 a 9, e la stessa trappola: il livello massimo è raramente quello giusto per i contenuti dinamici.
Negoziazione, HTTPS, e cosa non comprimere
La negoziazione del contenuto decide quale si usa, e non dipende solo da voi. Il browser invia `Accept-Encoding: gzip, deflate, br` e il server sceglie. Configurarli entrambi significa che i client moderni ricevono Brotli e tutto il resto ripiega su gzip, ed è per questo che non si tratta davvero di una scelta esclusiva.
Un dettaglio pratico che inganna spesso: i browser offrono Brotli solo su HTTPS. Un sito testato in HTTP semplice sembrerà non supportare Brotli anche quando lo fa.
Comprimere formati già compressi è lavoro sprecato. JPEG, PNG, WebP, MP4 e la maggior parte dei formati di carattere non guadagnano nulla e consumano CPU. Limitate la compressione ai tipi MIME di testo, che è l'impostazione predefinita nella maggior parte delle configurazioni ragionevoli e la prima cosa da controllare nelle altre.
Verificate il vostro sito con una richiesta
Verificare il vostro sito richiede un solo comando, ed è lo stesso che abbiamo lanciato 336 volte:
FAQ
Brotli è sempre migliore di gzip?
Sul testo Brotli produce in genere un risultato più piccolo di gzip a parità di impostazioni, e il margine dipende dal contenuto e dal livello scelto. Non è migliore sui formati già compressi come JPEG o MP4, dove nessuno dei due algoritmi aiuta. Configurarli entrambi è la risposta normale, perché il browser negozia quale riceve.
Come verifico se il mio sito comprime qualcosa?
Inviate una richiesta con un'intestazione Accept-Encoding e leggete la risposta: curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding. Se non torna alcuna riga content-encoding, non viene compresso nulla.
Perché il mio sito non usa Brotli anche se il server lo supporta?
Il motivo più frequente è che avete testato in HTTP semplice. I browser annunciano Brotli solo su HTTPS, quindi un test in HTTP fa sembrare privo di supporto un server configurato correttamente. Il secondo motivo più frequente è che il modulo di compressione è attivo ma limitato a un elenco di tipi MIME che non include il vostro tipo di contenuto.
Conviene usare il livello di compressione massimo?
Per le risorse statiche compresse una volta in fase di build un livello alto è ragionevole, perché il costo si paga una sola volta. Per le risposte generate a ogni richiesta, i livelli più alti possono costare più tempo di server del trasferimento che fanno risparmiare. Un livello moderato per i contenuti dinamici e uno alto per i file statici è la soluzione abituale.
Quanto costa davvero non comprimere?
Nella nostra misurazione di 291 enti pubblici che hanno risposto il 6 settembre 2026, la home page mediana pesava 29 312 byte trasmessi con la compressione attiva e 109 705 byte senza, un fattore di 3,7 per pagine comparabili. Diciotto siti non compressi superavano i 200 kB di solo HTML.
**Comprimere formati già compressi è lavoro sprecato.** JPEG, PNG, WebP, MP4 e la maggior parte dei formati di carattere non guadagnano nulla e consumano CPU. Limitate la compressione ai tipi MIME di testo, che è l'impostazione predefinita nella maggior parte delle configurazioni ragionevoli e la prima cosa da controllare nelle altre.