Quale dovrei implementare prima: gzip o HTTP/3?

Se le risposte testuali non sono compresse, di solito è più sensato verificare prima la compressione dei contenuti, come gzip o Brotli. Se la compressione funziona già correttamente, HTTP/3 può offrire miglioramenti aggiuntivi su reti con perdita di pacchetti o latenza e in presenza di molte richieste simultanee. Tuttavia, la priorità reale dipende dal fatto che l'immagine LCP, CSS o JavaScript che blocca il rendering, oppure il TTFB costituiscano il collo di bottiglia maggiore.

Mi serve ancora gzip se uso HTTP/3?

Sì. QPACK di HTTP/3 è un metodo di compressione per le intestazioni HTTP, mentre gzip è una codifica dei contenuti che comprime corpi di risposta quali HTML, CSS, JavaScript e JSON. Operano a livelli diversi e possono essere usati insieme.

Applicare gzip alle immagini le farà caricare più velocemente?

In generale, no. I file già compressi, come JPEG, WebP, AVIF, video e audio, in genere ottengono pochi vantaggi da un'ulteriore compressione con gzip e possono solo aggiungere overhead di elaborazione. Per le prestazioni delle immagini, contano di più dimensioni e formato appropriati e la priorità data alle immagini necessarie.

HTTP/3 riduce sempre il tempo di caricamento per ogni utente?

Non sempre. Grazie ai flussi indipendenti di QUIC, HTTP/3 può ridurre la misura in cui la perdita di pacchetti influisce su altri flussi, ma non risolve direttamente elaborazione server lenta, immagini grandi, risorse che bloccano il rendering o tempi di esecuzione JavaScript. HTTP/2 e HTTP/3 dovrebbero essere misurati separatamente in ambienti con utenti reali.

Posso fornire solo Brotli invece di gzip?

Il supporto per Brotli è ampiamente diffuso nei browser moderni, ma i server devono esaminare l'intestazione della richiesta Accept-Encoding e scegliere una codifica accettata dal client. Nella pratica, è comune offrire Brotli mantenendo gzip come fallback di compatibilità.

Cosa sono gzip e HTTP/3 e cosa migliorare prima per le prestazioni di caricamento delle pagine web?

Di 쉬었음.comPubblicato 12 settembre 2026

gzip è un metodo per ridurre la quantità di dati da trasmettere comprimendo i file di testo di una pagina web, mentre HTTP/3 è un protocollo che modifica il modo in cui vengono gestite le richieste multiple e affrontata la perdita di pacchetti distribuendo HTTP su QUIC. Entrambi possono contribuire al caricamento della pagina, ma non risolvono lo stesso problema. Anziché chiedersi «Quale è più veloce, gzip o HTTP/3?», è più corretto chiedersi prima dove si trova il collo di bottiglia della pagina corrente: byte trasferiti, perdita in rete, risposta del server, immagini, rendering o JavaScript.www.rfc-editor.org datatracker.ietf.org

Uno dei malintesi più comuni nella pratica è che abilitare HTTP/3 renda automaticamente più veloce un intero sito web. HTTP/3 può essere un importante miglioramento di base, ma non sostituisce le soluzioni per un'immagine above-the-fold eccessivamente grande, CSS o JavaScript che bloccano il rendering, oppure una risposta del server lenta. Al contrario, se un sito non comprime affatto le risposte testuali, abilitare gzip o Brotli può ridurre sensibilmente il volume trasferito con una modifica di configurazione relativamente piccola.web.dev developer.mozilla.org

Che cos'è esattamente gzip?

gzip è una codifica dei contenuti (Content-Encoding) ampiamente usata per HTTP. Un server comprime in formato gzip contenuti originali quali HTML, CSS, JavaScript, JSON, SVG e simili prima di inviarli, mentre il browser li decomprime e usa il contenuto originale. La specifica HTTP Semantics definisce gzip come una codifica di contenuto che usa una compressione della famiglia LZ77 e un CRC a 32 bit.www.rfc-editor.org www.rfc-editor.org

