Cosa sono la compressione Gzip e Brotli?

Gzip e Brotli sono algoritmi di compressione che il tuo web server usa per ridurre i file prima di inviarli al browser del visitatore. L'idea è semplice: file basati su testo come HTML, CSS e JavaScript contengono molti pattern ripetitivi, e gli algoritmi di compressione sono molto bravi a trovare ed eliminare quella ridondanza. Un file HTML di 100 KB può essere compresso a 15-20 KB. Il browser lo decomprime immediatamente, e il visitatore non nota nulla, tranne che la pagina si carica più velocemente.

Se hai mai zippato una cartella sul tuo computer, conosci già il concetto di base. La compressione web funziona allo stesso modo, ma automaticamente e in modo trasparente. Il server comprime la risposta, il browser la decomprime, e né lo sviluppatore né il visitatore devono fare nulla di speciale (purché il server sia configurato correttamente).

Come funziona la compressione web a livello di protocollo

Ogni volta che un browser invia una richiesta HTTP, include un header Accept-Encoding che dice al server quali algoritmi di compressione supporta:

Accept-Encoding: gzip, deflate, br

Questo header dice che il browser può gestire Gzip, Deflate e Brotli (abbreviato come br). Il server sceglie il miglior algoritmo che supporta, comprime il corpo della risposta e aggiunge un header Content-Encoding per dire al browser quale algoritmo è stato usato:

Content-Encoding: gzip

oppure:

Content-Encoding: br

Il browser legge questo header, applica l'algoritmo di decompressione corrispondente e renderizza il contenuto. Se il server non supporta la compressione (o non è configurato), invia la risposta non compressa, e nessun header Content-Encoding è presente.

Questa negoziazione avviene a ogni singola richiesta. Il server può scegliere metodi di compressione diversi per diversi tipi di file, o anche servire contenuto non compresso per file che non beneficiano della compressione.

Gzip: lo standard consolidato

Gzip è il cavallo di battaglia della compressione web dalla fine degli anni '90. Si basa sull'algoritmo DEFLATE (una combinazione di LZ77 e codifica Huffman) ed è supportato letteralmente da ogni browser e web server in uso. Quando le persone parlano di "abilitare la compressione" su un web server, di solito intendono Gzip.

Gzip funziona con livelli di compressione regolabili, tipicamente da 1 (più veloce, minima compressione) a 9 (più lento, miglior compressione). La maggior parte dei web server è impostata di default sul livello 6, che offre un buon equilibrio tra rapporto di compressione e uso CPU. Al livello 6, Gzip raggiunge tipicamente il 70-85% di compressione su file basati su testo. Un file CSS di 100 KB diventa quindi circa 15-30 KB.

I principali vantaggi di Gzip sono l'universalità (funziona ovunque), la velocità a livelli di compressione moderati e i decenni di ottimizzazione che sono stati investiti nelle implementazioni. Il principale svantaggio è che non comprime altrettanto bene quanto Brotli, soprattutto per file più piccoli.

Brotli: l'alternativa moderna

Brotli è stato sviluppato da Google e pubblicato come RFC 7932 nel 2016. È specificamente progettato per contenuti web e raggiunge rapporti di compressione del 15-25% migliori rispetto a Gzip su asset web tipici. Brotli ottiene questo usando un algoritmo di compressione più avanzato e includendo un dizionario integrato con stringhe comuni nei contenuti web (tag HTML, proprietà CSS, parole chiave JavaScript, ecc.).

Brotli usa anche livelli di compressione regolabili, da 0 a 11. A livelli di qualità comparabili, Brotli produce output più piccoli di Gzip, ma ai livelli più alti (10-11), Brotli è significativamente più lento nella compressione. Brotli con compressione alta è quindi ideale per asset statici che possono essere precompressi una volta e poi serviti molte volte, e meno adatto per contenuti dinamici che devono essere compressi a ogni richiesta.

Una limitazione importante: Brotli funziona solo su HTTPS. I browser non accettano risposte compresse con Brotli su connessioni HTTP semplici. Poiché la maggior parte dei siti WordPress dovrebbe comunque girare su HTTPS (e HTTP/2 lo richiede), questo è raramente un problema pratico.

Gzip versus Brotli: un confronto pratico

Ecco come i due algoritmi si confrontano sulle metriche che contano per i proprietari di siti WordPress:

• Rapporto di compressione: Brotli produce tipicamente file il 15-25% più piccoli di Gzip a livelli di compressione comparabili. Su un sito WordPress che carica 500 KB di asset comprimibili, quella differenza si traduce in circa 15-30 KB in meno di traffico dati per caricamento di pagina.
• Velocità di compressione: Gzip al livello 6 è più veloce di Brotli a un'impostazione di qualità equivalente. Per contenuti dinamici (pagine HTML generate da PHP), Gzip è spesso la scelta più pratica, perché la compressione avviene a ogni richiesta. Brotli ai livelli 1-4 è comparabile a Gzip in velocità e comprime ancora un po' meglio.
• Velocità di decompressione: Brotli decomprime un po' più velocemente di Gzip, consentendo al browser di elaborare il contenuto marginalmente più velocemente. La differenza è piccola, ma coerente.
• Supporto del browser: tutti i browser moderni supportano sia Gzip che Brotli. Internet Explorer (ormai in disuso) non supportava Brotli, ma Edge, Chrome, Firefox e Safari sì. Il supporto globale dei browser per Brotli è superiore al 96%.
• Supporto del server: Apache supporta Brotli tramite mod_brotli (disponibile dalla versione Apache 2.4.26). Nginx lo supporta tramite il modulo ngx_brotli (un modulo esterno che deve essere compilato separatamente). LiteSpeed ha supporto Brotli integrato. La maggior parte dei provider di hosting gestiti e CDN supportano entrambi.
• Requisito HTTPS: Brotli richiede HTTPS. Gzip funziona sia su HTTP che HTTPS.

