
⚙️ Come abilitare la compressione GZIP in WordPress: una guida completa
Il sito impiega 4 secondi ad aprirsi e il visitatore se ne va. Ti suona familiare? Nella maggior parte dei casi il problema non è l'hosting né le immagini. Le pagine pesano semplicemente più del dovuto perché il server le consegna "così come sono", senza compressione.
La compressione GZIP riduce le dimensioni di HTML, CSS e JavaScript del 60-80% prima che vengano inviati al browser. Per WordPress non si tratta di un plugin pesante con mille impostazioni, ma di una direttiva nel file di configurazione o di una spunta nel pannello di amministrazione. Secondo W3Techs, la compressione è usata da oltre l'85% dei siti web e, se il tuo non è tra questi, stai perdendo posizionamento sui motori di ricerca e conversioni senza alcun motivo.
Ecco sette metodi funzionanti per attivare GZIP: dalla modifica manuale di .htaccess a un paio di clic in un plugin. Alla fine ti mostrerò come verificare il risultato e risponderò alle domande più comuni sulla compatibilità con CDN, Brotli e caching.
💡 Panoramica rapida:
- Aggiungere il codice di compressione a
.htaccessvia FTP - Scrivere
gzip onegzip_typesinnginx.conf - Attivare la compressione con una spunta in W3 Total Cache o WP Rocket
- Verificare il risultato in Chrome DevTools o su GiftOfSpeed
Cos'è la compressione GZIP e perché serve a un sito WordPress
GZIP è un algoritmo di compressione che opera a livello di server: prima di inviarli al browser, "impacchetta" i file di testo in una forma più compatta. Il browser li decomprime al volo e visualizza la pagina come al solito. L'utente non nota alcuna differenza, mentre il volume dei dati trasmessi si riduce di diverse volte.

Cosa viene compresso esattamente: il codice HTML della pagina, i fogli di stile CSS, gli script JavaScript, i file XML, i font e gli SVG. GZIP non interviene sulle immagini; per queste esistono formati di compressione dedicati (WebP, AVIF) e plugin di ottimizzazione.
La differenza in numeri è facile da vedere in Chrome DevTools: la stessa pagina prima e dopo la compressione differisce in dimensioni di due o tre volte. Moltiplica questo valore per il numero di visitatori al mese e otterrai un risparmio significativo in termini di traffico e tempo di caricamento.
Una sfumatura importante: GZIP non è l'unica opzione. I server moderni supportano Brotli, un algoritmo di Google che comprime i file di testo il 15-25% meglio di GZIP. Ma Brotli non è disponibile su tutti i provider di hosting, mentre GZIP funziona ovunque, incluse le configurazioni più datate. Per questo conviene sempre partire da GZIP e collegare Brotli come livello successivo, una volta che la base è pronta.
Metodo 1: via.htaccess su Apache
Lo scenario più comune: il sito gira su Apache e tutto ciò che devi fare è aggiungere alcune righe al file .htaccess nella root del sito.
Dove si trova.htaccess. Collegati al server via FTP (ad esempio con FileZilla) o accedi al file manager dell'hosting. Nella cartella principale del sito (dove si trovano wp-config.php e le cartelle wp-content, wp-admin) individua .htaccess. Scaricalo sul tuo computer; lo modificheremo in locale in modo da poter tornare rapidamente indietro in caso di errore.
Cosa aggiungere. Apri .htaccess in un editor di testo (Notepad++, VS Code, Sublime Text) e aggiungi il blocco seguente PRIMA delle righe # BEGIN WordPress:
1 <IfModule mod_deflate.c> 2 AddOutputFilterByType DEFLATE text/html text/css text/javascript 3 AddOutputFilterByType DEFLATE application/javascript application/x-javascript 4 AddOutputFilterByType DEFLATE application/rss+xml application/xml application/xhtml+xml 5 AddOutputFilterByType DEFLATE image/svg+xml image/x-icon 6 AddOutputFilterByType DEFLATE font/ttf font/otf font/opentype application/x-font-ttf 7 AddOutputFilterByType DEFLATE application/vnd.ms-fontobject 8 9 BrowserMatch ^Mozilla/4 gzip-only-text/html 10 BrowserMatch ^Mozilla/4.0[678] no-gzip 11 BrowserMatch bMSIE !no-gzip !gzip-only-text/html 12 Header append Vary User-Agent 13 </IfModule>

