Che cosa succede se il tuo sito comprime la pagina due volte

Se la pagina del tuo sito arriva compressa due volte, oppure non arriva compressa affatto, la domanda è chi l'ha compressa: il server di origine, oppure chi sta davanti ai visitatori. Il 3 novembre 2026 ho letto la norma HTTP del giugno 2022, tre pagine di nginx con last-modified 22 ottobre 2026, la pagina sul campo Content-Encoding modificata in pagina il 4 luglio 2025, e la pagina sulla compressione aggiornata il 17 aprile 2026. Non dicono la stessa cosa. Non ho misurato un sito.

La norma, giugno 2022

La RFC 9110, HTTP Semantics, è pubblicata nel giugno 2022. Nella risposta letta il 3 novembre 2026 non c'è last-modified. Il campo Content-Encoding indica quali codifiche di contenuto sono state applicate alla rappresentazione, oltre a quelle già interne al tipo di media, e quindi quali decodifiche vanno applicate per ottenere i dati nel tipo indicato da Content-Type. Serve soprattutto a comprimere i dati senza perdere l'identità del tipo di media.

Se una o più codifiche sono state applicate, chi le ha applicate deve generare il campo e elencare le codifiche nell'ordine in cui sono state applicate. Il nome identity è riservato all'altro campo, quello delle preferenze, e non dovrebbe stare in Content-Encoding. Sono due campi. Non li fondo.

A differenza di Transfer-Encoding, le codifiche elencate in Content-Encoding sono una caratteristica della rappresentazione. La rappresentazione è definita nella forma codificata, e gli altri metadati riguardano la forma codificata, salvo dove la definizione del metadato dice altrimenti. Di solito la rappresentazione si decodifica solo subito prima di mostrarla, o di un uso analogo.

Se il tipo di media include già una codifica interna, per esempio un formato che è sempre compresso, quella codifica non si riscrive in Content-Encoding anche se l'algoritmo coincide con una delle codifiche di contenuto. Si elencerebbe solo se, per una ragione che il testo chiama bizzarra, viene applicata una seconda volta per formare la rappresentazione. Questa frase, la seconda applicazione, sta qui. Non è ancora la frase del 17 aprile, che parla di decomprimere e ricomprimere.

La codifica gzip, in questa norma, è una codifica LZ77 con un controllo CRC a 32 bit, prodotta di solito dal programma gzip. Il documento che la definisce è la RFC 1952. Non l'ho aperta. Chi riceve dovrebbe considerare x-gzip equivalente a gzip. La codifica deflate è un'altra: un formato zlib che contiene un flusso deflate. Una nota dice che alcune implementazioni non conformi mandano il flusso senza l'involucro zlib. Non la fondo con la definizione. La codifica compress, con la esse, è ancora un'altra, LZW. Non è gzip. In questa sezione la norma non nomina Brotli.

L'altro campo, ancora giugno 2022

Accept-Encoding, nella stessa norma, è il campo con cui un programma indica le preferenze sulle codifiche. Quando lo manda chi naviga, dice quali codifiche sono accettabili nella risposta. Il token identity è un sinonimo di nessuna codifica, per dire quando non si preferisce alcuna codifica. Se il campo manca del tutto, qualunque codifica di contenuto è considerata accettabile. Se il valore del campo è vuoto, chi naviga non vuole alcuna codifica nella risposta. Campo assente e campo vuoto non sono la stessa frase.

Una rappresentazione può essere codificata con più codifiche. Però la maggior parte delle codifiche sono modi alternativi per lo stesso scopo, per esempio comprimere i dati. Quando si sceglie tra codifiche con lo stesso scopo, si preferisce quella accettabile con il peso diverso da zero più alto. Questa frase è la scelta tra alternative. Non è la frase che obbliga a elencare le codifiche nell'ordine in cui sono state applicate. Non le unisco. Il peso zero significa non accettabile.

Se il campo c'è, non è vuoto, e nessuna rappresentazione disponibile ha una codifica elencata come accettabile, l'origine dovrebbe rispondere senza codifica, a meno che l'identità sia indicata come non accettabile. Una nota dice che l'insieme delle codifiche supportate può essere diverso per altre risorse dello stesso server, e può cambiare nel tempo o dipendere da altri aspetti della richiesta. Non descrivo quegli aspetti.

La pagina del campo, 4 luglio 2025

La pagina Content-Encoding di MDN scrive, in pagina, ultima modifica il 4 luglio 2025. Last-modified della risposta letta il 3 novembre 2026: 3 novembre 2026 alle 00:53:27 GMT. Le due date non coincidono. Non le unisco. Dice che il campo elenca le codifiche e l'ordine in cui sono state applicate, così chi riceve sa come decodificare per ottenere il formato originale descritto in Content-Type. La codifica di contenuto si usa soprattutto per comprimere senza perdere l'informazione sul tipo di media originale.

