Compressione Gzip di Nginx: Aumenta la Velocità di Caricamento del Tuo Sito Web

La compressione Gzip di Nginx aiuta il tuo sito web a caricarsi più velocemente riducendo le risposte basate su testo prima che viaggino sulla rete. Se le tue pagine includono file HTML, CSS, JavaScript, JSON, XML o SVG, la compressione può ridurre la dimensione del trasferimento senza cambiare ciò che gli utenti vedono nel browser.

L'obiettivo è semplice: inviare meno byte, ridurre i tempi di attesa e fare un uso migliore della larghezza di banda. Per la maggior parte dei siti in produzione, Gzip è uno dei miglioramenti di performance di Nginx più facili da abilitare in modo sicuro.

Come Funziona la Compressione Gzip in Nginx

La compressione Gzip avviene dopo che Nginx ha selezionato una risposta ma prima di inviarla al client. Il browser pubblicizza il supporto con l'intestazione della richiesta Accept-Encoding. Se Gzip è abilitato e il tipo di risposta corrisponde alla tua configurazione, Nginx comprime il corpo e lo invia con Content-Encoding: gzip.

Funziona meglio per i formati di testo perché contengono schemi ripetuti. I template HTML, i nomi di classe CSS, gli identificatori JavaScript e le chiavi JSON spesso si comprimono molto bene. Immagini, video, PDF e archivi sono solitamente già compressi, quindi provare a gzipparli può sprecare CPU senza ridurre significativamente il file.

Una configurazione di base di solito va nel blocco http in modo che si applichi a tutti i blocchi server:

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_proxied any;
gzip_types
    text/plain
    text/css
    text/xml
    application/json
    application/javascript
    application/xml
    application/rss+xml
    image/svg+xml;

La direttiva gzip on abilita la compressione. gzip_types dice a Nginx quali tipi MIME comprimere oltre al predefinito text/html. gzip_min_length evita di sprecare CPU su risposte molto piccole, dove l'overhead dell'intestazione Gzip potrebbe annullare il beneficio.

gzip_vary on aggiunge un'intestazione Vary: Accept-Encoding. Questo è importante se il tuo sito si trova dietro un CDN o una cache condivisa, perché le cache devono sapere che le versioni compressa e non compressa sono varianti diverse dello stesso URL.

Per una base di performance Nginx più ampia, potresti anche voler rivedere Ottimizzazione delle performance Nginx.

Un dettaglio che coglie molti: Nginx comprime sempre text/html quando Gzip è abilitato, quindi text/html non deve apparire in gzip_types. Se lo aggiungi comunque, Nginx potrebbe avvertire che il tipo MIME è duplicato. Questo avviso è innocuo, ma è un segno che la configurazione è stata copiata senza essere ripulita.

Scegliere Impostazioni di Compressione Sicure

L'errore più grande con la compressione Gzip di Nginx è trattare il livello di compressione come una manopola del volume. Più alto non è sempre meglio. I livelli Gzip di solito vanno da 1 a 9. Il livello 1 è il più veloce ma comprime meno. Il livello 9 comprime di più ma può costare notevolmente più CPU.

Per molti siti web, gzip_comp_level 4, 5 o 6 è un intervallo pratico. Dà una compressione forte senza spingere troppo il server. Se il tuo server Nginx gestisce traffico elevato o funziona su un'istanza piccola, evita di saltare direttamente al livello 9.

Buoni valori predefiniti assomigliano a questi:

• Usa gzip_comp_level 5 per una configurazione bilanciata.
• Usa gzip_min_length 1024 in modo che le risposte minuscole saltino la compressione.
• Comprimi asset basati su testo, non media già compressi.
• Mantieni gzip_vary on quando sono coinvolte cache o CDN.
• Testa l'uso della CPU dopo aver abilitato la compressione.

Ecco uno scenario comune. Gestisci un sito di documentazione con molte pagine CSS, JavaScript e HTML. Prima di Gzip, una pagina carica 650 KB di asset di testo. Dopo aver abilitato la compressione, la dimensione del trasferimento potrebbe ridursi drasticamente, mentre il browser riceve ancora gli stessi file dopo la decompressione. Gli utenti su connessioni più lente sentono maggiormente il miglioramento.

I guadagni non sono sempre uguali su ogni sito. Una pagina dominata da immagini JPEG non migliorerà molto con Gzip. Una dashboard che invia grandi risposte JSON potrebbe migliorare molto.

Per le API, sii più deliberato. Comprimere una piccola risposta JSON come {"ok":true} è di solito inutile. Comprimere un payload di 300 KB di risultati di ricerca o report può valere la pena. Se la tua API restituisce dati privati e riflette input controllati dall'utente nella stessa risposta, discuti i rischi della compressione con il team dell'applicazione prima di abilitarla ovunque. Questo non significa "non comprimere mai le API". Significa che la compressione appartiene allo stesso bucket di revisione di caching, cookie e intestazioni di risposta.