Cosa succede qui. Il blocco <IfModule mod_deflate.c> verifica se il modulo mod_deflate è abilitato sul server (sulla maggior parte degli hosting lo è di default). Le direttive AddOutputFilterByType DEFLATE specificano quali tipi di file comprimere. Le righe BrowserMatch sono un correttivo per le vecchie versioni di Internet Explorer, che evita bug di gzip in IE6 e versioni precedenti. Header append Vary User-Agent indica ai server proxy di considerare il browser dell'utente durante la cache.
Salva il file e caricalo di nuovo sul server sovrascrivendolo. Prima di farlo, assicurati di fare una copia di backup dell'.htaccess originale; se il sito va in down, ti basterà ripristinare la vecchia versione e tutto tornerà a funzionare come prima.
Se dopo il caricamento il sito restituisce errore 500, verifica che non ci siano spazi extra o interruzioni di riga prima di <?php o dopo i tag di chiusura nel file. Un errore in .htaccess blocca l'intero sito, quindi è meglio fare le modifiche una alla volta e verificare dopo ciascuna.
Metodo 2: su un server NGINX
NGINX gestisce la compressione in modo diverso da Apache. Qui non esiste .htaccess e tutte le impostazioni vanno scritte nel file nginx.conf o nel file di configurazione del sito specifico (di solito in /etc/nginx/sites-available/).
Aggiungi o decommenta le seguenti righe nella sezione http o server:
1 gzip on; 2 gzip_vary on; 3 gzip_min_length 1000; 4 gzip_comp_level 6; 5 gzip_types text/plain text/css text/javascript 6 application/javascript application/x-javascript 7 application/rss+xml application/xml application/xhtml+xml 8 image/svg+xml image/x-icon 9 font/ttf font/otf application/x-font-ttf 10 application/vnd.ms-fontobject; 11 gzip_disable "MSIE [1-6]\.(?!.*SV1)";
Dopo aver apportato le modifiche, verifica la sintassi della configurazione con il comando nginx -t e ricarica NGINX: sudo systemctl reload nginx.
Il parametro gzip_comp_level 6 rappresenta un compromesso tra livello di compressione e carico del processore. Un valore di 1 è la compressione minima, 9 è la massima. In pratica, il livello 6 offre un risparmio quasi identico al 9, ma consuma sensibilmente meno risorse del server.
Metodo 3: su un server IIS (Windows Server)
IIS è un web server Microsoft utilizzato sugli hosting Windows. L'attivazione della compressione qui si effettua in due modi: tramite l'interfaccia grafica o da riga di comando.
Tramite l'interfaccia di IIS. Apri Gestione IIS. Nella sezione "Componenti" → "Servizi" trova "Compressione". Seleziona le caselle "Abilita compressione contenuto statico" e "Abilita compressione contenuto dinamico". Nel pannello "Azioni" clicca su "Applica".
Tramite riga di comando (come amministratore):
1 :: Static compression 2 appcmd set config /section:urlCompression /doStaticCompression:True 3 4 :: Dynamic compression 5 appcmd set config /section:urlCompression /doDynamicCompression:True
La compressione statica memorizza nella cache su disco le versioni già compresse dei file, risparmiando tempo di processore. La compressione dinamica comprime le risposte "al volo" ed è adatta per pagine personalizzate, ma carica il processore. In pratica, per WordPress si attivano entrambe le modalità: quella statica gestisce CSS/JS, mentre quella dinamica gestisce l'HTML di ogni pagina.
Metodo 4: tramite il pannello del provider di hosting
La maggior parte dei provider di hosting moderni attiva GZIP di default. Se sei su cPanel, vai nella sezione "Ottimizzazione sito" o "Prestazioni" e cerca l'interruttore "Compressione" o "Comprimi contenuto". Su Plesk il percorso è simile: "Prestazioni" → "Compressione output".
Se non trovi l'interruttore, scrivi all'assistenza del tuo hosting. È una richiesta standard; il supporto tecnico risponde in pochi minuti e spesso attiva la compressione a livello di server in una sola risposta. Non devi spiegare cos'è GZIP; ti basta scrivere "Per favore, attivate la compressione GZIP per il mio sito".
Puoi verificare se l'hosting sta già comprimendo le pagine prima di qualsiasi modifica; il metodo è descritto nella sezione "Come verificare se la compressione è attiva" qui sotto. Se il controllo mostra che GZIP funziona, salta tutti i metodi lato server e passa ai plugin solo se desideri gestire la compressione dal pannello di amministrazione di WordPress.
Metodo 5: plugin W3 Total Cache
W3 Total Cache è uno dei più longevi plugin di caching nella repository di WordPress, con un milione di installazioni attive e una valutazione di 4,5 su WordPress.org. La compressione GZIP si attiva con una casella di controllo separata e non richiede di intervenire sui file del server.

