Brotli vs Gzip nel 2026: differenze e prestazioni

Brotli vs Gzip: quale sistema di compressione conviene utilizzare nel 2026 per ridurre il peso di HTML, CSS, JavaScript e degli altri contenuti testuali di un sito web?

La compressione HTTP è una delle tecniche più efficaci per diminuire la quantità di dati trasferiti tra server e browser. Invece di inviare il file originale, il server può comprimerlo prima della trasmissione e il browser lo decomprime automaticamente una volta ricevuto.

Per molti anni Gzip è stato lo standard più diffuso. Oggi, però, Brotli è supportato dai browser moderni e può offrire una compressione più efficiente, soprattutto per HTML, CSS, JavaScript, JSON e altri contenuti testuali.

Questo non significa che Gzip sia diventato inutile.

Nel 2026 la strategia migliore consiste spesso nel supportare entrambi e lasciare che browser e server negozino automaticamente il formato più adatto.

Brotli vs Gzip: le differenze principali

Gzip e Brotli hanno lo stesso obiettivo: ridurre il peso dei dati prima che vengano trasferiti attraverso la rete.

La differenza principale riguarda l’algoritmo utilizzato e il rapporto tra:

• dimensione finale del file;
• tempo necessario per comprimere;
• utilizzo della CPU;
• velocità di decompressione;
• compatibilità del client.

In termini generali:

Gzip offre un eccellente compromesso tra velocità, compatibilità e compressione.

Brotli può ottenere una compressione migliore, soprattutto sui contenuti testuali, ma ai livelli più elevati può richiedere molto più tempo di CPU durante la fase di compressione.

Cos’è Gzip

Gzip è un formato di compressione utilizzato da moltissimi anni sul Web.

In ambiente HTTP il browser può indicare al server di supportare Gzip attraverso l’header:

Accept-Encoding: gzip

Se il server decide di utilizzare questa codifica, restituisce:

Content-Encoding: gzip

Il browser riceve il contenuto compresso e lo decomprime automaticamente prima di elaborarlo.

Dal punto di vista dell’utente non cambia nulla.

La pagina HTML continua a essere visualizzata normalmente, ma il numero di byte trasferiti attraverso la rete può essere molto inferiore.

Cos’è Brotli

Brotli è un formato di compressione lossless specificato nella RFC 7932.

È stato progettato per ottenere un’elevata efficienza di compressione attraverso tecniche basate su LZ77, codifica Huffman e altre ottimizzazioni.

Il suo identificatore HTTP è:

br

Un browser moderno può quindi inviare, ad esempio:

Accept-Encoding: gzip, deflate, br, zstd

Se il server sceglie Brotli, la risposta includerà:

Content-Encoding: br

La negoziazione viene gestita automaticamente tramite HTTP.

Come funziona Accept-Encoding

Il browser comunica al server quali algoritmi di compressione è in grado di utilizzare attraverso l’header Accept-Encoding.

Un esempio moderno può essere:

Accept-Encoding: gzip, deflate, br, zstd

Il server analizza l’elenco e sceglie una codifica supportata.

La scelta viene poi comunicata attraverso:

Content-Encoding: br

oppure:

Content-Encoding: gzip

La documentazione MDN dedicata ad Accept-Encoding descrive questo meccanismo di content negotiation.

Brotli vs Gzip: tabella di confronto

Brotli comprime sempre meglio di Gzip?

Non sempre, ma sui contenuti testuali può frequentemente ottenere file più piccoli.

Il risultato dipende da:

• tipo di file;
• dimensione;
• livello di compressione;
• contenuto;
• implementazione utilizzata;
• modalità statica o dinamica.

Un file HTML ripetitivo, un grande foglio CSS o un bundle JavaScript possono comprimersi molto bene.

Un file già compresso, invece, può beneficiare pochissimo.

La stessa RFC di Brotli descrive un formato progettato per ottenere un rapporto di compressione migliore rispetto a Gzip in numerosi scenari generici.

Quali file conviene comprimere

La compressione HTTP è particolarmente efficace sui contenuti testuali.