Il punto chiave è che il tipo logico del file non cambia. Per esempio, anche quando un server distribuisce app.js con gzip, il browser esegue in definitiva lo stesso JavaScript. Ciò che cambia è il numero di byte che attraversano la rete. Quando un file è più piccolo, richiede meno tempo per essere scaricato su una larghezza di banda limitata e può anche ridurre il consumo di dati mobili dell'utente.www.rfc-editor.org developer.chrome.com

Come scelgono browser e server un metodo di compressione?

I browser usano l'intestazione di richiesta Accept-Encoding per indicare quali formati di compressione possono decodificare. In base a tale elenco e alle relative priorità, il server seleziona una rappresentazione appropriata e aggiunge alla risposta un'intestazione come Content-Encoding: gzip o Content-Encoding: br. br indica Brotli.www.rfc-editor.org developer.mozilla.org

Se un server o una CDN fornisce risposte diverse per lo stesso URL a seconda del metodo di compressione, è comune inviare Vary: Accept-Encoding affinché le cache le distinguano. Altrimenti, una rappresentazione compressa memorizzata per un client potrebbe essere riutilizzata impropriamente per una richiesta con condizioni diverse.www.rfc-editor.org

Il flusso concettuale è il seguente:

Il browser dichiara i formati supportati, ad esempio Accept-Encoding: br, gzip.
Il server o la CDN sceglie una versione Brotli, gzip o non compressa del file.
Indica il formato selezionato in Content-Encoding insieme al corpo della risposta.
Il browser decomprime la risposta durante o dopo la ricezione, quindi continua con l'analisi dell'HTML, l'applicazione del CSS e l'esecuzione di JavaScript.

gzip può ridurre il tempo di trasferimento in questo processo, ma non elimina il tempo che il browser impiega per analizzare ed eseguire JavaScript. La compressione è un elemento delle prestazioni, non una soluzione per ogni causa di ritardo.developer.chrome.com web.dev

Quali file traggono vantaggio da gzip?

gzip è particolarmente adatto al testo con molte stringhe e strutture ripetute. Dati con una ripetizione significativa, come tag HTML, selettori CSS, identificatori e sintassi JavaScript, nonché nomi di campi JSON, possono diventare molto più piccoli per il trasferimento dopo la compressione. Le linee guida generali sulle prestazioni web raccomandano inoltre di applicare la compressione alle risorse di testo ed escludere gli asset già compressi.developer.mozilla.org web.dev

Tipo di asset	Valutazione generale per gzip	Aree da esaminare con priorità maggiore
HTML	Generalmente adatto	Tempo di risposta del server, caching, dimensione del documento
CSS	Generalmente adatto	Rimuovere CSS inutilizzato, gestire il CSS critico
JavaScript	Generalmente adatto	Code splitting, rimuovere codice inutilizzato, tempo di esecuzione
JSON e risposte API	Generalmente adatto	Progettazione della risposta, caching, rimuovere campi non necessari
SVG	Generalmente adatto	Ripulire e semplificare gli SVG
JPEG, WebP, AVIF	Generalmente non adatto	Dimensioni dell'immagine, formato, distribuzione responsiva
MP4 e audio	Generalmente non adatto	Bitrate, streaming, lazy loading

Per i formati che eseguono già autonomamente la compressione, quali JPEG, WebP, AVIF, video, audio e archivi compressi, applicare nuovamente gzip può offrire pochi vantaggi. Lo stesso vale per i file piccoli. web.dev spiega che le risorse inferiori a circa 1 KiB possono comprimersi in modo inefficiente o non offrire risparmi significativi.developer.mozilla.org web.dev

Una distinzione importante è quella fra dimensione trasferita e dimensione originale. Nel pannello Network degli strumenti per sviluppatori, è possibile confrontare la dimensione del download compresso con quella non compressa e verificare l'intestazione di risposta Content-Encoding per controllare se la compressione è stata effettivamente applicata.developer.chrome.com

In cosa differiscono gzip e Brotli?