Installa il plugin dalla repository di WordPress, vai su Performance → Browser Cache e individua la sezione «HTTP (gzip) compression». Spunta la casella «Enable HTTP (gzip) compression» e salva le impostazioni. Il plugin aggiungerà automaticamente le direttive necessarie al file .htaccess o configurerà le regole NGINX in base al server su cui gira il sito.
- Vantaggi: non si interviene manualmente sui file del server, un milione di installazioni conferma la stabilità, compatibile con CDN e Brotli
- Svantaggi: interfaccia sovraccarica di opzioni, un principiante può facilmente rompere la cache con la casella sbagliata
Metodo 6: plugin WP Rocket
WP Rocket è un plugin premium per le performance che aggiunge automaticamente le regole GZIP al file .htaccess dopo l'attivazione. Non ci sono impostazioni di compressione al suo interno; viene abilitata automaticamente all'installazione.
- Pro: zero lavoro manuale, la compressione si attiva da sola, il plugin risolve anche una serie di attività correlate (caching, lazy loading, minificazione)
- Contro: a pagamento (da $59 all'anno), pagare solo per il GZIP non è giustificato
Se hai già acquistato WP Rocket per altre funzionalità, la compressione sta già funzionando. Se stai pensando di prendere il plugin solo per il GZIP, non farlo: .htaccess o W3 Total Cache fanno la stessa cosa gratis.
Metodo 7: plugin WP Super Cache
WP Super Cache è un plugin di caching gratuito di Automattic (le stesse persone dietro WordPress.com). Funziona in modo più semplice di W3 Total Cache: meno impostazioni, meno rischio di rompere qualcosa.

Installa il plugin, vai su Impostazioni → WP Super Cache → Avanzate e trova la voce "Comprimi le pagine in modo che vengano servite più velocemente ai visitatori". Attivala e salva.
- Pro: gratuito, interfaccia semplice, codice stabile di Automattic
- Contro: inferiore a W3 Total Cache nelle funzionalità di caching, nessuna regolazione fine dei tipi di compressione
Come funziona in pratica la compressione GZIP
Quando un browser richiede una pagina invia l'header Accept-Encoding: gzip, deflate, br, che significa "capisco gzip, deflate e brotli, invia in uno di questi formati". Il server vede questo header, verifica se la compressione è abilitata per il tipo di file richiesto e, in caso affermativo, comprime la risposta e aggiunge l'header Content-Encoding: gzip.
Il browser riceve i dati compressi, li decomprime in memoria e renderizza la pagina. Per l'utente tutto avviene all'istante; la decompressione gzip richiede frazioni di millisecondo anche su un dispositivo mobile poco potente.
Questo meccanismo è universale: funziona allo stesso modo per Apache, NGINX, IIS e qualsiasi plugin WordPress. I plugin non inventano un proprio metodo di compressione; aggiungono semplicemente le stesse direttive server che abbiamo scritto manualmente nei primi tre metodi.
Cosa mostrano Google PageSpeed Insights e GTmetrix
Entrambi i servizi, PageSpeed Insights e GTmetrix, verificano la compressione durante ogni audit e segnalano esplicitamente il problema se le risorse testuali sono servite senza GZIP.

In PageSpeed Insights l'avviso appare come "Attiva la compressione del testo" nella sezione "Opportunità" dell'audit. Lighthouse (il motore di PageSpeed Insights) stima direttamente il risparmio potenziale in kilobyte per ogni risorsa non compressa. In GTmetrix c'è un controllo simile, "Attiva la compressione GZIP" nella categoria "Contenuti".
Un punto importante: né PageSpeed Insights né GTmetrix distinguono tra GZIP e Brotli a livello di raccomandazione. Se la compressione è abilitata con uno di questi metodi, l'audit mostrerà un segno di spunta verde. Quindi il GZIP è sufficiente per superare l'audit.
Come verificare se la compressione è attiva
Tre metodi, dal visivo al basso livello.
Metodo 1: Chrome DevTools. Apri il sito, premi F12, vai alla scheda Network. Ricarica la pagina, clicca su una qualsiasi riga e guarda la scheda Headers. Trova la riga Content-Encoding: gzip nella sezione Response Headers.

Lì puoi anche vedere la dimensione effettiva e quella compressa: nell'esempio sopra la pagina pesava 51,6 KB e dopo la compressione 17,7 KB.

Metodo 2: tester online. GiftOfSpeed GZIP Test (giftofspeed.com/gzip-test) o Check GZIP Compression (checkgzipcompression.net): incolli l'URL e ottieni un verdetto e la percentuale di compressione. Più veloce di DevTools se devi controllare il sito di qualcun altro o più pagine in sequenza.
Metodo 3: curl da riga di comando. Se sei su Linux/macOS o in WSL su Windows:
1 curl -I -H "Accept-Encoding: gzip" https://yoursite.com | grep Content-Encoding
La risposta Content-Encoding: gzip significa che la compressione funziona. Una risposta vuota significa di no.
Breve spiegazione video
Per chiudere l'argomento con un lato visivo, ecco un breve video che mostra l'intero processo di attivazione del GZIP via .htaccess e la verifica del risultato in Chrome DevTools:
⁉️🤔 Domande frequenti
La compressione GZIP rallenta il server?
Al contrario. Sì, il processore spende risorse per comprimere, ma è un carico microscopico rispetto al guadagno derivante dalla riduzione dei dati trasmessi. Al livello di compressione 6 (il compromesso standard) il processore lo gestisce in millisecondi. L'unico scenario in cui la compressione può essere percepibile è un VPS molto debole con 512 MB di memoria e migliaia di visitatori simultanei. Ma in quella situazione hai problemi più seri del GZIP. In pratica la compressione non rallenta il server: una tipica pagina WordPress viene compressa in 2-5 millisecondi, mentre il risparmio sulla trasmissione dei dati in rete ammonta a decine e centinaia di millisecondi per ogni visitatore. La compressione è sempre più vantaggiosa della sua assenza.
GZIP o Brotli: cosa scegliere nel 2026?
Inizia con GZIP; funziona su qualsiasi hosting ed è supportato da tutti i browser senza eccezioni. Brotli comprime sensibilmente meglio ma richiede HTTPS (non è un problema nel 2026) e supporto lato server. Se l'hosting o la CDN (Cloudflare, BunnyCDN) supportano Brotli, attivalo in aggiunta a GZIP. La maggior parte dei siti moderni usa entrambi: il server serve Brotli ai browser che lo capiscono e GZIP a tutti gli altri.
La compressione GZIP è compatibile con le CDN?
Pienamente. CDN come Cloudflare o BunnyCDN comprimono i contenuti sui loro edge server autonomamente, spesso in Brotli, anche se il tuo hosting non lo supporta. Se il sito è già dietro Cloudflare, verifica che l'opzione "Brotli" sia attiva in "Velocità" → "Ottimizzazione". In questo scenario configurare il GZIP a livello server è comunque utile come fallback per le richieste dirette al server di origine.
Ho un plugin di caching. Devo attivare il GZIP separatamente?
Dipende dal plugin. WP Rocket attiva il GZIP automaticamente, W3 Total Cache con un'apposita casella di controllo, WP Super Cache con un'apposita casella di controllo. Controlla le impostazioni del tuo plugin; quasi tutti i plugin di caching hanno un'opzione di compressione ma non tutti la attivano di default. Non fare affidamento sul "dovrebbe funzionare"; verifica tramite DevTools dopo la configurazione.
Posso comprimere le pagine tramite functions.php?
Tecnicamente sì, tramite la funzione PHP
ob_start('ob_gzhandler'), ma non lo consigliamo. Questo metodo comprime l'output PHP e non influisce sui file statici (CSS, JS) che costituiscono la maggior parte del traffico. La compressione lato server (Apache/NGINX) funziona per tutti i tipi di file e non carica il processore PHP. Lascia la compressione PHP per quei rari casi in cui l'accesso alle configurazioni del server è fisicamente impossibile.
Conclusioni: cosa attivare e quando
Il GZIP non è un'opzione "imposta e dimentica" ma un'igiene di base per un sito WordPress. Se in questo momento non sai se il tuo server comprime le pagine, apri DevTools e controlla l'header Content-Encoding. Manca? Torna al metodo 1 e aggiungi tre righe a .htaccess.
Matrice decisionale rapida:
- Sito su Apache e non hai paura dell'FTP → metodo 1 (
.htaccess), 5 minuti - Sito su NGINX e hai accesso alle configurazioni → metodo 2 (
nginx.conf), 10 minuti con verifica della sintassi - Per principio non tocchi i file del server → W3 Total Cache o WP Super Cache, 2 minuti
- Paghi già WP Rocket → non fare nulla, la compressione funziona in automatico
- Non vuoi configurare proprio niente → scrivi all'assistenza dell'hosting
Verifica il risultato con uno qualsiasi dei tre metodi sopra e chiudi questa questione per sempre. È quella rara ottimizzazione che si fa davvero una volta sola e continua a far risparmiare traffico e ad accelerare il sito anni dopo, senza aggiornamenti, abbonamenti e riconfigurazioni.



