Come utilizzare Brotli e Gzip per ottimizzare streaming e download

Se desideri che il tuo sito web, le API, i download e lo streaming siano velocissimi anche con connessioni mobili lente, uno dei trucchi più efficaci (e sottovalutati) è la compressione HTTP. Se utilizzata correttamente, la combinazione di Brotli e Gzip riduce drasticamente le dimensioni delle risposte senza perdere nemmeno un bit di informazione. Questo si traduce in un minore consumo di banda, server meno sovraccarichi e utenti che percepiscono un caricamento istantaneo.

Nelle righe seguenti, analizzeremo il funzionamento di Gzip e Brotli, le loro differenze, come scegliere i livelli di compressione più appropriati, come abilitarli in Apache, Nginx, LiteSpeed, Cloudflare, WordPress e nelle API REST , e come verificare che tutto sia configurato correttamente. L'obiettivo è fornirvi una guida completa per sfruttare al meglio il potenziale di entrambe le tecnologie per siti web tradizionali, servizi di streaming e piattaforme di download.

Cosa sono Gzip e Brotli e perché sono così importanti?

Gzip è il veterano della famiglia: un formato di compressione basato sull'algoritmo DEFLATE , che a sua volta combina la codifica LZ77 e Huffman. Ha contribuito ad accelerare il web sin dai primi anni '90 e oggi gode di un supporto pressoché universale da parte di tutti i tipi di browser, server e client HTTP.

Brotli , creato da Google, si basa su idee simili (LZ77 + Huffman), ma introduce miglioramenti fondamentali, come l'utilizzo di dizionari statici e dinamici altamente ottimizzati per i contenuti web (HTML, CSS, JS, JSON, ecc.). Di conseguenza, raggiunge in genere rapporti di compressione dal 20% al 30% migliori rispetto a Gzip per molti file di testo.

In pratica, entrambi gli algoritmi vengono utilizzati in modo che il server prelevi le risorse testuali (HTML, CSS, JavaScript, JSON dalle API, XML, font, ecc.), le comprima e le invii al browser o al client. Il browser o il client, in modo trasparente per l'utente, decomprime la risposta e la elabora normalmente. L'utente si accorge solo che tutto si carica più velocemente e consuma meno dati.

Un dettaglio importante: mentre Gzip può essere utilizzato sia con HTTP che con HTTPS, la compressione Brotli sul web viene di fatto utilizzata su HTTPS . La buona notizia è che oggigiorno praticamente qualsiasi progetto di una certa importanza utilizza già SSL/TLS, quindi di solito non rappresenta un problema.

Brotli contro Gzip: differenze di prestazioni reali

Quando si confronta Brotli con Gzip, la prima cosa che si guarda è solitamente il tasso di compressione . Test pubblici dimostrano che, per HTML, CSS, JS o JSON, Brotli può ridurre le dimensioni del file di diversi kilobyte rispetto a Gzip nelle stesse condizioni. Ad esempio, per un file HTML non compresso di circa 418 kB, sono stati misurati risultati come questi:

• Livello Gzip 9: file finale di circa 78,7 kB.
• Brotli livello 11: file finale di circa 57,2 kB.

La differenza sembra spettacolare, ma c'è un problema: i livelli massimi di compressione di Brotli (10-11) richiedono più CPU e tempi di compressione più lunghi , il che non sempre si traduce in un vantaggio, soprattutto per i contenuti dinamici generati al volo.

Se bilanciamo meglio le cose, ad esempio confrontando Gzip livello 9 con Brotli livello 3 , lo stesso HTML di 418 kB può essere ridotto a:

• Gzip livello 9: 78,7 kB.
• Brotli livello 3: 76,5 kB.

In quella situazione, le dimensioni sono praticamente le stesse, ma Brotli al livello 3 comprime e decomprime molto più velocemente e con un minore consumo di risorse rispetto a Gzip al livello 9. Pertanto, si consiglia di utilizzare livelli intermedi di Brotli (tra 3 e 6) per i contenuti dinamici e di riservare i livelli più alti alla pre-compressione dei contenuti statici (CSS, JS, font, ecc.).

I benchmark indipendenti mostrano solitamente un andamento simile: Brotli vince quasi sempre in termini di rapporto di compressione , mentre Gzip è leggermente più veloce in alcuni scenari, soprattutto quando si utilizzano livelli di compressione bassi e quando si tratta di comprimere molte piccole risorse in tempo reale.

Per le API, lo streaming di testo o i download di file JSON di grandi dimensioni, la chiave è la misurazione: a volte ridurre le dimensioni della risposta di un ulteriore 15-20% vale la pena del costo aggiuntivo della CPU, soprattutto se si dispone di un'infrastruttura ben dimensionata o se si utilizza una CDN con compressione edge.