Come Testare Che Gzip Funzioni

Dopo aver modificato la configurazione di Nginx, testa la sintassi prima di ricaricare:

nginx -t

Poi ricarica Nginx tramite il tuo gestore di servizi o processo di deployment. Di solito un ricarico è sufficiente perché si tratta di un cambiamento di configurazione, non di un riavvio completo del binario.

Puoi controllare una risposta con curl:

curl -I -H "Accept-Encoding: gzip" https://example.com/app.css

Cerca questa intestazione:

Content-Encoding: gzip

Controlla anche per:

Vary: Accept-Encoding

Se non vedi Content-Encoding: gzip, verifica il tipo MIME della risposta. Ad esempio, un file JavaScript servito come text/plain potrebbe ancora comprimersi se text/plain è incluso, ma una risposta API personalizzata che usa un tipo di contenuto insolito potrebbe non corrispondere alla tua lista gzip_types.

Anche gli strumenti di sviluppo del browser possono aiutare. Apri la scheda Rete, ricarica la pagina e ispeziona le intestazioni della risposta e la dimensione trasferita. La dimensione trasferita dovrebbe essere più piccola della dimensione della risorsa non compressa per file comprimibili.

Se stai anche usando un CDN, ricorda che il CDN potrebbe eseguire la propria compressione. In tal caso, Nginx potrebbe non essere il livello finale che decide cosa riceve il browser. Testa sia l'accesso diretto all'origine che l'URL pubblico del CDN quando possibile.

Se la risposta dell'origine diretta è compressa ma la risposta del CDN no, guarda le impostazioni di compressione del CDN e il comportamento della chiave cache. Se la risposta del CDN è compressa ma l'origine no, potrebbe andare bene. Molti team lasciano intenzionalmente che il CDN gestisca la compressione statica pubblica mentre mantengono la configurazione dell'origine più semplice.

Quando Fare Attenzione con Gzip

Gzip è sicuro per la maggior parte dei contenuti statici e dinamici, ma ci sono casi in cui dovresti rallentare e testare attentamente.

Non comprimere file già compressi. Esempi comuni includono:

• .jpg, .jpeg, .png e .webp
• .mp4, .mov e altri formati video
• .zip, .gz, .tar.gz e archivi di pacchetti
• La maggior parte dei file di font, a seconda del formato e del percorso di consegna

Dovresti anche monitorare l'uso della CPU. La compressione non è gratuita. Se il tuo server è già vicino ai limiti di CPU, abilitare una compressione aggressiva può peggiorare i tempi di risposta sotto carico. Inizia con impostazioni moderate, poi monitora traffico, latenza e CPU.

Le applicazioni sensibili alla sicurezza dovrebbero anche evitare di esporre segreti in risposte compresse accanto a input controllati dall'attaccante. Questo è un rischio più specializzato, ma vale la pena saperlo per app che riflettono input utente in pagine contenenti token o dati privati.

Per asset statici, un'altra opzione è precomprimere i file durante la pipeline di build e servire versioni .gz dal disco. Questo può ridurre la CPU runtime, specialmente per grandi bundle JavaScript. Le risposte API dinamiche hanno ancora bisogno di compressione runtime se vuoi che siano compresse.

Se servi file precompressi, abilita gzip_static on; e assicurati che il file .gz sia generato dalla stessa versione esatta dell'asset del file non compresso. Un app.js.gz obsoleto accanto a un app.js più recente è un bug frustrante: solo i client che richiedono Gzip vedono il vecchio codice.

gzip_static on;

Quella direttiva è utile per artefatti di build, non per risposte dinamiche upstream. Per risposte dinamiche proxy da un server applicativo, Nginx ha ancora bisogno di compressione runtime a meno che l'upstream non invii già un corpo compresso.

Quando Chiedere Aiuto

Chiama un amministratore Nginx esperto o un ingegnere DevOps se abilitare Gzip causa CPU elevata, comportamento incoerente del CDN o risposte errate per client più vecchi. Dovresti anche chiedere aiuto se le impostazioni di compressione sono mescolate tra diversi file di configurazione inclusi e non sei sicuro di quale blocco sia effettivamente attivo.

Per un sito web semplice, Gzip può essere abilitato in pochi minuti. Per un'applicazione ad alto traffico, trattalo come qualsiasi cambiamento di performance: testalo, implementalo gradualmente e monitora il risultato.

La compressione Gzip di Nginx è un modo pratico per aumentare la velocità di caricamento per siti e API pesanti di testo. Mantieni i tipi MIME mirati, scegli un livello di compressione moderato e verifica le intestazioni dopo il ricarico. Una volta che funziona, gli utenti ricevono risposte più piccole mentre il codice dell'applicazione rimane lo stesso.