Tra i principali candidati troviamo:

• HTML;
• CSS;
• JavaScript;
• JSON;
• XML;
• SVG;
• file di testo;
• risposte API;
• manifest;
• alcuni font, a seconda del formato e della configurazione.

Questi contenuti contengono spesso pattern ripetitivi che gli algoritmi possono comprimere molto efficacemente.

Quali file non conviene comprimere di nuovo

Un errore comune consiste nell’attivare la compressione indiscriminatamente su qualsiasi tipo di file.

Immagini, audio, video e archivi sono spesso già compressi internamente.

Per esempio:

• JPEG;
• WebP;
• AVIF;
• MP4;
• MP3;
• ZIP;
• GZIP;
• 7z.

Applicare un’ulteriore compressione può produrre un risparmio minimo o nullo, consumando invece CPU sul server.

MDN raccomanda infatti di utilizzare la compressione principalmente sui contenuti che possono realmente beneficiarne, evitando quelli già compressi come immagini, audio e video.

Brotli e Gzip non comprimono le immagini come WebP e AVIF

È importante non confondere due concetti differenti.

Brotli e Gzip comprimono la risposta HTTP.

WebP e AVIF sono invece formati immagine progettati specificamente per comprimere contenuti grafici.

Una strategia corretta può quindi essere:

HTML → Brotli
CSS → Brotli
JavaScript → Brotli
JSON → Brotli

Immagini → WebP / AVIF

Per approfondire il tema delle immagini puoi leggere la guida Xlogic WebP vs AVIF nel 2026.

Compressione statica vs compressione dinamica

Esistono due strategie principali.

Compressione dinamica

Il server riceve la richiesta e comprime la risposta al momento.

Per esempio:

browser richiede style.css
↓
server legge style.css
↓
server comprime
↓
server invia style.css compresso

Il vantaggio è che non bisogna conservare copie compresse già pronte.

Lo svantaggio è che ogni operazione di compressione utilizza CPU.

Compressione statica

Il file viene compresso in anticipo.

Potremmo avere:

style.css
style.css.gz
style.css.br

Quando il browser supporta Brotli, il server può inviare direttamente:

style.css.br

senza doverlo comprimere durante la richiesta.

Questa tecnica permette di utilizzare livelli di compressione più elevati senza aumentare il carico CPU per ogni visitatore.

Perché Brotli 11 non è sempre la scelta migliore

Brotli supporta livelli di qualità da 0 a 11.

Aumentando il livello, normalmente aumenta la capacità di compressione ma anche il tempo necessario per generare il risultato.

Il problema diventa evidente con la compressione on-the-fly.

Utilizzare il livello massimo su contenuti dinamici può richiedere molta più CPU per ottenere un guadagno relativamente piccolo rispetto a un livello intermedio.

Per questo il principio corretto non è:

“Più alto è il livello, migliore è sempre la configurazione.”

Bisogna trovare un equilibrio tra:

• risparmio di banda;
• tempo di compressione;
• CPU;
• latenza;
• tipo di contenuto.

Livelli Gzip

Gzip, attraverso zlib, utilizza normalmente livelli di compressione compresi tra 0 e 9.

In termini generali:

1 = maggiore velocità
9 = maggiore compressione

Il livello 0 equivale sostanzialmente all’assenza di compressione.

Anche in questo caso il livello massimo non è necessariamente il migliore per contenuti generati dinamicamente.

Brotli vs Gzip e utilizzo della CPU

La compressione non è gratuita.

Ridurre il numero di byte trasferiti richiede calcoli.

Il server deve quindi bilanciare:

CPU utilizzata per comprimere

contro:

banda e tempo di trasferimento risparmiati.

Su contenuti statici molto richiesti è spesso conveniente creare versioni precompresse.

Su contenuti dinamici bisogna utilizzare livelli adeguati per evitare che il costo della compressione annulli il beneficio ottenuto sulla rete.

Brotli e LiteSpeed

LiteSpeed Web Server supporta sia Gzip sia Brotli per contenuti statici e dinamici.