Come avviene la negoziazione tra client e server: Accept-Encoding e Content-Encoding

La compressione HTTP, sia sui siti web, sia sulle API REST o sui servizi di streaming dati, si basa su una negoziazione tramite intestazioni. Il client dichiara nell'intestazione quali algoritmi è in grado di comprendere. Accetta-codifica (per esempio gzip, br) e il server risponde indicando cosa ha applicato nell'intestazione Codifica del contenuto.

Un tipico flusso API potrebbe essere strutturato in questo modo: il client invia `Accept-Encoding: gzip, br` , il server rileva di poter utilizzare Brotli e restituisce `Content-Encoding: br` . Se il client supporta solo Gzip, utilizza `Content-Encoding: gzip` . In assenza di un algoritmo comune, il server potrebbe rispondere con un errore 406 Not Acceptable , sebbene sia più comune inviare semplicemente la risposta non compressa.

Quando più algoritmi vengono concatenati (un caso più raro, ma consentito dalla specifica), l' intestazione Content-Encoding elenca i metodi in ordine, in modo che il client possa decomprimere in ordine inverso. Inoltre, per le cache intermedie come proxy o CDN, è essenziale inviare Vary: Accept-Encoding in modo che memorizzino sia la versione compressa che quella non compressa della stessa risorsa.

Sui dispositivi con risorse limitate (telefoni cellulari più vecchi, dispositivi IoT, ecc.), tieni presente che anche la decompressione consuma CPU e memoria. Questo non è un problema nella maggior parte dei browser moderni, ma se stai sviluppando un client personalizzato, è consigliabile impostare delle soglie minime di dimensione (non ha senso comprimere una risposta JSON di 200 byte) e scegliere attentamente quali algoritmi supportare.

Architettura interna di Brotli: dizionari e finestra scorrevole

Uno dei motivi per cui Brotli produce file più piccoli di Gzip è l'uso intensivo di dizionari di dati . Ne impiega due tipi: un dizionario statico e un dizionario dinamico (a finestra scorrevole), che lavorano insieme per trovare schemi ricorrenti e codificarli in modo molto efficiente.

Il dizionario statico include oltre 13.000 parole e frammenti comuni presenti in HTML, CSS, JavaScript e testo generico, in diverse lingue. Grazie a questo dizionario, Brotli non ha bisogno di analizzare l'intero flusso byte per byte; può invece fare affidamento su riferimenti familiari, proprio come un sistema di template che fa riferimento a un blocco di codice riutilizzabile.

All'interno di quel dizionario ci sono anche frasi parziali e trasformazioni: pezzi che con un prefisso o un suffisso possono formare nuove parole. Ciò consente di risparmiare spazio non solo nelle parole complete, ma anche nelle combinazioni tipiche come i tag HTML (<html>, type="text/javascript", Ecc.).

Il dizionario dinamico (la cosiddetta "finestra scorrevole") analizza i dati recenti del flusso, memorizzandoli in una sorta di cache che l'algoritmo può riutilizzare. In Brotli, questa finestra può raggiungere fino a 16 MB , molto più grande dei tipici ~32 KB di Gzip, il che offre una grande flessibilità per individuare modelli in file di grandi dimensioni o flussi di dati estesi.

Questa combinazione permette a Brotli di dare il meglio di sé soprattutto con risorse statiche di grandi dimensioni (CSS, JavaScript concatenato, bundle moderni, JSON voluminosi per SPA, ecc.) e con contenuti HTML caratterizzati da numerose ripetizioni di struttura.

Compatibilità di Brotli e Gzip con browser, server e CDN.

Dal punto di vista del client, la situazione è molto favorevole: secondo raccolte come Can I Use , oltre il 95% dei browser in uso supporta già Brotli, inclusi praticamente tutti i browser basati su Chromium, Firefox e i principali browser per dispositivi mobili. Gzip, nel frattempo, è supportato universalmente da molti anni.

Sul lato server, il panorama è un po' più variegato. Gzip è disponibile di serie in quasi tutti gli stack (Apache, Nginx, IIS, ecc.), mentre Brotli a volte richiede moduli o build specifici.

• ApacheÈ necessario almeno Apache 2.4 con mod_brotli installato e abilitato.
• Nginx: Di solito viene attivato dalle versioni recenti (1.18+), spesso tramite il modulo ngx_brotli, sia che venga compilato in formato binario o come modulo dinamico.
• Server Web LiteSpeed: porta Brotli abilitato di default Per anni, senza bisogno di modifiche manuali.
• CDN Servizi come Cloudflare, KeyCDN, CDN77, Amazon CloudFront, ecc., offrono supporto nativo per Brotli o tramite opzioni di configurazione molto semplici.

