[WP] Compressione Gzip vs Brotli: la differenza tra i due algoritmi di compressione

Per rendere più veloci i siti, compresi quelli creati con il CMS WordPress, è utile impostare la compressione dei dati sul server. Così i dati trasferiti tra server web e browser si caricano più in fretta e l'intero sito diventa più veloce. È uno dei fattori a cui gli amministratori di siti pensano di più. La compressione gzip è molto usata, e su molti server web c'è un passaggio crescente da gzip alla compressione Brotli .

1️⃣ Cos'è la compressione?

Sito URL: quando lo apri, inizia una conversazione tra browser e server. In quel momento il browser comunica al server se può annullare la compressione dei contenuti (Compression) e quali algoritmi di compressione usa. Questo aiuta il browser a decomprimere correttamente i dati quando il server li invia compressi. Quindi, con un server e un browser che supportano gli algoritmi di compressione, il tuo sito si carica ancora più velocemente.

Quando un browser si collega a un server, invia header come la compressione gzip o Brotli. I dati compressi con uno dei due arrivano al browser, e i dati compressi si caricano più velocemente di quelli non compressi.

Content-encoding: gzip
Content-encoding: br

I file compressi sono soprattutto testo:
· HTML
· CSS
· JavaScript

2️⃣ Cos'è la compressione Gzip?

Gli algoritmi di compressione più usati dagli hosting sono Gzip e Brotli. La beta di Gzip è uscita nel 1992 e la versione 1.0 nel 1993. In generale, Gzip è uno dei metodi standard per comprimere i dati inviati su internet. Si basa su DEFLATE, uno dei primi algoritmi di compressione, e prende il nome da gzip, un programma di compressione di file sviluppato in precedenza per Unix.

DEFLATE combina l'algoritmo LZ77 (Lempel-Ziv 1977) con la codifica di Huffman. LZ77 cerca dati ripetuti, trova le stringhe corrispondenti e le sostituisce con dei codici. La codifica di Huffman usa la frequenza di ogni carattere per assegnare i codici di bit più brevi.

Gzip comprime i dati con DEFLATE e, grazie all'header ‘Accept-Encoding: gzip’ nelle richieste e risposte HTTP, comprime solo quando il client supporta Gzip. Questa compressione aiuta i siti a caricarsi più velocemente.

3️⃣ Cos'è la compressione Brotli?

Brotli è stato sviluppato nel 2013 dagli ingegneri di Google Jyrki Alakuijala e Zoltán Szabadka.

Gzip era pensato in origine per comprimere file, ma è stato adattato all'uso sul web. Brotli invece è stato sviluppato fin dall'inizio per il web. Con Brotli quindi il server web può comprimere i contenuti prima di inviarli al browser. Poiché vengono compressi prima di essere trasmessi al browser, è un approccio migliore e più avanzato.

Brotli usa le stesse due tecniche di base della compressione GZIP: LZ77 e la codifica di Huffman.

4️⃣ Compressione Gzip vs compressione Brotli

Gzip comprime (e decomprime) i dati con il metodo DEFLATE, mentre Brotli usa un formato proprio che aggiunge la modellazione del contesto a LZ77 e alla codifica di Huffman.

• Gzip comprime più velocemente di Brotli.
• Brotli è stato progettato appositamente per il web.
• Brotli offre un rapporto di compressione migliore (cioè file compressi più piccoli) a ogni livello.
• Rispetto a Gzip, Brotli comprime meglio questi tre tipi di file: del 21% l'HTML, del 17% il CSS e del 14% il JavaScript.

Sempre più server web preferiscono Brotli a Gzip. Poiché Brotli è progettato per comprimere i flussi al volo, la decompressione lato front-end sarebbe fino al 64% più veloce di Gzip.

La RFC 1952, pubblicata nel maggio 1996, spiega che il formato Gzip usa il metodo di compressione DEFLATE e include un valore CRC per rilevare i dati danneggiati. Il valore CRC-32 e la dimensione dei dati originali sono scritti alla fine dei dati compressi.

La RFC 7932, pubblicata nel luglio 2016, afferma che Brotli comprime combinando l'algoritmo LZ77 con la codifica di Huffman. In più usa i due byte precedenti dei dati non compressi come contesto per scegliere i codici di Huffman e, al posto delle stringhe ripetute, può anche rimandare a parole di un dizionario statico di 122.784 byte.

I due formati compaiono nell'header di risposta come [Content-Encoding: gzip] e [Content-Encoding: br]. Il valore [br] è stato registrato come codifica di contenuto HTTP nella RFC 7932.

5️⃣ Compressione Gzip e Brotli misurata: un server Nginx + Apache

Su un server WordPress con Nginx e Apache insieme ho confrontato le risposte per un articolo, il file CSS predefinito dei blocchi di WordPress e il file jQuery, cambiando solo l'header della richiesta. Le richieste con solo gzip in [Accept-Encoding], solo br e senza header sono state inviate con curl dallo stesso server.