Brotli non è un successore di gzip; è un altro algoritmo selezionabile insieme a gzip per la compressione dei contenuti HTTP. Sul web moderno, è comune dare priorità a Brotli per gli asset di testo offrendo al contempo gzip ai client che non possono usare Brotli. Poiché i browser inviano Accept-Encoding e i server negoziano il risultato, per lo stesso URL possono essere inviate rappresentazioni compresse diverse a seconda del client.developer.mozilla.org developer.mozilla.org

In generale, Brotli può produrre risultati più piccoli di gzip per il testo web. Tuttavia, questo non comporta sempre un miglioramento proporzionale della velocità di pagina complessiva percepita. Se i byte risparmiati sono pochi, o se il collo di bottiglia è rappresentato da immagini, elaborazione del server o esecuzione JavaScript, passare da gzip a Brotli può avere un effetto limitato. Sui server che comprimono dinamicamente, impostazioni che aumentano il rapporto di compressione possono anche aumentare l'uso della CPU e la latenza della risposta. Gli asset statici dovrebbero pertanto essere precompressi durante la fase di build o nella CDN, mentre le risposte dinamiche dovrebbero essere ottimizzate in base al carico effettivo.web.dev web.dev

In altre parole, i criteri di selezione assomigliano più ai seguenti che a «Brotli è sempre migliore»:

Se gli asset di testo sono grandi e i visitatori alla prima visita sono numerosi, considera di servire sia Brotli sia gzip.
Se una CDN fornisce già una compressione adeguata, non comprimere di nuovo lo stesso contenuto nell'applicazione.
Per un servizio dinamico con CPU server limitata, misura l'equilibrio tra livello di compressione e TTFB.
Se immagini e video costituiscono una grande quota della pagina, l'ottimizzazione dei contenuti multimediali può precedere la compressione del testo.

Cosa cambia HTTP/3?

HTTP/3 è uno standard che mantiene la semantica richiesta-risposta di HTTP sostituendo TCP con QUIC come base di trasporto. QUIC funziona su UDP, ma non è semplicemente un modo per inviare HTTP su UDP. Fornisce funzionalità quali instaurazione della connessione, crittografia, affidabilità, controllo della congestione e flussi multiplexati; HTTP/3 usa queste funzionalità per distribuire messaggi HTTP.datatracker.ietf.org developer.mozilla.org

HTTP/1.1 aveva limitazioni sostanziali nella gestione delle richieste su una singola connessione, perciò si è diffuso l'uso parallelo di più connessioni TCP. HTTP/2 ha migliorato questa situazione multiplexando più richieste su una connessione TCP. Tuttavia, poiché TCP garantisce la consegna ordinata dei dati ricevuti, quando un pacchetto si perde su una connessione, i dati arrivati successivamente non possono essere consegnati all'applicazione nell'ordine corretto finché la perdita non viene recuperata. In HTTP/2, questo ritardo a livello TCP può influire su più flussi HTTP.datatracker.ietf.org www.rfc-editor.org

QUIC di HTTP/3 gestisce la consegna affidabile e ordinata per singolo flusso. Di conseguenza, la perdita di dati su un flusso non richiede necessariamente l'interruzione anche dei flussi non correlati. RFC 9000 spiega che, quando un pacchetto si perde, solo i flussi che contengono dati di quel pacchetto rimangono bloccati in attesa della ritrasmissione, mentre gli altri flussi possono continuare.www.rfc-editor.org

Quanto è accurata l'espressione «elimina l'head-of-line blocking»?

Ciò che HTTP/3 affronta principalmente è l'head-of-line blocking a livello di trasporto sull'intera connessione. È inesatto interpretarlo come se ogni attesa scomparisse.

Innanzitutto, l'ordine continua a essere importante all'interno di un singolo flusso. Se una porzione precedente va persa nello stesso flusso, ad esempio il corpo di un documento HTML o una grande immagine, i dati successivi di quel flusso non possono essere utilizzati completamente finché non viene ripristinato l'ordine richiesto. In secondo luogo, se dati di più flussi erano inclusi in un unico pacchetto QUIC, la perdita di quel pacchetto può ritardare simultaneamente più flussi.www.rfc-editor.org