Molti provider di hosting condiviso utilizzano ancora Apache senza mod_brotli o Nginx senza il modulo corrispondente, quindi prima di iniziare a modificare le configurazioni, è consigliabile verificare con il proprio provider quali opzioni sono disponibili e quali no. In alcuni casi, abilitare Brotli sarà semplice come spuntare una casella nel pannello di controllo o nella console CDN.

Abilitare Gzip sui server web (Apache e Nginx)

Gzip rimane essenziale, non solo per la compatibilità con browser e client meno recenti, ma anche come soluzione di ripiego quando Brotli non è disponibile lungo l'intera catena (server di origine, CDN, proxy, ecc.). Abilitarlo è solitamente molto semplice.

En ApacheLa prassi usuale è quella di utilizzare il modulo mod_deflate e dichiara i tipi MIME che desideri comprimere. Un esempio tipico in .htaccess voluto:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
  AddOutputFilterByType DEFLATE text/javascript application/javascript
  AddOutputFilterByType DEFLATE application/json application/xml
  AddOutputFilterByType DEFLATE image/svg+xml image/x-icon
  AddOutputFilterByType DEFLATE font/ttf font/otf font/woff font/woff2
</IfModule>

En NginxViene attivato con alcune direttive all'interno del blocco http del nginx.conf:

gzip on;
gzip_comp_level 2;
gzip_min_length 1100;
gzip_types text/plain text/html text/css text/xml
           application/json application/javascript text/javascript
           application/xml application/xml+rss image/svg+xml;
gzip_vary on;

Da quel momento in poi, qualsiasi browser che invii `Accept-Encoding: gzip` riceverà il contenuto compresso, mentre il resto verrà ricevuto in testo semplice. È importante non forzare la compressione su file già compressi (JPEG, PNG, MP4, ZIP, PDF, ecc.), perché il vantaggio è solitamente minimo e si incorre in un inutile consumo di CPU.

Abilita Brotli in Apache, Nginx e LiteSpeed

Per utilizzare Brotli sul tuo server, il tuo software deve supportare mod_brotli o moduli equivalenti . Una volta verificato, è sufficiente abilitarlo e selezionare i tipi di file che si desidera comprimere.

En Apache2.4+ con mod_brotli Una volta installato, un blocco tipico sarebbe:

<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css
  AddOutputFilterByType BROTLI_COMPRESS text/javascript application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json application/xml
  AddOutputFilterByType BROTLI_COMPRESS application/x-font-ttf
  AddOutputFilterByType BROTLI_COMPRESS application/vnd.ms-fontobject
  AddOutputFilterByType BROTLI_COMPRESS image/x-icon
</IfModule>

En Nginx con ngx_brotliDi solito una cosa del genere è sufficiente nginx.conf:

brotli on;
brotli_comp_level 4;  # niveles 3-6 son buena opción general
brotli_static on;      # sirve .br precomprimidos si existen
brotli_types text/plain text/css application/json application/javascript
             text/xml application/xml application/xml+rss text/javascript
             image/svg+xml;

In ambienti in cui le risorse sono precompresse (ad esempio, durante una pipeline CI/CD che genera .br y .gz), brotli_static on Questo comando indica a Nginx di servire direttamente quei file, invece di comprimerli ogni volta al volo, con un notevole risparmio di risorse della CPU.

La buona notizia riguardo a LiteSpeed ​​Web Server è che Brotli è abilitato di default nelle tipiche installazioni cPanel e in molti piani di hosting gestito. In questo caso, non è praticamente necessario fare nulla: il server deciderà automaticamente quando utilizzare Brotli o Gzip in base all'utilizzo del client.

Utilizzo di Brotli e Gzip nelle CDN e nelle reti di distribuzione dei contenuti

Se utilizzi una CDN moderna , probabilmente hai già accesso alla compressione Brotli senza troppi problemi. Cloudflare, ad esempio, è stata una delle prime a supportarla e ora la utilizza su tutta la sua infrastruttura, con un'implementazione altamente ottimizzata.

Per anni, Cloudflare si è limitata a richiedere i file compressi con Gzip dall'origine, decomprimerli e ricomprimerli utilizzando Brotli di livello 4 o Gzip di livello 8 prima di restituirli all'utente. Ora, grazie al supporto end-to-end di Brotli , Cloudflare può richiedere direttamente i contenuti Brotli dall'origine (fino al livello 11, se configurato) e memorizzarli nella cache così come sono, senza ricompressione. Ciò si traduce in una latenza inferiore e un minore consumo di banda tra l'origine e l'edge.

