Differenze tra HTTP/2 e HTTP/3

HTTP/2 e HTTP/3 a confronto: cosa verificare prima di cambiare protocollo

• Trasporto: HTTP/2 usa TCP, HTTP/3 usa QUIC sopra UDP.
• Limite risolto: HTTP/3 elimina il blocco di tutti i flussi quando un pacchetto si perde, problema che in HTTP/2 resta a livello di trasporto.
• Sicurezza: in HTTP/3 TLS 1.3 è integrato e obbligatorio, in HTTP/2 è un livello separato richiesto di fatto dai browser.
• Standardizzazione: HTTP/2 è una specifica del 2015, HTTP/3 è diventato standard RFC a giugno 2022.
• Quale scegliere: su reti mobili o instabili HTTP/3 riduce la latenza percepita, su banda larga stabile la differenza si assottiglia.
• Come si verifica: il protocollo usato da una pagina si legge dagli strumenti per sviluppatori del browser, non si assume a priori.

Le differenze principali tra HTTP/2 e HTTP/3

La differenza che conta non riguarda ciò che il browser scarica (HTML, CSS, immagini, script), ma il modo in cui i pacchetti che li trasportano attraversano la rete. Il protocollo non cambia la sitemap, gli URL o il contenuto delle pagine: cambia il trasporto sottostante, e con esso la tenuta della connessione quando qualcosa va storto.

HTTP/2, pubblicato nel 2015, ha risolto il collo di bottiglia di HTTP/1.1 introducendo il multiplexing su una singola connessione TCP: più richieste e risposte viaggiano insieme, senza aprire connessioni parallele per ogni risorsa. HTTP/3 mantiene lo stesso principio di multiplexing, ma lo sposta su QUIC, un trasporto costruito sopra UDP invece che su TCP.

La conseguenza pratica riguarda la gestione degli errori di rete. Con HTTP/2, se un pacchetto TCP si perde, tutti i flussi aperti sulla stessa connessione restano fermi finché quel pacchetto non viene ritrasmesso: è il cosiddetto head-of-line blocking a livello di trasporto, e nessuna ottimizzazione lato server lo risolve, perché dipende da TCP, non da HTTP. Con HTTP/3 questo non succede: QUIC gestisce ogni flusso in modo indipendente, quindi un pacchetto perso rallenta solo quel flusso.

Su una connessione in fibra stabile, con pochi pacchetti persi, la differenza si nota poco. Su una rete mobile che perde pacchetti con regolarità, invece, si vede: per questo le fonti tecniche concordano nell’indicare HTTP/3 come il protocollo che cambia le cose sulle reti instabili, non su quelle pulite.

Per chi gestisce un piano di hosting condiviso o un server dedicato, la scelta del protocollo dipende dal software installato e dal provider: si attiva a livello di infrastruttura, non da WordPress o da un altro CMS.

HTTP/1.1, il protocollo da cui partono le due evoluzioni

HTTP/1.1, standardizzato nel 1997, gestiva una richiesta alla volta per connessione: per scaricare dieci risorse di una pagina servivano dieci round trip in sequenza, oppure più connessioni TCP aperte in parallelo dal browser. Era un modello pensato per pagine con pochi oggetti, non per i siti moderni con decine di immagini, script e fogli di stile.

HTTP/2 e HTTP/3 nascono entrambi per superare questo limite, ma con due strategie diverse: il primo lavora sopra lo stesso trasporto di HTTP/1.1, cambiando il modo in cui le richieste viaggiano; il secondo cambia anche il trasporto. Per la definizione completa del protocollo e delle sue versioni precedenti rimando alla pagina dedicata a HTTP.

HTTP/2: multiplexing su TCP e il limite del head-of-line blocking

HTTP/2 richiede nei fatti una connessione cifrata: la specifica non lo impone, ma tutti i browser principali attivano il protocollo solo su siti in HTTPS. Un sito senza HTTPS resta su HTTP/1.1 anche se il server supporta HTTP/2.

Le novità rispetto a HTTP/1.1 sono tre. Il formato binario sostituisce il testo in chiaro e riduce il lavoro di analisi dei messaggi. Il multiplexing permette di inviare più richieste e ricevere più risposte in parallelo sulla stessa connessione TCP, eliminando la coda che bloccava HTTP/1.1. La compressione delle intestazioni con HPACK riduce il peso dei metadati scambiati a ogni richiesta, cookie compresi.