for ae in gzip br ''; do echo == ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/hello-world/ | grep -i -E '^(content-encoding|size)'; done

== gzip
content-encoding: gzip
size: 21390
== br
content-encoding: br
size: 20190
== none
size: 90833

L'HTML di un articolo è stato compresso a 21.390 byte per la richiesta gzip e a 20.190 byte per quella br, mentre la richiesta senza header ha ricevuto i 90.833 byte non compressi. La risposta br era 1.200 byte (5,6%) più piccola di quella gzip.

for f in wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do for ae in gzip br ''; do echo == ${f##*/} ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/$f | grep -i -E '^(content-encoding|size)'; done; done

== style.min.css gzip
content-encoding: gzip
size: 19655
== style.min.css br
size: 140829
== style.min.css none
size: 140829
== jquery.min.js gzip
content-encoding: gzip
size: 30633
== jquery.min.js br
size: 87553
== jquery.min.js none
size: 87553

Con la richiesta gzip il file CSS è stato compresso a 19.655 byte e il file jQuery a 30.633 byte. Con solo br o senza header, il server ha restituito così com'erano gli originali da 140.829 e 87.553 byte, senza header [Content-Encoding].

nginx -V 2>&1 | grep -c brotli

0

httpd -M 2>/dev/null | grep -E 'brotli|deflate'

 deflate_module (shared)
 brotli_module (shared)

I file statici come CSS e JS vengono serviti e compressi direttamente da Nginx, e poiché in questa configurazione Nginx non ha il modulo Brotli, comprime solo con gzip.

Per l'HTML, WordPress risponde alla richiesta che Nginx passa ad Apache, e Apache la comprime. Apache ha sia il modulo Brotli sia il modulo [mod_deflate], che gestisce la compressione Gzip.

for f in hello-world/ wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do echo == $f; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/$f | grep -i -E '^(content-encoding|size)'; done

== hello-world/
content-encoding: gzip
size: 21390
== wp-includes/css/dist/block-library/style.min.css
content-encoding: gzip
size: 19655
== wp-includes/js/jquery/jquery.min.js
content-encoding: gzip
size: 30633

Avere un modulo Brotli sul server non significa che il browser riceva risposte compresse con Brotli. Con la richiesta [gzip, deflate, br, zstd], lo stesso valore che invia Edge 155, Apache ha compresso anche l'HTML con gzip, e tutti e tre i file sono tornati in gzip.

Anche mettendo br prima di gzip o indicandolo come preferito, come in [br;q=1.0, gzip;q=0.5], l'HTML è tornato in gzip. Aprendo lo stesso articolo e i due file in Edge, anche lì sono arrivati tutti in gzip.

Il tempo al primo byte è la mediana dei valori [time_starttransfer] di curl, misurati 40 volte ciascuno in ordine casuale; ogni richiesta apriva una nuova connessione, quindi è incluso il tempo di connessione TLS. Per l'HTML la risposta non compressa ha impiegato 22,7 ms, gzip 26,3 ms, br 26,5 ms e la richiesta simile a quella di un browser 25,0 ms. CSS e JS hanno impiegato 18–21 ms, con o senza compressione.

La velocità di compressione di Gzip e Brotli non è stata misurata qui, ma confrontata con fonti pubbliche. La RFC 7932 afferma che Brotli comprime con un rapporto nettamente più alto del programma gzip e decomprime molto più velocemente delle attuali implementazioni LZMA. Nel repository di Brotli, Google spiega che Brotli ha una velocità simile a deflate ma comprime in modo più denso.

Nel 2015 Cloudflare ha testato i due metodi su 10.655 file HTML, CSS e JavaScript. Brotli alla qualità massima ha prodotto risultati in media 1,19 volte più piccoli di zlib alla qualità massima, ma comprimeva a 0,5 MB al secondo, molto più lentamente dei 41,9 MB di zlib livello 9. Brotli livello 4 aveva un rapporto simile a zlib livello 8 ed era in media leggermente più veloce, ma 1,48 volte più lento considerando solo i file sotto i 64 KB.

Abbiamo visto come ottimizzare un sito comprimendo file come HTML, CSS e JavaScript. Per velocizzare un sito, la compressione dei file e Ottimizzazione immagini sono elementi essenziali.

🔢 FAQ & contenuti consigliati

ℹ️ Informativa sull'affiliazione
I contenuti di questo sito includono link di affiliazione. Se un visitatore acquista un prodotto o un servizio tramite uno di questi link, il sito riceve una commissione dal venditore. In questo processo l'importo pagato dall'acquirente ^{(durante le promozioni l'importo scende↓)} non aumenta. Prezzi, sconti e disponibilità indicati si riferiscono al momento della stesura e possono differire da quelli reali: prima di acquistare verifica sempre presso il venditore. I prodotti vengono scelti e valutati secondo criteri propri, e le commissioni non influiscono sull'ordine di presentazione né sul contenuto delle valutazioni.