Se il tuo codice sorgente supporta Brotli, puoi configurare qualcosa del genere con Nginx, ad esempio:

brotli on;
brotli_comp_level 11;
brotli_static on;
brotli_types text/plain text/css application/javascript application/x-javascript
             text/xml application/xml application/xml+rss text/javascript
             image/x-icon image/vnd.microsoft.icon image/bmp image/svg+xml;

Con questa configurazione, le risorse corrispondenti verranno consegnate a Cloudflare in formato altamente compresso, che potrà quindi distribuirle direttamente agli utenti compatibili. Per i browser che non supportano Brotli, la CDN si occuperà della decompressione e dell'inoltro in formato Gzip o non compresso, a seconda dei casi.

Anche altre CDN come KeyCDN, CDN77 e Amazon CloudFront offrono Brotli. In alcuni casi, è sufficiente selezionare un'opzione nel pannello; in altri, è necessario regolare impostazioni come Accept-Encoding o disabilitare la compressione automatica della CDN per evitare interferenze con la compressione del file sorgente.

Come integrare Brotli e Gzip in WordPress e altri CMS

In WordPress, l'attivazione della compressione non dipende dal CMS stesso , bensì dal server web (Apache, Nginx, LiteSpeed, ecc.) o dalla CDN utilizzata. I plugin possono modificare le impostazioni del server solo se quest'ultimo lo consente.

Molti plugin di caching come W3 Total Cache, WP Rocket o LiteSpeed ​​Cache Offrono opzioni per abilitare Gzip e talvolta Brotli. In Apache, ciò che effettivamente fanno è scrivere o modificare le regole di .htaccess attivare mod_deflate o mod_brotliSe il modulo non è installato sul server, il plugin non sarà in grado di funzionare correttamente.

In Nginx, poiché non c'è .htaccessQuesti plugin non possono influire direttamente sulla compressione. Dovrai modificare i file di configurazione (oppure chiedi al tuo fornitore di farlo) per aggiungere le direttive gzip y brotli corrispondente, quindi ricarica Nginx.