Scrive che i server dovrebbero comprimere i dati il più possibile, e che comprimere tipi di media già compressi, come un archivio zip o un'immagine jpeg, di solito non è appropriato perché può aumentare la dimensione del file. Questa frase sulla dimensione è di questa pagina. La norma del giugno 2022 non la scrive. Se il media originale è già codificato, per esempio come archivio zip, quell'informazione non sta nel campo. È vicina alla frase della norma sulla codifica interna, ma l'esempio e la dimensione stanno qui.

Quando il campo è presente, gli altri metadati, per esempio Content-Length, si riferiscono alla forma codificata, non alla risorsa originale, salvo dichiarazione esplicita. La norma dice che gli altri metadati riguardano la forma codificata, salvo dove la definizione dice altrimenti. Non è la stessa frase, e non la fondo con quella del 17 aprile sul campo della lunghezza.

Nell'elenco, br è un formato che usa la struttura dell'algoritmo Brotli definita nella RFC 7932. Quella RFC non l'ho aperta. zstd è un formato che usa la struttura Zstandard definita nella RFC 8878. Nemmeno quella l'ho aperta. L'esempio di più codifiche è deflate e poi gzip, nell'ordine in cui sono state applicate. Il campo Accept-Encoding, in questa pagina, è l'elenco che il client annuncia. Il server risponde con lo schema usato, indicato da Content-Encoding. Se il server usa gli schemi chiesti dal client dipende dalla configurazione e da ciò che sa fare. La pagina dice anche che la funzione è ampiamente disponibile da luglio 2015, e che alcune parti possono avere un supporto diverso. Luglio 2015 non è il 4 luglio 2025.

Il filtro, 22 ottobre 2026

Tre pagine di nginx hanno lo stesso last-modified, 22 ottobre 2026 alle 11:23:18 GMT. Nel testo che ho letto non c'è una seconda data. La pagina del modulo gzip descrive un filtro che comprime le risposte con il metodo gzip. Scrive che spesso aiuta a ridurre la dimensione dei dati trasmessi della metà o anche di più. È la frase di quella pagina. Non è una misura mia.

La direttiva è spenta di default. Il livello di compressione predefinito è 1, e i valori accettati vanno da 1 a 9. La lunghezza minima predefinita è 20. La lunghezza si determina solo dal campo Content-Length. Sulle richieste inoltrate, la compressione è spenta di default. La pagina decide che la richiesta è inoltrata se c'è il campo Via. Il valore che spegne la compressione per tutte le richieste inoltrate ignora gli altri parametri. Il valore che la accende per tutte le richieste inoltrate è un parametro distinto. Non li fondo.

I tipi aggiuntivi si sommano al tipo delle pagine HTML, che è il predefinito. Le risposte di quel tipo sono sempre compresse. Un valore speciale, dalla versione 0.8.29, corrisponde a qualunque tipo. Il segno non lo incollo. Un'altra direttiva, spenta di default, inserisce Vary con Accept-Encoding se sono attivi il filtro, il modulo dei file già compressi o il modulo che decomprime. La variabile del rapporto confronta la dimensione originale e quella compressa. Non ho letto un registro.

Queste pagine non dicono che cosa fa il filtro se la risposta ha già una codifica. Non lo invento. La nota sulla sicurezza della pagina del filtro non la copio.

Il modulo dei file già compressi manda un file con estensione .gz al posto del file ordinario. Non è compilato di default. Il valore sempre, dalla versione 1.3.6, usa il file compresso in ogni caso, senza controllare se il client lo supporta. La pagina consiglia che data e ora di modifica del file originale e di quello compresso siano uguali. Non è il filtro che comprime al volo.

Il modulo che decomprime decomprime le risposte che hanno Content-Encoding gzip per i client che non supportano gzip. Non è compilato di default. La pagina dice che è utile quando si vuole tenere i dati compressi per risparmiare spazio e ridurre il costo di lettura e scrittura. È una decompressione per chi non accetta gzip. Non è la frase del 17 aprile, che decomprime e poi comprime di nuovo.

Davanti ai visitatori, 17 aprile 2026

La pagina Content compression, letta il 3 novembre 2026, dice ultimo aggiornamento 17 aprile 2026. Nella risposta non c'è last-modified. Comprime in due direzioni: fra la rete e chi visita il sito, e fra la rete e il server di origine. Verso chi visita, supporta gzip, Brotli e Zstandard, oppure nessuna compressione, a seconda dei valori che il visitatore manda in accept-encoding, del piano, e di una regola di compressione che corrisponde alla richiesta. Zstandard verso i visitatori si può attivare con le regole di compressione. L'elenco dei tipi non lo ricopio.

Per le risposte di errore comprime solo se il codice è 403 o 404. Per le risposte riuscite comprime solo se il codice è 200. Gli altri codici non vengono compressi. Si può cambiare questo comportamento con le regole di compressione. La dimensione minima, quando manda la risposta a chi visita, è 48 byte per gzip e 50 byte per Brotli e Zstandard. Le risposte più piccole non vengono compresse, qualunque sia il tipo. Il 20 della pagina del filtro è un altro numero, letto solo da Content-Length, e vale per un altro programma. Non li unisco.