La documentazione LiteSpeed indica che il web server può comprimere le risposte con entrambi i formati e permette di configurare separatamente regole e livelli di compressione.

Puoi consultare la documentazione ufficiale LiteSpeed sulla compressione.

LiteSpeed sottolinea inoltre che livelli di compressione più elevati riducono maggiormente il traffico, ma utilizzano più memoria e cicli CPU.

È quindi importante configurare la compressione in funzione delle caratteristiche del server e del traffico.

Xlogic e LiteSpeed Enterprise

Xlogic utilizza LiteSpeed Enterprise negli ambienti hosting compatibili.

Questo permette di integrare la compressione HTTP direttamente a livello web server insieme alle altre funzionalità dello stack.

Xlogic è inoltre presente nella directory ufficiale dei partner LiteSpeed Technologies.

Per approfondire puoi leggere l’articolo Xlogic partner ufficiale LiteSpeed Technologies.

Brotli vs Gzip e cache

Compressione e cache sono due ottimizzazioni differenti.

La cache riduce il lavoro necessario per generare il contenuto.

La compressione riduce invece la quantità di dati trasferiti.

Un sistema ben configurato può utilizzare entrambe:

pagina generata
↓
cache
↓
compressione Brotli
↓
browser

In questo modo il server evita di rigenerare continuamente la pagina e trasferisce anche una quantità inferiore di dati.

Content-Encoding e cache

Se una stessa risorsa può essere inviata in differenti formati compressi, i sistemi di cache devono distinguere correttamente le varianti.

Un client potrebbe supportare:

br

mentre un altro potrebbe accettare soltanto:

gzip

Per questo le risposte compresse possono utilizzare:

Vary: Accept-Encoding

Questo permette alle cache HTTP di conservare correttamente versioni differenti della stessa risorsa in base alle capacità del client.

Come verificare se un sito usa Brotli

Il metodo più semplice consiste nell’utilizzare gli strumenti di sviluppo del browser.

Su Chrome, Edge e browser simili:

1. apri il sito;
2. premi F12;
3. apri Network;
4. ricarica la pagina;
5. seleziona il documento HTML;
6. apri Response Headers.

Se Brotli è attivo dovresti vedere:

Content-Encoding: br

Se viene utilizzato Gzip:

Content-Encoding: gzip

Come verificare Brotli con curl

È possibile effettuare anche un controllo da terminale.

Per esempio:

curl -I -H "Accept-Encoding: br" https://example.com

Se il server supporta Brotli e decide di utilizzarlo, tra gli header dovrebbe comparire:

Content-Encoding: br

Per Gzip:

curl -I -H "Accept-Encoding: gzip" https://example.com

Perché curl -I può non raccontare tutta la storia

Alcune configurazioni possono trattare diversamente richieste HEAD e GET.

Per una verifica più completa si può utilizzare:

curl -s -o /dev/null -D - \
-H "Accept-Encoding: br" \
https://example.com

In questo modo curl effettua una normale richiesta GET ma scarta il corpo, mostrando gli header della risposta.

Brotli vs Gzip e CDN

Una CDN può gestire la compressione indipendentemente dal server origin.

Lo schema può essere:

Browser
↓
CDN
↓
Server origin

Il browser può ricevere Brotli dalla CDN anche se il server origin utilizza un altro tipo di compressione o invia contenuto non compresso.

Questo significa che quando si analizza la compressione bisogna capire quale componente sta effettivamente generando la risposta osservata.

Brotli funziona con HTTP/2?

Sì.

Brotli è un meccanismo di content encoding e non dipende direttamente dalla versione HTTP.

Può essere utilizzato con connessioni HTTP/2 e HTTP/3.

Quindi una configurazione moderna può essere:

HTTP/3
+
Brotli
+
WebP / AVIF
+
cache

Ogni tecnologia interviene su un livello differente.

Per approfondire il protocollo di trasporto puoi leggere la guida Xlogic dedicata a HTTP/3 e QUIC nel 2026.

Brotli rende automaticamente più veloce un sito?

Non necessariamente.

Ridurre il peso di HTML, CSS e JavaScript può diminuire il tempo di trasferimento.