I vantaggi di HTTP/3 possono quindi risultare particolarmente evidenti sulle reti in cui si verificano perdita o riordinamento di pacchetti. Al contrario, visualizzando una pagina piccola su una connessione cablata a bassa latenza e bassa perdita, la differenza rispetto a HTTP/2 può essere ridotta o variare in base alle condizioni di misurazione. HTTP/3 non è infatti una tecnologia che riduce magicamente i byte: è un'architettura che riduce la misura in cui l'attesa nel trasporto si propaga.datatracker.ietf.org www.rfc-editor.org

In cosa QPACK di HTTP/3 differisce da gzip?

HTTP/3 include un meccanismo di compressione delle intestazioni chiamato QPACK. Questo può far credere erroneamente che HTTP/3 includa gzip, ma si applicano a obiettivi differenti. QPACK è progettato per rappresentare in modo efficiente i campi di intestazione nelle richieste e risposte HTTP, quali Cookie, Content-Type e Cache-Control. gzip e Brotli sono codifiche dei contenuti che comprimono i corpi delle risposte, quali HTML, CSS e JavaScript.datatracker.ietf.org www.rfc-editor.org

HPACK di HTTP/2 si basa sull'ipotesi che lo stato della compressione delle intestazioni venga distribuito in sequenza, ma questa ipotesi è difficile da applicare invariata all'architettura a flussi indipendenti di QUIC. QPACK usa flussi unidirezionali separati per gestire lo stato della tabella dinamica, consentendo alle implementazioni di bilanciare l'efficienza di compressione con il rischio di blocco delle intestazioni.datatracker.ietf.org datatracker.ietf.org

Dal punto di vista delle prestazioni effettive della pagina, è utile considerare i rispettivi ruoli così:

gzip e Brotli: riducono il volume di trasferimento dei corpi di testo.
QPACK: migliora l'efficienza di trasmissione delle intestazioni di richiesta e risposta.
HTTP/3 e QUIC: riducono la misura in cui i ritardi di trasporto dovuti a richieste multiple e condizioni di perdita si propagano ad altre richieste.
Caching: impedisce che le risorse già ricevute vengano trasferite di nuovo.
Ottimizzazione delle immagini e del codice: riduce la quantità di lavoro che deve essere scaricata ed elaborata in primo luogo.

Non sono opzioni concorrenti fra cui sceglierne una sola; sono approcci complementari a colli di bottiglia diversi.

Quali sono i colli di bottiglia più importanti nella velocità percepita di una pagina web?

La velocità di caricamento percepita dagli utenti non è un singolo numero. Il tempo fino all'invio del primo byte da parte del server, il tempo fino a quando diventa visibile il contenuto principale above-the-fold e il tempo fino a quando pulsanti e campi di input rispondono possono essere ritardati ciascuno da cause diverse. In particolare, LCP (Largest Contentful Paint) rappresenta il punto in cui viene renderizzata l'immagine, il blocco di testo o il video più grande nel viewport, risultando utile per valutare l'esperienza iniziale della pagina.web.dev

Un LCP lento non significa sempre che la causa sia la compressione di rete. web.dev raccomanda di separare TTFB, ritardo nel caricamento della risorsa, tempo di caricamento della risorsa e ritardo di rendering dell'elemento nella diagnosi di LCP. Per esempio, anche se un'immagine viene scaricata rapidamente, CSS di grandi dimensioni può bloccare il rendering oppure il thread principale può essere troppo impegnato in attività JavaScript lunghe per visualizzare l'immagine.web.dev

Quando il collo di bottiglia è l'immagine above-the-fold

L'elemento above-the-fold più grande è spesso un'immagine, come una grande foto prodotto in una pagina di dettaglio, un'immagine principale nella homepage di un sito di notizie o un banner su una pagina di viaggi. In questa situazione, abilitare gzip non aiuta molto i file JPEG, WebP o AVIF stessi. Un approccio più efficace consiste nel servire immagini dimensionate per le loro dimensioni di visualizzazione, usare formati moderni appropriati ed evitare di ritardare l'immagine LCP con loading="lazy". Quando necessario, puoi fornire un hint di priorità usando fetchpriority="high", ma assegnare indiscriminatamente alta priorità a molte immagini può invece creare competizione.web.dev web.dev