Alcuni provider di hosting gestito (ad esempio, alcuni basati sull'integrazione con Cloudflare) attivano automaticamente Brotli per tutti i siti senza richiedere plugin. In questi casi, aggiungere un ulteriore plugin di compressione è solitamente superfluo e persino controproducente, in quanto può causare una doppia compressione o conflitti con il reverse proxy.

Compressione Brotli e Gzip nelle API REST, nello streaming e nei download

Oltre ai siti web tradizionali, Brotli e Gzip sono essenziali per le API REST, i servizi di streaming dati e il download di file . In questi contesti, la riduzione delle dimensioni del payload ha un impatto diretto sulla latenza, sui costi di banda e sull'esperienza utente.

In un'API, è prassi comune comprimere i formati di testo come application/json, application/xml, text/html e simili, lasciando non compressi i formati ottimizzati (immagini, video, file ZIP, ecc.). Il server controlla l' intestazione Accept-Encoding del client e decide se inviare la risposta in formato Brotli, Gzip o senza compressione.

Nei servizi di streaming di testo (ad esempio, SSE o WebSockets con messaggi JSON, log in tempo reale, ecc.), la compressione deve essere gestita con maggiore attenzione. Comprimere blocchi molto piccoli uno alla volta può far sì che il sovraccarico superi il beneficio. Generalmente, vengono configurate delle soglie di dimensione per determinare quando applicare la compressione.

Per i download HTTP di file di grandi dimensioni, l'approccio è diverso. Se il file è già un ZIP, un .tar.gz o un video , l'aggiunta di Gzip/Brotli non offre praticamente alcun vantaggio. Tuttavia, se si distribuiscono pacchetti di grandi dimensioni in formato JSON, XML o CSV, la compressione con Brotli o Gzip può comportare enormi riduzioni di dimensioni e tempi di trasferimento significativamente più brevi per gli utenti.

Cosa comprimere e cosa non comprimere

Una delle migliori pratiche fondamentali è quella di avere ben chiaro quali tipi di contenuto vale la pena comprimere e quali no. Come regola generale, è consigliabile abilitare Brotli e Gzip per:

• HTML e modelli renderizzati dal server (text/html).
• CSS e JavaScript (text/css, application/javascript, Ecc.).
• API JSON e XML (application/json, application/xml).
• Font web (TTF, OTF, WOFF, WOFF2) se il server lo consente.
• SVG (image/svg+xml), che sebbene sia un'immagine, è in realtà testo.

Al contrario, è consigliabile escludere dalla compressione i seguenti elementi:

• Immagini come JPEG, PNG, WebP, AVIF, GIF.
• Video (MP4, WebM, ecc.).
• File ZIP, RAR, 7z, .tar.gz e simili.
• I file PDF e altri formati binari sono già altamente ottimizzati.

È inoltre consigliabile definire una dimensione minima di risposta (ad esempio, 1 o 2 KB) per evitare di comprimere messaggi di piccole dimensioni laddove non vi sia alcun vantaggio. Ciò consente di risparmiare risorse della CPU e di evitare di aggiungere latenza ai contenuti per i quali la compressione non apporta alcun valore.

Come verificare se Gzip o Brotli sono attivi

Una volta configurata la compressione, è necessario verificare che venga effettivamente applicata e che le intestazioni si comportino come previsto. Esistono diversi modi per farlo, dagli strumenti online alle utilità da riga di comando o agli Strumenti per sviluppatori del browser.

Servizi come Gift of Speed, il test Brotli di KeyCDN o gli strumenti di Paul Calvano consentono di inserire un URL e verificare se la risposta arriva compressa con Gzip, Brotli o senza compressione, nonché le dimensioni prima e dopo.

Nel tuo browser, apri semplicemente gli Strumenti per sviluppatori (Rete), ricarica la pagina e seleziona una risorsa (ad esempio, il codice HTML principale). Nel pannello delle intestazioni, vedrai qualcosa di simile a questo:

• codifica del contenuto: br se si utilizza Brotli.
• codifica del contenuto: gzip se si utilizza Gzip.
• Assenza di codifica dei contenuti se arriva non compresso.

Puoi anche ricorrere a arricciare dalla console, forzando un Accept-Encoding Nello specifico, e rivedendo la risposta:

curl -H "Accept-Encoding: br" -I https://tu-dominio.com
curl -H "Accept-Encoding: gzip" -I https://tu-dominio.com

Se nella risposta visualizzi `Content-Encoding: br` o `Content-Encoding: gzip`, significa che tutto funziona correttamente. Approfitta inoltre dell'occasione per verificare che venga inviato `Vary: Accept-Encoding` , elemento essenziale per le cache e le CDN.

Impatto su prestazioni, CPU e sicurezza

L'attivazione di Brotli e Gzip è una delle ottimizzazioni più convenienti per le prestazioni di siti web e API, ma non bisogna dimenticare le sue implicazioni in termini di risorse e sicurezza.

Sul fronte delle prestazioni, la compressione riduce drasticamente le dimensioni dei file, con conseguente riduzione dei tempi di download, miglioramento di parametri come First Contentful Paint e Time to First Byte percepito, e una diminuzione diretta del consumo di banda (un aspetto che si riflette positivamente sulla fattura di provider come AWS).

Il costo risiede nella CPU e nella memoria necessarie per la compressione e la decompressione. Brotli, soprattutto ai livelli più elevati, è più esigente di Gzip. Pertanto, per i contenuti dinamici, è meglio utilizzare livelli intermedi (3-5) e riservare i livelli estremi alla pre-compressione di contenuti statici o a scenari molto specifici.

In ambito di sicurezza, la compressione può essere influenzata da attacchi teorici come BREACH , che sfruttano le variazioni nelle dimensioni delle risposte compresse per tentare di dedurre dati sensibili. Sebbene si tratti di scenari piuttosto specifici, è una buona idea:

• Evitare la compressione risposte altamente sensibili che mescolano segreti con dati controllati dall'utente.
• Separare i token e le credenziali da qualsiasi input fornito dal client.
• Applicare misure classiche come Token CSRF, limitazione della velocità e il monitoraggio di schemi sospetti.

Con una configurazione adeguata, Brotli e Gzip diventano alleati fondamentali per accelerare siti web, API e servizi di streaming e download senza compromettere la sicurezza.

L'intero ecosistema di compressione, da Gzip, che rimane lo standard di fatto, a Brotli, che massimizza la riduzione delle dimensioni con dizionari avanzati e finestre di analisi molto più ampie, offre un'enorme flessibilità per ottimizzare il modo in cui i dati viaggiano attraverso la rete. Combinando entrambi gli algoritmi con livelli di compressione ragionevoli, scegliendo attentamente quali tipi di contenuto comprimere, affidandosi a CDN che supportano Brotli end-to-end e verificando sempre le intestazioni e il loro reale impatto sulle metriche di performance, è possibile rendere il sito web, le API, i flussi e i download molto più leggeri e agili senza modificare una singola riga di logica di business.