Brotli e Gzip: compressione web e controlli

Brotli e Gzip compressione web riducono la dimensione di risorse testuali come HTML, CSS, JavaScript, JSON e SVG. Il client comunica gli algoritmi supportati con Accept-Encoding e il server indica quello utilizzato con Content-Encoding.

Questa guida approfondisce Brotli e Gzip compressione con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.

Che cosa significa

Immagini JPEG, WebP, AVIF, video e archivi sono già compressi e ottengono poco beneficio. Comprimerli nuovamente può consumare CPU senza ridurre il trasferimento.

Quando esiste una CDN, la compressione può essere applicata all’edge indipendentemente dalla risposta tra origine e CDN.

Come riconoscere il problema

  • Content-Encoding è assente su CSS o HTML.
  • Il test mostra gzip ma non br.
  • La CDN comprime soltanto risposte cacheate.
  • File già compressi diventano più lenti.
  • La cache serve la variante sbagliata senza Vary.

Cause più frequenti

1. Client non supporta Brotli

Il server usa gzip o nessuna compressione. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

2. Tipo MIME escluso

La configurazione non comprime quella risorsa. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

3. Risposta troppo piccola

Il costo supera il beneficio. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

4. CDN o proxy

La compressione viene rimossa o ricalcolata. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

5. File precompressi

Il server non trova `.br` o `.gz` coerenti. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

6. Header Vary assente

Cache condivise mescolano varianti. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

Diagnosi passo per passo

  1. Controlla Accept-Encoding. Verifica gli algoritmi offerti dal client. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
  2. Leggi Content-Encoding. Controlla la risposta effettiva. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
  3. Confronta dimensione trasferita. Non confondere dimensione originale e download. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
  4. Testa tipi differenti. HTML, CSS, JS, JSON, SVG e immagini. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
  5. Verifica CDN e origine. Determina dove avviene la compressione. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
  6. Controlla Vary. La cache deve distinguere Accept-Encoding quando necessario. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
  7. Misura CPU e latenza. Livelli massimi dinamici possono essere costosi. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.

Metodo sicuro di diagnosi

Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.

Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.

Controllo incrociato

Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.

Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.

Procedura di risoluzione

  1. Abilita Brotli o Gzip nel livello gestito. Usa LiteSpeed o CDN senza regole duplicate. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  2. Comprimi tipi testuali. Mantieni esclusi formati già compressi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  3. Usa livelli equilibrati. Per compressione dinamica privilegia latenza e CPU. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  4. Precomprimi asset statici se supportato. Rigenera i file quando cambia l’originale. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  5. Correggi Vary e cache. Evita varianti incompatibili. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  6. Pulisci la CDN dopo le modifiche. Ritesta una risposta non obsoleta. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  7. Mantieni fallback Gzip. Client che non supportano Brotli devono ricevere una variante compatibile. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Verifica della stabilità dopo l’intervento

Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.

Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.

Controlli finali

  • HTML CSS e JS hanno Content-Encoding.
  • Immagini non sono ricomprese inutilmente.
  • Vary è coerente.
  • Dimensione trasferita diminuisce.
  • CPU resta stabile.

Prevenzione

  • Monitora header.
  • Usa CDN.
  • Rigenera precompressi.
  • Mantieni fallback.
  • Non comprimere archivi.

Errori da evitare

  • Non comprimere due volte.
  • Non forzare Brotli a client incompatibili.
  • Non usare il massimo livello dinamico senza misura.
  • Non confondere minificazione e compressione.
  • Non ignorare Vary.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:

  • URL risorsa
  • Accept-Encoding
  • Content-Encoding
  • uso CDN
  • dimensioni rilevate

Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

Verifica prolungata dopo la correzione

Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.

Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.

Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.

Domande frequenti su Brotli e Gzip compressione

Brotli è sempre migliore di Gzip?

Spesso comprime meglio i testi, ma costo, client e configurazione determinano il risultato.

Devo comprimere WebP o ZIP?

Normalmente no, sono già formati compressi.

Minificazione e Gzip sono la stessa cosa?

No. La minificazione modifica il testo; la compressione riduce i byte trasferiti.

Perché vedo gzip dietro Cloudflare?

Il risultato dipende dal client, dal piano e dalla risposta edge.

Che cosa indica Content-Encoding?

L’algoritmo applicato al corpo della risposta ricevuta.

Brotli e Gzip: compressione web e controlli ultima modifica: 2026-08-02T16:32:06+02:00 da Team tecnico Xlogic

Ti è piaciuto questo Post?