Quando il collo di bottiglia è CSS e JavaScript

Il CSS ha caratteristiche di blocco del rendering perché impedisce al contenuto di apparire senza stile. Tuttavia, CSS troppo grande, CSS non necessario per la visualizzazione iniziale e script caricati in modo sincrono possono ritardare la visualizzazione del contenuto principale. Anche dopo che il trasferimento è terminato, grandi bundle JavaScript usano il thread principale del browser per analisi, compilazione ed esecuzione, quindi ridurre solo la dimensione del download con gzip potrebbe non essere sufficiente.developer.chrome.com web.dev

Le prestazioni JavaScript dovrebbero quindi essere esaminate separatamente dalla compressione. Tra le opzioni possibili vi sono rimuovere il codice inutilizzato, caricare in modo differito funzionalità non necessarie per la visualizzazione iniziale, suddividere le attività lunghe e, ove possibile, usare rendering lato server o prerendering affinché l'HTML iniziale esponga contenuti e risorse principali alla scoperta. Tuttavia, il rendering lato server può anche aumentare il tempo di elaborazione del server e influire sul TTFB, pertanto le modifiche architetturali dovrebbero essere valutate mediante misurazione.web.dev

Quando il collo di bottiglia è la risposta del server e il caching

Quando il TTFB è lungo, il browser fatica a scoprire le risorse successive prima di ricevere l'HTML. Cause comuni includono un server geograficamente distante, lunghi processi di database e personalizzazione, reindirizzamenti non necessari e opportunità di caching inutilizzate. HTTP/3 può migliorare una parte della fase di trasferimento in questa situazione, ma non riduce direttamente il tempo necessario al server per generare la prima risposta.web.dev

Il caching ha una natura diversa dagli altri miglioramenti delle prestazioni. gzip invia gli stessi dati in una forma più piccola, HTTP/3 modifica le caratteristiche della connessione usata per distribuire i dati e il caching impedisce che i dati vengano inviati di nuovo nelle visite ripetute che soddisfano le condizioni. Per un servizio con un'alta quota di visitatori di ritorno, una politica di caching appropriata può produrre una differenza percepita maggiore rispetto al cambio di algoritmi di compressione. Tuttavia, le strategie di caching per risposte che cambiano frequentemente o variano per utente, come l'HTML, devono essere progettate con maggiore attenzione.www.rfc-editor.org developer.chrome.com

Qual è la classifica pratica dei miglioramenti delle prestazioni per impatto percepito?

Non esiste una classifica fissa applicabile a ogni sito. I risultati differiscono in base alla composizione della pagina, al rapporto fra visitatori alla prima visita e di ritorno, alle reti degli utenti, alla posizione dei server e alla configurazione esistente. Tuttavia, per le tipiche pagine di contenuti, commercio e servizi in cui rimangono colli di bottiglia importanti, il seguente ordine è pratico per l'analisi.

Individua cosa ritarda il contenuto principale above-the-fold. Esamina prima dimensione, tempo di scoperta e priorità dell'immagine LCP; CSS che blocca il rendering; JavaScript sincrono; e rendering lato client non necessario.web.dev
Rivedi il tempo di risposta del server e il caching. Controlla TTFB, reindirizzamenti, posizionamento della CDN, caching degli asset statici e ritardi nell'elaborazione backend.web.dev www.rfc-editor.org
Controlla la compressione del testo per HTML, CSS, JavaScript e JSON. Se non sono compressi, applicare gzip o Brotli ha alta priorità. Se sono già compressi correttamente, i guadagni aggiuntivi nella stessa area possono essere limitati.developer.mozilla.org developer.chrome.com
Riduci il volume totale trasferito e ottimizza la composizione delle richieste. Ripulisci immagini grandi, script e risorse di terze parti e rimanda le richieste finché non sono realmente necessarie. Payload di rete grandi sono associati a tempi di caricamento lunghi.developer.chrome.com developer.chrome.com
Offri HTTP/3, mantieni un fallback HTTP/2 e convalidalo con traffico reale. Confronta i risultati prima e dopo, soprattutto su ambienti mobili, ad alta latenza e con perdita di pacchetti, nonché su pagine con molte richieste simultanee.datatracker.ietf.org www.rfc-editor.org