Quando comprime la risposta verso chi visita, può omettere Content-Length per non consegnare una lunghezza sbagliata a causa di trasformazioni dinamiche. Per conservare la lunghezza messa dall'origine, l'origine aggiunge cache-control no-transform. Quella direttiva impedisce di alterare la compressione, e la lunghezza passa com'è. Il campo va messo dall'origine: la pagina dice che non si aggiunge nelle richieste del client.

Quando chiede il contenuto all'origine, supporta Brotli, gzip o nessuna compressione. Se l'origine risponde con Brotli o gzip, tiene la stessa compressione verso chi visita se succedono tre cose insieme: la risposta dell'origine include content-encoding e nomina la compressione usata, br o gzip; il browser di chi visita supporta quell'algoritmo; non sono attive funzioni che cambiano il contenuto della risposta. Può anche convertire: ricevere compresso e servire non compresso, o il contrario, indipendentemente dalla cache. Se non si vuole che una risposta dell'origine sia codificata con Brotli o gzip verso chi visita, si disattiva con cache-control no-transform. La pagina usa quella direttiva in due punti. Non li riduco a una sola conseguenza oltre le parole che usa.

Una avvertenza dice che, verso chi visita, tiene conto del valore accept-encoding della richiesta del visitatore. Quando invece chiede il contenuto all'origine, manda un Accept-Encoding diverso, a supporto di Brotli e gzip. Nella sezione sui piani, su tutti i piani, la richiesta all'origine usa l'intestazione accept-encoding con br e gzip: chiede all'origine di mandare il contenuto compresso con Brotli o gzip, a seconda di quale metodo l'origine supporta. Verso chi visita il predefinito dipende dal piano, e la pagina aggiunge che la compressione effettiva può dipendere anche da ciò che il browser chiede. Nel piano gratuito il predefinito è Zstandard. Nei piani Pro e Business è Brotli. Nel piano Enterprise è gzip. Il predefinito verso chi visita e l'intestazione verso l'origine non sono la stessa frase.

Anche usando lo stesso algoritmo da un capo all'altro, la pagina dice che deve decomprimere la risposta e comprimerla di nuovo se per quella richiesta è attiva una di queste impostazioni: Automatic HTTPS Rewrites, Cloudflare Fonts, Email Address Obfuscation, Polish, Rocket Loader, JavaScript detections, RUM. Per spegnerle su percorsi specifici si crea una regola di configurazione. Una nota aggiunge che anche l'impostazione Replace insecure JS libraries richiede di decomprimere e comprimere di nuovo, e che al momento non si spegne con quelle regole. Decomprimere e ricomprimere, su questa pagina, non è la frase della norma sulla codifica applicata una seconda volta. La pagina non dice che chi visita riceve due codifiche elencate. Non lo aggiungo.

Che cosa non rimetto

La pagina sulla cache parla della copia di ieri. La pagina sulle misure parla di che cosa guardare prima di cambiare server. La pagina sullo status 103 dice che una risorsa non conservata in cache viene chiesta due volte: non è una risposta compressa due volte. La pagina sulla cartella chiusa parla di un'altra domanda. Non le ho riscritte.

Non ho copiato l'elenco dei tipi, gli esempi di configurazione, né il segno che corrisponde a qualunque tipo. Non ho aperto le RFC 1950, 1951, 1952, 7932 e 8878. Le tre pagine di nginx che ho aperto non descrivono un modulo Brotli. Non ne apro uno per riempire il vuoto.

Esempio ipotetico

prova.bottega.example è un nome di scuola. Non ho aperto quel nome e non ho letto una sua risposta.

Non le assegno gzip, Brotli, Zstandard, una seconda codifica, il livello da 1 a 9, il minimo 20, i 48 byte, i 50 byte, la metà in meno, un piano, né una funzione che decomprime e ricomprime. Non la pubblico, perché non l'ho misurata.

Che cosa questa pagina lascia stare

Non ho misurato un sito. Non ho riscritto la pagina sulla cache, la pagina sulle misure, la pagina sullo status 103 e la pagina sulla cartella chiusa. La copertina di questa pagina è nuova, perché la pagina è nuova.

Fonti lette il 3 novembre 2026. RFC 9110, pubblicata nel giugno 2022, senza last-modified nella risposta, sezioni 8.4 e 12.5.3, https://www.rfc-editor.org/rfc/rfc9110.html. Modulo gzip di nginx, last-modified 22 ottobre 2026 alle 11:23:18 GMT, https://nginx.org/en/docs/http/ngx_http_gzip_module.html. Modulo dei file già compressi, stesso last-modified, https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html. Modulo che decomprime, stesso last-modified, https://nginx.org/en/docs/http/ngx_http_gunzip_module.html. Content-Encoding, ultima modifica in pagina 4 luglio 2025, last-modified 3 novembre 2026 alle 00:53:27 GMT, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Encoding. Content compression, ultimo aggiornamento in pagina 17 aprile 2026, senza last-modified nella risposta, https://developers.cloudflare.com/speed/optimization/content/compression/.