Il limite resta nel trasporto: il multiplexing di HTTP/2 vive sopra TCP, e TCP garantisce che i dati arrivino in ordine. Se un pacchetto si perde, TCP ferma la consegna di tutto ciò che viene dopo finché quel pacchetto non viene ritrasmesso, anche se i dati dei flussi successivi sono già arrivati al client. È il punto che genera più confusione tra chi non segue questi temi tutti i giorni: si pensa che il multiplexing risolva anche questo, invece risolve solo il collo di bottiglia applicativo, non quello di rete.

Per un e-commerce con molte immagini prodotto, questo significa che su una connessione instabile un singolo pacchetto perso può rallentare il caricamento dell’intera pagina, anche se il server ha già inviato tutto il resto.

HTTP/3: QUIC, handshake rapido e migrazione di connessione

HTTP/3 abbandona TCP e si appoggia a QUIC, un trasporto costruito sopra UDP, con la crittografia integrata invece che a parte: a differenza di HTTP/2, dove TLS resta un livello separato, in HTTP/3 è richiesto sempre.

I tre vantaggi che QUIC porta rispetto a TCP riguardano situazioni specifiche, non il caricamento in generale. Il primo è l’handshake: HTTP/2 apre la connessione TCP e poi negozia TLS separatamente, per due o tre round trip prima che parta il primo dato utile. QUIC integra TLS 1.3 nel protocollo stesso e riduce l’handshake a un solo round trip; per un client che ha già visitato il dominio, può arrivare a zero round trip, inviando subito i dati (0-RTT).

Il secondo è l’head-of-line blocking, che a livello di trasporto sparisce perché QUIC gestisce ogni flusso in modo indipendente. Il terzo è la migrazione di connessione: se un utente passa dal Wi-Fi di casa alla rete mobile, l’indirizzo IP cambia, e con TCP questo significa chiudere la connessione e riaprirla da zero. QUIC identifica la connessione con un ID indipendente dall’IP, quindi la sessione resta attiva anche durante il cambio di rete. Un vantaggio che conta per chi guarda analytics da mobile, streaming video o applicazioni in tempo reale.

Per la compressione delle intestazioni, HTTP/3 usa QPACK invece di HPACK: la logica è la stessa, ma tiene conto del fatto che QUIC non garantisce l’ordine di arrivo come TCP. Sono dettagli tecnici che raramente interessano chi gestisce un sito, ma spiegano perché i due protocolli non sono intercambiabili a livello di configurazione server.

Tabella comparativa tra HTTP/1.1, HTTP/2 e HTTP/3

Mettere le tre versioni una accanto all’altra aiuta a capire dove si gioca la differenza: non nelle funzionalità percepite dall’utente, ma in come i dati vengono trasportati e protetti.

Quando passare a HTTP/3 fa davvero la differenza

La mia posizione, basata su quello che i test di performance pubblicati documentano, è che HTTP/3 non è un aggiornamento che cambia tutto per tutti i siti: cambia parecchio per alcuni profili di traffico e quasi niente per altri.

Se il traffico è prevalentemente mobile o internazionale

Se in Search Console risulta che buona parte del traffico arriva da dispositivi mobili, da zone con copertura di rete discontinua o da un pubblico geograficamente lontano dal server, HTTP/3 riduce la latenza percepita grazie all’handshake più rapido e alla resistenza alla perdita di pacchetti. Vale anche per i siti con molte risorse da scaricare, come un e-commerce con gallerie prodotto estese: un pacchetto perso su un’immagine non blocca più il caricamento di CSS e JavaScript.

Se il pubblico naviga da desktop su banda larga stabile

Su connessioni fisse e stabili, con pochi pacchetti persi, il vantaggio di QUIC rispetto a TCP si riduce molto. In questo scenario il tempo speso a verificare e configurare HTTP/3 lato server rende meglio se investito altrove: ottimizzazione delle immagini, caching, riduzione del peso delle risorse critiche.

Sull’adozione reale di HTTP/3 nel traffico di un sito specifico non esiste un numero valido in generale: dipende dal mix di browser e provider dei visitatori, e si verifica guardando i dati di protocollo nelle richieste reali, non stimandolo a tavolino.

Come verificare quale protocollo usa un sito e cosa serve per attivare HTTP/3

Prima di chiedersi se attivare HTTP/3, va verificato cosa sta già usando il sito: la versione del protocollo si negozia tra browser e server, non è una scelta che si fa dal CMS.

