In breve
Verifica quali risorse arrivano senza compressione, individua chi le serve e misura la correzione sulle risposte pubbliche del sito.
- Distinguere compressione, minificazione e rimozione del codice inutile
- Controllare HTML, CSS e JavaScript attraverso le risposte HTTP
- Coordinare hosting, CDN e cache senza sovrapporre configurazioni
- Confrontare trasferimenti e funzionamento prima e dopo l’intervento
Capire quale parte del caricamento può migliorare
La compressione riduce i byte necessari per trasmettere una risorsa; il browser la ricostruisce prima di utilizzarla. Il contenuto rimane lo stesso. Una pagina con molto JavaScript può quindi diventare più leggera durante il trasferimento e continuare a richiedere lavoro quando il codice viene eseguito.
La minificazione elimina elementi non necessari alla lettura del codice, mentre la rimozione delle risorse inutilizzate evita di inviarlo quando non serve. Sono interventi complementari, descritti anche nella guida a CSS e JavaScript inutilizzati.
Chiedi quale problema è stato rilevato: troppi dati, attesa del server o interazioni lente. La risposta aiuta a scegliere la modifica corretta e a evitare che una spunta attivata nel pannello venga presentata come soluzione a ogni rallentamento.
Preparare un campione di pagine e risorse
Scegli homepage, pagina servizio, articolo e uno dei percorsi più importanti, come richiesta di preventivo o prenotazione. Per ogni pagina individua il documento HTML e i principali file CSS e JavaScript. Annota indirizzo completo e dominio che li distribuisce: alcuni potrebbero essere esterni alla tua infrastruttura.
Ripeti le verifiche in condizioni documentate, distinguendo il primo caricamento dai file già disponibili nella cache del browser. Una visita che recupera una copia locale non permette di confrontare direttamente il trasferimento di una risorsa appena scaricata.
Consegna al tecnico un elenco circoscritto, non soltanto uno screenshot del punteggio. Dimensione della risorsa, quantità trasferita e tempo di risposta aiutano a capire dove esiste un margine concreto e quale fornitore può intervenire.
Controllare la risposta pubblica del server
Il browser comunica gli algoritmi accettati tramite l’intestazione Accept-Encoding. Il server indica quello applicato nella risposta con Content-Encoding: per Brotli il valore è br, per Gzip è gzip. La configurazione dichiarata nel pannello va quindi verificata sulle richieste reali.
| Controllo | Che cosa chiarisce |
|---|---|
| URL e tipo di file | Quale risorsa stai misurando |
| Content-Encoding | La compressione applicata |
| Dimensione trasferita | Quanti dati sono stati scaricati |
| Origine della risposta | Server, CDN o cache locale |
Un valore assente merita approfondimento, ma non autorizza una modifica indiscriminata: la risorsa potrebbe essere piccola, già compressa nel formato o gestita da un servizio esterno.
Stabilire se intervenire su hosting, server o CDN
Chiedi a chi gestisce il sito dove viene preparata la risposta: server web, applicazione, piattaforma ospitata o rete CDN. Un’impostazione sul server di origine può essere modificata dal livello che distribuisce pubblicamente i file. La prova finale deve raggiungere l’indirizzo usato dai visitatori.
Su un hosting gestito, la richiesta utile è una verifica delle risorse specifiche e degli algoritmi disponibili. Su infrastrutture amministrate direttamente, il tecnico può valutare configurazione, tipi di contenuto e file compressi preparati in anticipo. Il livello massimo di compressione non è sempre la scelta più efficiente per risposte generate a ogni richiesta.
Evita di attivare più plugin con lo stesso compito. Concorda un responsabile, salva la configurazione precedente e prova il cambiamento su un ambiente controllato quando l’architettura lo consente.
Coordinare le varianti compresse con la cache
Quando uno stesso indirizzo può produrre versioni con codifiche diverse, la cache deve distinguere le risposte appropriate ai client. Nella negoziazione HTTP è rilevante anche Vary: Accept-Encoding. Questo dettaglio va gestito dal tecnico insieme al comportamento effettivo della CDN e del server.
Immagini, archivi e video spesso utilizzano già formati compressi: comprimerli nuovamente può non offrire vantaggi. Il lavoro iniziale dovrebbe concentrarsi sulle risorse testuali individuate, senza applicare la stessa regola a ogni file del sito.
Se il browser continua a ricevere una versione precedente, controlla prima i vari livelli di cache. La guida alla cache del browser aiuta a separare riutilizzo dei file e riduzione del loro trasferimento: sono obiettivi collegati, con verifiche differenti.
Confrontare il risultato senza fermarsi a un avviso
Ripeti lo stesso campione dopo la modifica, con condizioni confrontabili. Registra codifica ricevuta, dimensione trasferita e tempi osservati. Non serve promettere una percentuale uguale per tutti: testo, dimensione iniziale e compressione precedente influenzano il margine disponibile.
Esempio ipotetico: il foglio di stile principale arriva più leggero, mentre il menu resta lento all’apertura. La prima correzione ha ridotto il trasferimento; il ritardo del menu richiede una verifica separata del lavoro eseguito dal browser. Non annullare una modifica utile soltanto perché un altro problema è ancora presente.
Controlla anche caricamento degli stili, script, moduli e pagine con autenticazione. Il risparmio di byte è una misura tecnica; il completamento dei percorsi conferma che il sito continua a funzionare correttamente.
Inserire il controllo nel processo di pubblicazione
Nuovi sottodomini, cambi di hosting o aggiornamenti della CDN possono cambiare il modo in cui vengono serviti i file. Conserva un piccolo campione di risorse da ricontrollare dopo questi interventi, con l’esito atteso e la persona responsabile della configurazione.
Nella consegna chiedi un riepilogo leggibile: problema osservato, livello su cui si è intervenuti, risorse coinvolte, prova eseguita e modalità per ripristinare la configurazione. È più utile di un elenco di ottimizzazioni attivate senza riscontri.
Se il trasferimento è già efficiente ma il caricamento resta lento, prosegui con la diagnosi generale delle prestazioni. La compressione è una parte del percorso: server, dipendenze, immagini e interazioni vanno valutati attraverso ciò che il visitatore sta realmente aspettando.
Domande frequenti
Brotli deve sostituire sempre Gzip?
La scelta dipende dal supporto dei sistemi, dal tipo di risorsa e dalla configurazione. Il server negozia una codifica compatibile; Gzip può restare disponibile per i client e i percorsi che lo richiedono.
Devo rinominare le pagine con un’estensione compressa?
Normalmente gli URL pubblici restano gli stessi. La compressione riguarda la risposta inviata al browser; l’eventuale gestione di file precompressi viene configurata sul server o nella piattaforma.
La compressione migliora automaticamente il posizionamento?
Non garantisce posizioni. Può ridurre i dati trasferiti e contribuire a un’esperienza più rapida quando quel trasferimento rappresenta un limite effettivo.
Fonti e approfondimenti
Riferimenti ufficiali per verificare le indicazioni e applicarle al proprio sito.
- Chrome for Developers: latenza del documento e compressione (si apre in una nuova scheda)
- MDN: compressione HTTP e negoziazione delle risposte (si apre in una nuova scheda)
- MDN: intestazione Content-Encoding (si apre in una nuova scheda)
- web.dev: ottimizzare codifica e trasferimento delle risorse testuali (si apre in una nuova scheda)