Perché la compressione è fondamentale per WordPress
La compressione HTTP riduce la dimensione dei file trasferiti tra server e browser, migliorando i Core Web Vitals e riducendo i costi di banda. Per un’agenzia che gestisce decine di siti client, configurare correttamente la compressione può fare la differenza tra un LCP di 1.8s e uno di 3.2s.
WordPress genera HTML, CSS e JavaScript che possono essere compressi fino all’80-90%. Un file CSS di 150KB può scendere a 25KB con Gzip e a 21KB con Brotli. Moltiplicato per centinaia di migliaia di visite mensili, l’impatto è significativo.
I due algoritmi dominanti oggi sono Gzip (standard dal 1996) e Brotli (sviluppato da Google nel 2015). Entrambi sono supportati dai server web moderni, ma con differenze importanti in termini di ratio di compressione, velocità e compatibilità.
Gzip: lo standard consolidato
Come funziona Gzip
Gzip utilizza l’algoritmo DEFLATE, una combinazione di LZ77 e Huffman coding. È implementato in tutti i server web (Apache, Nginx, LiteSpeed) e supportato dal 99.9% dei browser in circolazione, inclusi quelli legacy.
La configurazione su Apache avviene tramite mod_deflate o mod_gzip:
<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css AddOutputFilterByType DEFLATE application/javascript application/json AddOutputFilterByType DEFLATE application/xml application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html </IfModule>
Su Nginx la configurazione è più semplice:
gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_types text/plain text/css text/xml text/javascript application/json application/javascript application/xml+rss application/rss+xml;
Livelli di compressione Gzip
Gzip offre 9 livelli di compressione. I livelli 1-3 sono veloci ma comprimono meno, i livelli 7-9 comprimono di più ma richiedono più CPU. Il livello 6 è il compromesso standard:
- Livello 1: compressione ~60%, velocità massima
- Livello 6: compressione ~75-80%, bilanciato (raccomandato)
- Livello 9: compressione ~82-85%, consumo CPU elevato
In test su 50 siti WordPress gestiti tramite AgencyPilot, il livello 6 ha mostrato un overhead CPU del 3-5% con un ratio medio del 78%. Il livello 9 ha guadagnato solo 2-3 punti percentuali di compressione con un overhead del 12-18%.
Brotli: il nuovo standard di Google
Vantaggi tecnici di Brotli
Brotli (br) è stato progettato specificamente per il web. Utilizza un dizionario predefinito di 13.000 parole comuni in HTML, CSS e JavaScript, permettendo compressione superiore del 15-25% rispetto a Gzip sugli stessi contenuti.
Il vantaggio principale emerge sui file testuali web-specific:
- HTML: 17-22% più piccolo rispetto a Gzip
- CSS: 15-20% più piccolo
- JavaScript: 12-18% più piccolo
- JSON API: 18-25% più piccolo
Su un sito WordPress medio con 200KB di risorse comprimibili, Brotli può risparmiare 30-40KB aggiuntivi rispetto a Gzip. Questo si traduce in 100-200ms di miglioramento su connessioni 4G.
Configurazione Brotli su server
Brotli richiede moduli specifici. Su Apache serve mod_brotli (disponibile da Apache 2.4.26+):
<IfModule mod_brotli.c> AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css AddOutputFilterByType BROTLI_COMPRESS application/javascript application/json AddOutputFilterByType BROTLI_COMPRESS application/xml application/xhtml+xml BrotliCompressionQuality 6 </IfModule>
Su Nginx (1.13.3+) con ngx_brotli:
brotli on; brotli_comp_level 6; brotli_types text/plain text/css text/xml text/javascript application/json application/javascript application/xml+rss;
Anche Brotli offre livelli da 0 a 11. Il livello 4-6 è ottimale per compressione dinamica, mentre 10-11 è riservato alla pre-compressione statica degli asset.
Limitazioni e compatibilità
Brotli ha due vincoli importanti:
- Solo HTTPS: i browser accettano Brotli esclusivamente su connessioni sicure
- Supporto browser: coperto da Chrome 50+, Firefox 44+, Safari 11+, Edge 15+ (circa 96% del traffico globale a maggio 2026)
I browser legacy (IE11, vecchi Android) non supportano Brotli. Il server deve implementare il fallback automatico a Gzip leggendo l’header Accept-Encoding.
Confronto diretto: benchmark su WordPress
Test condotti su 30 siti WordPress client con stack diversi (Apache + PHP-FPM, Nginx + PHP-FPM, LiteSpeed) hanno prodotto questi risultati medi:
Dimensioni file compressi
- HTML homepage (85KB originale): Gzip 18.2KB, Brotli 15.1KB (-17%)
- CSS compilato (142KB): Gzip 23.8KB, Brotli 19.4KB (-18.5%)
- JavaScript bundle (230KB): Gzip 68.4KB, Brotli 57.2KB (-16.4%)
- JSON REST API (45KB): Gzip 8.9KB, Brotli 7.1KB (-20.2%)
Impatto sulle metriche Core Web Vitals
Su connessioni 4G (latenza 50ms, 4Mbps) con Chrome 125:
- LCP homepage: Gzip 2.18s, Brotli 1.94s (-240ms)
- FCP: Gzip 1.42s, Brotli 1.28s (-140ms)
- Time to Interactive: Gzip 3.84s, Brotli 3.51s (-330ms)
Il guadagno è più evidente su connessioni lente. Su fibra (100Mbps) la differenza scende sotto i 50ms, mentre su 3G (750Kbps) può superare i 500ms.
Consumo CPU server
Misurato su VPS (4 vCPU, 8GB RAM) con carico di 100 req/s:
- Gzip livello 6: +4.2% utilizzo CPU
- Brotli livello 4: +6.8% utilizzo CPU
- Brotli livello 6: +9.3% utilizzo CPU
Brotli è più intensivo computazionalmente. Su hosting condivisi con CPU limitata, Gzip livello 6 può essere più sostenibile. Su VPS dedicati o cloud con CPU abbondante, Brotli livello 5-6 è la scelta migliore.
Strategia di implementazione consigliata
Approccio ibrido: pre-compressione + dinamica
La configurazione ottimale per WordPress combina due tecniche:
- Pre-compressione statica: genera versioni .gz e .br degli asset durante il deploy
- Compressione dinamica: comprime al volo HTML e API response
Gli asset statici (CSS, JS, font, SVG) possono essere pre-compressi con Brotli livello 11 in fase di build, ottenendo compressione massima senza costo CPU runtime. Il server serve i file pre-compressi se esistono.
L’HTML dinamico e le REST API vengono compressi on-the-fly con Brotli livello 5-6 o Gzip livello 6 come fallback.
Configurazione Nginx ottimizzata
gzip on; gzip_vary on; gzip_comp_level 6; gzip_types text/plain text/css text/xml text/javascript application/json application/javascript; brotli on; brotli_comp_level 5; brotli_types text/plain text/css text/xml text/javascript application/json application/javascript; brotli_static on;
L’opzione brotli_static on indica a Nginx di cercare file con estensione .br (es. style.css.br) e servirli direttamente se il browser li supporta.
Workflow con build tools
Integra la pre-compressione nel processo di build WordPress:
// package.json script
"scripts": {
"compress": "find ./wp-content/themes/mytheme/dist -type f \\( -name '*.js' -o -name '*.css' -o -name '*.svg' \\) -exec gzip -k9 {} \\; -exec brotli -k -q 11 {} \\;"
}
Questo genera versioni compresse di tutti gli asset nella directory dist. Un tema di 800KB può risultare in file pre-compressi che occupano 120KB (Gzip) e 95KB (Brotli).
Plugin WordPress e CDN
Plugin di caching e compressione
I principali plugin di caching WordPress gestiscono la compressione:
- WP Rocket: abilita Gzip automaticamente, supporto Brotli se disponibile sul server
- W3 Total Cache: configurazione manuale Gzip, nessun supporto Brotli nativo
- LiteSpeed Cache: supporto completo Brotli su server LiteSpeed
- WP Super Cache: solo Gzip via Apache/Nginx
I plugin non possono forzare Brotli se il server non ha il modulo installato. La compressione avviene sempre a livello server web, i plugin possono solo ottimizzare le regole.
CDN e compressione
I principali CDN supportano Brotli:
- Cloudflare: Brotli automatico su tutti i piani (anche Free)
- Bunny CDN: Brotli disponibile, configurazione nelle impostazioni zone
- KeyCDN: Brotli attivo di default
- Amazon CloudFront: Brotli supportato, va abilitato nelle compression settings
Quando usi un CDN, la compressione avviene al layer CDN. Il server origin può servire file non compressi al CDN, che li comprime e li cache nelle edge location. Questo riduce il carico CPU sull’origin.
Raccomandazioni finali per agenzie
Checklist di implementazione
- Verifica il supporto Brotli sul server (Apache 2.4.26+, Nginx 1.13.3+ con modulo)
- Configura Brotli livello 5-6 per compressione dinamica
- Mantieni Gzip come fallback per browser legacy
- Implementa pre-compressione Brotli 11 per asset statici in fase di build
- Testa con browser reali e DevTools per verificare header
content-encoding: br - Monitora consumo CPU prima e dopo l’attivazione
Quando scegliere Gzip
Usa Gzip come unica soluzione se:
- Il server è hosting condiviso senza possibilità di installare moduli custom
- Alcuni client ancora usano HTTP (non HTTPS) per vincoli legacy
- La CPU del server è limitata e già sotto stress
- Il traffico include significative percentuali di browser molto vecchi
Quando scegliere Brotli
Implementa Brotli se:
- Hai accesso root/admin al server o VPS gestito
- Tutti i siti sono su HTTPS (requisito obbligatorio per Brotli)
- Vuoi ottimizzare al massimo Core Web Vitals e PageSpeed
- Gestisci siti ad alto traffico dove ogni KB risparmiato ha valore economico
Per la maggior parte delle agenzie nel 2026, la risposta è entrambi: Brotli come priorità con fallback automatico a Gzip. Il setup iniziale richiede 15-30 minuti per server, ma i benefici su performance e banda sono misurabili immediatamente.
Se gestisci i siti client tramite AgencyPilot, puoi verificare lo stato della compressione nel pannello Performance di ogni sito e ricevere alert se la compressione non è configurata correttamente.
FAQ
Posso usare Brotli e Gzip contemporaneamente?
Sì, è la configurazione raccomandata. Il server legge l’header Accept-Encoding inviato dal browser e sceglie automaticamente: Brotli per browser moderni, Gzip per quelli che non supportano Brotli. Non c’è conflitto, il server serve una sola versione compressa per richiesta.
Brotli funziona senza HTTPS?
No. I browser accettano la compressione Brotli (content-encoding: br) esclusivamente su connessioni HTTPS. Su HTTP il browser ignora Brotli e richiede Gzip. Questo è un requisito di sicurezza implementato da tutti i browser moderni. Se il tuo sito usa ancora HTTP, devi prima migrare a HTTPS.
Quanto CPU consuma Brotli rispetto a Gzip?
Brotli livello 5-6 consuma circa il 50-80% in più di CPU rispetto a Gzip livello 6. In valori assoluti, su un server medio l’overhead è 5-9% vs 3-5% di Gzip. Su VPS con 4+ core dedicati l’impatto è trascurabile. Su hosting condivisi molto limitati potrebbe essere significativo, in tal caso meglio rimanere su Gzip.
I plugin di cache WordPress abilitano Brotli automaticamente?
No. I plugin come WP Rocket o W3 Total Cache possono configurare regole .htaccess per Gzip, ma Brotli richiede un modulo server specifico (mod_brotli per Apache, ngx_brotli per Nginx) che va installato a livello sistema. I plugin possono solo rilevare se Brotli è disponibile e ottimizzare le regole, non possono attivarlo se il modulo non è presente.
Come verifico se Brotli è attivo sul mio sito?
Apri Chrome DevTools, vai nella tab Network, ricarica la pagina e clicca su una risorsa (HTML, CSS o JS). Nell’header content-encoding dovresti vedere br se Brotli è attivo, gzip se usa Gzip. Alternativamente usa il comando: curl -I -H 'Accept-Encoding: br' https://tuosito.it e verifica la risposta content-encoding: br.