1. Apri gli strumenti per sviluppatori del browser sulla scheda che mostra le richieste di rete.
2. Aggiungi alla visualizzazione la colonna relativa al protocollo, se non è già visibile.
3. Ricarica la pagina una seconda volta: al primo accesso a un dominio il browser negozia quasi sempre su HTTP/2, e passa a HTTP/3 solo dopo che il server lo ha segnalato come disponibile.
4. Controlla il valore riportato per ogni risorsa: le sigle comuni sono h2 per HTTP/2 e h3 per HTTP/3.
5. Ripeti il controllo su più risorse della stessa pagina, perché contenuti di terze parti come font o script esterni possono viaggiare su un protocollo diverso da quello del dominio principale.

Se il risultato mostra solo HTTP/2 e vale la pena valutare HTTP/3, il primo passo riguarda l’infrastruttura, non il sito: bisogna verificare se il software del server web e il piano di hosting lo supportano, perché è una capacità che si abilita a livello di server o di rete di distribuzione dei contenuti, non con un plugin. Chi si appoggia a una edge function spesso lo trova già disponibile senza doverlo configurare manualmente.

Un punto sottovalutato: attivare HTTP/3 non richiede modifiche al codice del sito, ma richiede che il dominio sia raggiungibile anche su UDP, oltre che su TCP, cosa che non tutti i firewall aziendali permettono di default.

Errori frequenti e casi limite da conoscere

L’errore più comune è applicare a HTTP/2 le ottimizzazioni pensate per HTTP/1.1: concatenare tutti i file CSS e JavaScript in uno solo, unire le icone in uno sprite, distribuire le risorse su più domini. Con HTTP/1.1 queste tecniche riducevano il numero di connessioni necessarie; con HTTP/2, che gestisce già richieste multiple in parallelo sulla stessa connessione, spesso peggiorano le prestazioni, perché costringono il browser a scaricare codice che non gli serve subito o aprono connessioni TCP aggiuntive che intralciano la gestione delle priorità.

Il secondo errore è dare per scontato che HTTP/3 sia già attivo solo perché il server lo supporta: se il firewall della rete da cui si naviga blocca il traffico UDP, il browser torna automaticamente a HTTP/2 senza avvisare nessuno, e un test di performance rischia di confrontare due scenari diversi senza che chi lo esegue se ne accorga.

Il terzo caso limite riguarda i contenuti di terze parti: font, tag di tracciamento, script pubblicitari possono essere serviti da un’infrastruttura diversa da quella del sito, con un protocollo diverso. Verificare il protocollo sulla propria pagina non dice niente sul protocollo usato da quelle risorse esterne, e non è qualcosa su cui si ha controllo diretto.

Capita spesso che un cliente insista per passare subito a HTTP/3 come fosse una casella da spuntare in una checklist SEO. È invece una condizione infrastrutturale che aiuta certi pubblici più di altri, e va valutata guardando i dati di traffico reali in Search Console, non la moda del momento.

Domande frequenti su HTTP/2 e HTTP/3

Qual è la differenza principale tra HTTP/2 e HTTP/3?

HTTP/2 trasporta i dati su TCP, HTTP/3 su QUIC, costruito sopra UDP. La conseguenza pratica è che HTTP/3 non blocca tutti i flussi quando un singolo pacchetto si perde, mentre HTTP/2 sì, perché quel limite dipende da TCP, non dal livello applicativo.

HTTP/3 è sempre più veloce di HTTP/2?

No, il guadagno è concreto su reti mobili, instabili o ad alta latenza e per i visitatori di ritorno. Su connessioni fisse e stabili, con pochi pacchetti persi, la differenza percepita resta minima.

HTTP/2 richiede sempre HTTPS?

La specifica non lo impone, ma tutti i browser principali attivano HTTP/2 solo su connessioni HTTPS tramite l’estensione ALPN. Un sito senza HTTPS resta quindi su HTTP/1.1 anche se il server supporta HTTP/2.

Come si verifica quale protocollo usa un sito?

Dagli strumenti per sviluppatori del browser, nella scheda di rete, aggiungendo la colonna del protocollo. Va controllato con una ricarica a cache calda, perché al primo accesso il browser negozia quasi sempre su HTTP/2.

Cosa serve per attivare HTTP/3 su un server?

Serve che il software del server web e il piano di hosting supportino QUIC, e che la rete permetta il traffico UDP verso il dominio, non solo TCP. Non è una modifica che si fa dal codice del sito.

HTTP/3 sostituisce completamente HTTP/2?

No, convive con esso. Se il client o la rete non supportano QUIC, la connessione ricade automaticamente su HTTP/2, senza che l’utente se ne accorga.

HTTP/2 e HTTP/3 influenzano direttamente il posizionamento?

Non in modo diretto: migliorano la velocità di caricamento, uno dei fattori che compongono le Core Web Vitals. L’effetto sul posizionamento passa da lì, non dal protocollo in sé.