Questa classifica presenta eccezioni importanti. Se un'applicazione ha risposte testuali non compresse superiori a 1 MB, applicare gzip o Brotli al punto 3 può essere il maggiore miglioramento a breve termine. Al contrario, se un'immagine principale occupa diversi MB e il testo è già compresso con Brotli, l'ottimizzazione dell'immagine ha priorità. Se il server non riesce a generare l'HTML per diversi secondi, il lavoro su backend e caching precede HTTP/3.developer.mozilla.org web.dev developer.chrome.com

Se confronti soltanto gzip e HTTP/3

Se devi scegliere soltanto fra queste due tecnologie, la decisione è relativamente semplice.

Quando il testo non è compresso: gzip o Brotli vengono di solito prima. Riducono la quantità di dati da trasmettere, quindi ci si possono aspettare vantaggi su ogni connessione supportata.
Quando la compressione funziona già correttamente: aumenta il valore relativo di HTTP/3. Tuttavia, il miglioramento effettivo dipende dalla qualità della rete e dalla struttura delle richieste.
Per pagine ricche di immagini e video: né gzip né HTTP/3 da soli probabilmente risolveranno il problema maggiore. L'ottimizzazione dei contenuti multimediali viene prima.
Per grandi applicazioni JavaScript: gzip è solo un punto di partenza. Devi esaminare anche i costi di esecuzione successivi al trasferimento per ottenere un miglioramento percepito continuo.
Per servizi con molte visite di ritorno: i tassi di cache hit possono essere una variabile più importante del cambio dei metodi di compressione.

Pertanto, nessuna delle due conclusioni — «gzip viene sempre prima di HTTP/3» oppure «HTTP/3 è più nuovo, quindi viene sempre prima» — è corretta. Un'affermazione più precisa è: la compressione dei contenuti è la priorità di base per il testo non compresso, mentre HTTP/3 è un'ottimizzazione fondamentale che può offrire vantaggi aggiuntivi in base alle condizioni di trasporto e ai modelli di richiesta.

Quali vincoli considerare nell'adozione di HTTP/3?

Per offrire HTTP/3, server, CDN, bilanciatori del carico, firewall e strumenti di osservabilità devono poter gestire adeguatamente QUIC e il traffico basato su UDP. Poiché alcuni client o percorsi potrebbero non poter usare HTTP/3, è generalmente appropriata una distribuzione graduale che fornisca anche HTTP/2 o HTTP/1.1. Lo standard HTTP/3 si basa su QUIC e definisce il processo con cui un client scopre un server HTTP/3 e stabilisce poi una connessione QUIC.datatracker.ietf.org

Dal punto di vista operativo, è importante non giudicare il successo in base al solo cambio di protocollo. Monitora insieme quota di connessioni HTTP/3, tassi di errore e ritento, TTFB, LCP, tassi di errore e utilizzo della CPU. In particolare, quando una CDN o un proxy si trova davanti all'origine, il protocollo visibile sul server origin può differire da quello effettivamente usato dal browser dell'utente finale, quindi occorre includere anche l'osservazione lato client.developer.chrome.com developer.chrome.com

Esistono considerazioni di sicurezza per la compressione?

Sì. Anche con HTTPS, se input controllato da un attaccante e valori segreti vengono compressi insieme nello stesso contesto di compressione, un attaccante potrebbe riuscire a dedurre il segreto osservando differenze nella lunghezza del testo cifrato. Le specifiche HTTP Semantics e HTTP/3 mettono in guardia dalle situazioni in cui dati sensibili e dati controllati da un attaccante vengono compressi insieme e identificano la disabilitazione della compressione per dati sensibili o la separazione dei contesti di compressione come mitigazioni più affidabili.www.rfc-editor.org www.rfc-editor.org