Ma le prestazioni di un sito dipendono da molti altri fattori:

• tempo di risposta del server;
• PHP;
• database;
• cache;
• numero di richieste;
• JavaScript;
• CSS;
• font;
• immagini;
• rete;
• latency;
• CPU e RAM.

Un HTML compresso perfettamente non può compensare un database che impiega tre secondi per elaborare una query.

Brotli vs Gzip e Core Web Vitals

La compressione può contribuire indirettamente alle performance percepite perché permette di trasferire più rapidamente le risorse testuali.

Questo può risultare utile soprattutto per:

• CSS critico;
• JavaScript;
• documento HTML;
• grandi file JSON;
• risorse utilizzate durante il rendering iniziale.

Non bisogna però aspettarsi che l’attivazione di Brotli risolva automaticamente problemi di LCP, INP o CLS.

Core Web Vitals dipende dall’intero processo di caricamento e rendering.

Quando scegliere Brotli

Brotli è particolarmente interessante quando:

• il sito utilizza browser moderni;
• sono presenti grandi file CSS o JavaScript;
• si vogliono ridurre i dati trasferiti;
• il server supporta Brotli nativamente;
• è disponibile una cache delle versioni compresse;
• si possono precomprimere gli asset statici.

Quando mantenere Gzip

Gzip rimane importante come fallback.

È utile quando:

• il client non supporta Brotli;
• la configurazione server non include Brotli;
• si utilizzano software legacy;
• si privilegia la semplicità operativa;
• la differenza di compressione non giustifica maggiore complessità.

Non esiste quindi una ragione per disabilitare Gzip soltanto perché Brotli è disponibile.

La strategia migliore: Brotli + Gzip fallback

Nel 2026 una strategia moderna può consistere nel supportare entrambi.

Il browser comunica:

Accept-Encoding: gzip, br

Il server può preferire:

br

e utilizzare Gzip quando Brotli non è disponibile.

La negoziazione avviene automaticamente senza richiedere modifiche da parte dell’utente.

E Zstandard?

Nel panorama moderno della compressione HTTP sta crescendo anche Zstandard, identificato come:

zstd

Browser moderni possono includerlo nell’header Accept-Encoding.

Questo non significa che Brotli e Gzip siano destinati a scomparire a breve.

Significa piuttosto che la compressione HTTP continua a evolversi e i server moderni possono progressivamente supportare più algoritmi.

La logica rimane la stessa: client e server negoziano automaticamente un formato compatibile.

Errori da evitare con la compressione HTTP

Tra gli errori più comuni troviamo:

• comprimere immagini già compresse;
• utilizzare sempre il livello massimo;
• ignorare l’utilizzo CPU;
• non configurare correttamente i MIME type;
• comprimere file minuscoli con risparmio irrilevante;
• non verificare Content-Encoding;
• non gestire correttamente Vary: Accept-Encoding;
• pensare che Brotli sostituisca la cache;
• confondere Brotli con WebP o AVIF;
• attivare più sistemi di compressione sovrapposti senza controllare il risultato.

Brotli vs Gzip su un hosting condiviso

Su un hosting condiviso la compressione viene normalmente gestita dal web server e dall’infrastruttura del provider.

L’utente non dovrebbe essere costretto a compilare manualmente Brotli o modificare il web server.

Quando la piattaforma supporta correttamente la compressione, browser e server possono negoziare automaticamente il formato migliore.

Per questo la presenza di un web server moderno rappresenta un elemento importante nella valutazione di un servizio hosting.

I piani Hosting Condiviso Xlogic utilizzano LiteSpeed Enterprise nei servizi in cui questa tecnologia è indicata tra le caratteristiche del piano.

Brotli vs Gzip: quale scegliere nel 2026?

Nel confronto Brotli vs Gzip non è necessario scegliere esclusivamente uno dei due.

La configurazione migliore è normalmente:

Brotli quando supportato + Gzip come fallback.

Brotli permette spesso di ridurre maggiormente il peso dei contenuti testuali.

Gzip rimane estremamente compatibile, veloce e affidabile.