In pratica, molti server sono configurati per preferire Brotli quando il browser lo supporta e altrimenti ricadere su Gzip. Così ottieni la migliore compressione per i browser moderni e mantieni la compatibilità con client più vecchi.

Abilitare la compressione in Apache

Per Apache, abiliti la compressione Gzip tramite mod_deflate (nominato in modo confuso, ma usa Gzip, non Deflate grezzo). Aggiungi quanto segue al tuo .htaccess:

  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE application/font-woff2

Per Brotli su Apache, hai bisogno di mod_brotli:

  AddOutputFilterByType BROTLI_COMPRESS text/html
  AddOutputFilterByType BROTLI_COMPRESS text/css
  AddOutputFilterByType BROTLI_COMPRESS text/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json

Abilitare la compressione in Nginx

Per Nginx, Gzip è integrato e deve solo essere attivato nella configurazione:

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Per Brotli su Nginx, dopo l'installazione del modulo ngx_brotli:

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Plugin di caching WordPress e compressione

Se non hai accesso alla configurazione del tuo server (comune sull'hosting condiviso), diversi plugin di caching WordPress possono gestire la compressione per te:

• WP Rocket: abilita automaticamente la compressione Gzip aggiungendo regole al tuo .htaccess. Crea anche file di cache HTML statici precompressi.
• W3 Total Cache: offre la compressione Gzip come opzione configurabile nelle impostazioni Browser Cache. Può anche servire file precompressi.
• LiteSpeed Cache: se il tuo host gira su un server LiteSpeed, questo plugin abilita automaticamente sia la compressione Gzip che Brotli.
• WP Super Cache: include un'opzione di compressione Gzip che comprime le pagine in cache.
• Autoptimize: sebbene principalmente un plugin di ottimizzazione CSS/JS, può anche servire versioni compresse dei file generati.

Tieni presente che se il tuo server già gestisce la compressione a livello di server, riabilitarla tramite un plugin è inutile e a volte può causare conflitti (doppia compressione, che i browser non possono decomprimere).

Quali tipi di file beneficiano di più dalla compressione

La compressione funziona meglio su contenuti ripetitivi basati su testo. Una panoramica per tipo di file:

• HTML: comprime eccellentemente (riduzione del 70-90%). Le pagine HTML generate da WordPress sono piene di strutture di tag ripetitive, nomi di classi e spazi bianchi.
• CSS: comprime molto bene (riduzione dell'80-90%). I fogli di stile contengono molti nomi di proprietà e selettori ripetuti.
• JavaScript: comprime molto bene (riduzione del 70-85%). I file JS hanno parole chiave ripetute, nomi di funzioni e pattern strutturali.
• SVG: comprime eccellentemente (riduzione dell'80-95%). Gli SVG sono basati su XML e fortemente ripetitivi.
• JSON: comprime molto bene (riduzione del 75-90%). Le risposte API e i dati di configurazione beneficiano significativamente.
• Feed XML e RSS: comprimono molto bene grazie alla loro struttura di tag ripetitiva.
• Webfont (WOFF/WOFF2): i font WOFF2 contengono già internamente compressione Brotli, quindi una compressione aggiuntiva lato server offre poco. I font WOFF contengono compressione più leggera e possono beneficiare marginalmente da Gzip.

Cosa NON dovrebbe essere compresso

Non tutti i tipi di file beneficiano dalla compressione, e alcuni dovrebbero essere attivamente esclusi:

• Immagini JPEG, PNG, WebP, AVIF: questi formati sono già compressi. Passarli attraverso Gzip o Brotli spreca tempo CPU e può anche aumentare leggermente la dimensione del file.
• File video (MP4, WebM): già compressi con codec molto efficienti. La compressione lato server aggiunge overhead senza beneficio.
• File audio (MP3, AAC, OGG): come video, già compressi.
• File ZIP, GZIP e altri archivi: già compressi per definizione.
• File PDF: la maggior parte dei PDF usa compressione interna. Una compressione aggiuntiva offre risparmi trascurabili.

Comprimere file già compressi spreca CPU del server a ogni richiesta e può anche produrre output leggermente più grandi. La maggior parte delle configurazioni del web server e dei plugin di caching WordPress limita correttamente la compressione ai MIME type basati su testo, ma vale la pena verificare che i file binari siano esclusi.

Cosa controlla InspectWP

InspectWP esamina l'header di risposta Content-Encoding restituito dal tuo sito WordPress per determinare se la compressione è attiva. In particolare, cerca gzip, br (Brotli) o deflate nel valore dell'header. Se non viene rilevata alcuna compressione, il report lo segnala come problema di prestazioni con la raccomandazione di abilitare la compressione Gzip o Brotli. Il metodo di compressione rilevato è mostrato nella sezione prestazioni del report, e ti dà una visione chiara se il tuo server è configurato correttamente per limitare la dimensione del trasferimento.