Questo non significa che ogni risposta gzip sia pericolosa. La domanda chiave è se esistano contemporaneamente input utente riflesso, segreti legati all'autenticazione e condizioni che permettano a un attaccante di effettuare ripetutamente richieste e osservare le dimensioni delle risposte. Ai flussi sensibili come login, pagamento e recupero dell'account non dovrebbero essere applicate meccanicamente le stesse politiche di compressione degli asset statici generali; dovrebbero essere riesaminati insieme alla progettazione della sicurezza.www.rfc-editor.org datatracker.ietf.org

Cosa dovrei misurare sul mio sito?

È più sicuro convalidare i miglioramenti delle prestazioni attraverso l'esperienza di utenti reali piuttosto che tramite un singolo punteggio di laboratorio. Lighthouse è utile per identificare rapidamente potenziali problemi, ma non rappresenta tutti gli utenti reali su reti, dispositivi, stati della cache e regioni diverse. Usare gli strumenti per sviluppatori insieme al monitoraggio degli utenti reali facilita la separazione fra ipotesi e risultati.developer.chrome.com developer.chrome.com

Puoi analizzare le prestazioni nel seguente ordine:

Controlla lo stato di trasferimento attuale. Nel pannello Network, esamina Content-Encoding, dimensione trasferita e dimensione originale per risposte HTML, CSS, JS e JSON importanti.developer.chrome.com
Controlla il protocollo. Nella colonna Protocol, verifica se le richieste effettive usano h3, h2 o http/1.1.
Segmenta le metriche utente principali. Confronta TTFB, LCP e metriche di interazione per prima visita rispetto a visita di ritorno, mobile rispetto a desktop, regione e tipo di rete.web.dev web.dev
Modifica una cosa alla volta. Se distribuisci simultaneamente l'abilitazione di gzip, il supporto Brotli, la sostituzione delle immagini, la suddivisione di JavaScript e l'abilitazione di HTTP/3, è difficile identificare quale modifica abbia prodotto un effetto.
Registra anche gli effetti collaterali. Monitora inoltre CPU del server, tassi di errore, tassi di cache hit e tassi di errore o fallback delle connessioni HTTP/3.

Per esempio, se il passaggio di un bundle JavaScript non compresso a gzip riduce la dimensione trasferita ma modifica appena l'LCP, il collo di bottiglia successivo è probabilmente una grande immagine, CSS o l'esecuzione JavaScript, non la compressione. Al contrario, se la coda lunga dell'LCP migliora per gli utenti su rete mobile dopo l'adozione di HTTP/3, puoi identificare vantaggi in ambienti ad alta perdita e alta latenza oltre a osservare le medie. Tali conclusioni partono dai colli di bottiglia misurati, non dal nome di una tecnologia.web.dev www.rfc-editor.org

Riepilogo: considera gzip e HTTP/3 come ruoli complementari, non come una gara di priorità

gzip e HTTP/3 sono entrambi utili per le prestazioni web, ma la base del confronto fra loro è diversa. gzip riduce i byte trasferiti per le risposte testuali, mentre HTTP/3 può ridurre tramite i flussi multiplexati basati su QUIC l'impatto che la perdita in rete esercita su più richieste. QPACK di HTTP/3 è compressione delle intestazioni; non sostituisce la compressione dei corpi gestita da gzip e Brotli.www.rfc-editor.org datatracker.ietf.org datatracker.ietf.org

La priorità più pratica è identificare prima il collo di bottiglia effettivo fra LCP, TTFB, blocco del rendering, JavaScript, immagini e caching; colmare l'assenza della compressione del testo come base; quindi convalidare HTTP/3 in condizioni di utenti reali. Le prestazioni non consistono nell'aggiungere una nuova tecnologia: consistono nell'accorciare il percorso più lungo che l'utente deve attendere.web.dev developer.chrome.com

Ulteriori letture

Specifiche HTTP Semantics e codifica dei contenutiwww.rfc-editor.org
Standard HTTP/3datatracker.ietf.org
Standard di compressione delle intestazioni QPACKdatatracker.ietf.org
Specifica di trasporto QUICwww.rfc-editor.org
Linee guida per le prestazioni web e l'ottimizzazione LCPweb.dev
Panoramica sulla compressione HTTPdeveloper.mozilla.org