Entrambi continuano quindi ad avere un ruolo importante.

Checklist compressione HTTP nel 2026

1. Abilita la compressione sui contenuti testuali.
2. Supporta Brotli quando disponibile.
3. Mantieni Gzip come fallback.
4. Non comprimere nuovamente immagini e video già compressi.
5. Controlla i MIME type compressibili.
6. Evita livelli eccessivi sui contenuti dinamici.
7. Valuta la precompressione degli asset statici.
8. Verifica Content-Encoding con DevTools.
9. Controlla Vary: Accept-Encoding.
10. Misura CPU e tempi reali.
11. Combina compressione e cache.
12. Utilizza WebP o AVIF per le immagini.
13. Verifica la configurazione anche attraverso CDN o proxy.

Conclusioni

Brotli vs Gzip nel 2026 non è una battaglia in cui uno dei due deve necessariamente eliminare l’altro.

Brotli rappresenta un’evoluzione importante della compressione HTTP e può ottenere risultati particolarmente efficienti sui contenuti testuali.

Gzip rimane però estremamente diffuso, rapido e compatibile.

La strategia più efficace consiste quindi nel permettere al server di scegliere automaticamente il formato migliore in base alle capacità del client.

In pratica:

Browser supporta Brotli
→ Content-Encoding: br

Browser non supporta Brotli
→ Content-Encoding: gzip

È inoltre importante ricordare che la compressione non deve essere analizzata isolatamente.

Un sito veloce nasce dalla combinazione di:

hosting performante + cache + compressione + HTTP/3 + PHP ottimizzato + database efficiente + immagini WebP/AVIF + frontend leggero.

Brotli permette di trasferire meno dati, ma è l’intero stack che determina la velocità reale di un sito.

Domande frequenti su Brotli vs Gzip

È meglio Brotli o Gzip?

Brotli può ottenere una compressione migliore su molti contenuti testuali, mentre Gzip offre un’eccellente compatibilità e velocità di compressione. Nel 2026 è generalmente utile supportare entrambi.

Brotli sostituisce Gzip?

No. Brotli può essere utilizzato come formato preferenziale e Gzip come fallback per client o configurazioni che non supportano Brotli.

Come faccio a sapere se il mio sito usa Brotli?

Apri gli strumenti di sviluppo del browser, seleziona una richiesta nella scheda Network e controlla l’header Response Headers. Se trovi Content-Encoding: br, la risposta utilizza Brotli.

Quali file devo comprimere con Brotli?

Principalmente HTML, CSS, JavaScript, JSON, XML, SVG e altri contenuti testuali che possono beneficiare significativamente della compressione.

Devo comprimere JPEG, WebP e AVIF con Brotli?

Generalmente no. Questi formati sono già compressi e un’ulteriore compressione HTTP può produrre pochissimi benefici consumando risorse del server.

Brotli utilizza più CPU di Gzip?

Può utilizzarne di più, soprattutto ai livelli di compressione elevati. Per questo la configurazione deve bilanciare rapporto di compressione e costo computazionale.

Qual è il livello massimo di Brotli?

Le implementazioni standard di Brotli utilizzano livelli di qualità compresi tra 0 e 11. I livelli più elevati comprimono generalmente meglio ma richiedono più tempo.

Qual è il livello massimo di Gzip?

Le implementazioni basate su zlib utilizzano normalmente livelli da 0 a 9, dove 1 privilegia la velocità e 9 privilegia la compressione.

Brotli funziona con HTTP/3?

Sì. Brotli è un content encoding e può essere utilizzato indipendentemente dal fatto che il trasporto avvenga tramite HTTP/2 o HTTP/3.

LiteSpeed supporta Brotli?

Sì. LiteSpeed Web Server supporta risposte compresse con Gzip o Brotli sia per contenuti statici sia per contenuti dinamici, in base alla configurazione.

Zstandard sostituirà Brotli?

Zstandard è sempre più presente nel supporto HTTP moderno, ma Brotli e Gzip rimangono ampiamente utilizzati. I diversi algoritmi possono convivere attraverso la negoziazione Accept-Encoding.