HTTP/3 e QUIC nel 2026: cos’è, come funziona e perché può velocizzare un sito

HTTP/3 è la più recente evoluzione principale del protocollo HTTP e nel 2026 è ormai una tecnologia concreta utilizzata da browser, CDN e web server moderni.

La differenza più importante rispetto a HTTP/1.1 e HTTP/2 non riguarda soltanto il modo in cui vengono trasmesse le pagine web. HTTP/3 cambia anche il protocollo utilizzato a livello di trasporto: al posto di TCP utilizza QUIC, un protocollo moderno costruito sopra UDP.

L’obiettivo è ridurre alcune delle limitazioni delle connessioni TCP tradizionali, migliorare la gestione di più flussi simultanei e offrire prestazioni più stabili soprattutto su reti con latenza elevata, perdita di pacchetti o frequenti cambiamenti di connessione.

Ma HTTP/3 rende davvero un sito più veloce? Conviene abilitarlo? Qual è la differenza rispetto a HTTP/2? E perché LiteSpeed, CDN e browser moderni lo utilizzano?

In questa guida analizziamo HTTP/3 e QUIC dal punto di vista pratico, evitando promesse irrealistiche e cercando di capire quando il nuovo protocollo può offrire un vantaggio reale.

HTTP/3: cos’è

HTTP/3 è la terza grande versione del protocollo utilizzato dai browser per comunicare con i server web.

È standardizzato dalla IETF attraverso la RFC 9114 dedicata a HTTP/3.

HTTP continua a definire concetti familiari come:

• richieste;
• risposte;
• header;
• metodi GET e POST;
• status code;
• contenuti HTML, CSS, JavaScript e immagini.

La grande differenza riguarda il livello sottostante.

HTTP/1.1 e HTTP/2 utilizzano normalmente TCP.

HTTP/3 utilizza invece QUIC.

Lo schema semplificato diventa:

HTTP/1.1 → TCP → IP

HTTP/2 → TCP → IP

HTTP/3 → QUIC → UDP → IP

QUIC non è semplicemente “HTTP via UDP”. È un vero protocollo di trasporto che implementa gestione delle connessioni, flussi, ritrasmissioni, controllo della congestione e crittografia.

Cos’è QUIC

QUIC è il protocollo di trasporto utilizzato da HTTP/3.

La sua specifica principale è definita nella RFC 9000 della IETF.

QUIC utilizza UDP come base ma implementa molte delle funzionalità normalmente associate a TCP direttamente all’interno del protocollo.

Tra queste troviamo:

• connessioni affidabili;
• gestione della perdita dei pacchetti;
• controllo della congestione;
• stream multipli;
• ritrasmissione dei dati;
• controllo del flusso;
• crittografia integrata;
• migrazione della connessione.

QUIC integra inoltre TLS 1.3 nel processo di creazione della connessione.

Questo permette di ridurre alcuni round trip necessari durante l’apertura di una nuova comunicazione.

Da HTTP/1.1 a HTTP/2

Per capire il vantaggio di HTTP/3 bisogna prima osservare come funzionavano le versioni precedenti.

Con HTTP/1.1 il browser poteva utilizzare più connessioni TCP parallele per scaricare contemporaneamente differenti risorse.

Una pagina moderna può però contenere decine o centinaia di elementi:

• HTML;
• CSS;
• JavaScript;
• font;
• immagini;
• API;
• file multimediali.

Creare molte connessioni separate introduce inevitabilmente overhead.

HTTP/2 ha risolto parte del problema introducendo il multiplexing.

Più richieste possono viaggiare contemporaneamente attraverso la stessa connessione TCP.

Questo è stato un miglioramento fondamentale.

Il limite di HTTP/2: TCP Head-of-Line Blocking

HTTP/2 può trasportare molti flussi contemporaneamente, ma tutti questi flussi continuano a viaggiare all’interno della stessa connessione TCP.

TCP garantisce che i dati vengano consegnati nell’ordine corretto.

Se un pacchetto viene perso, i dati successivi non possono essere consegnati all’applicazione finché il pacchetto mancante non viene recuperato.

Questo fenomeno viene chiamato TCP Head-of-Line Blocking.

Immaginiamo che una pagina stia scaricando contemporaneamente:

HTML
CSS
JavaScript
immagine 1
immagine 2
font

HTTP/2 considera questi contenuti come stream distinti, ma TCP vede il traffico come una sequenza ordinata di byte.

Se un pacchetto viene perso durante il percorso, il recupero può rallentare temporaneamente anche dati appartenenti ad altri stream.

La specifica HTTP/3 descrive proprio questo limite di HTTP/2 sopra TCP.

Come HTTP/3 riduce l’Head-of-Line Blocking

QUIC gestisce gli stream in modo indipendente a livello di trasporto.

Questo significa che la perdita di dati appartenenti a uno stream non deve necessariamente impedire agli altri stream di continuare a essere elaborati.

In uno scenario semplificato:

Stream 1 → HTML
Stream 2 → CSS
Stream 3 → JavaScript
Stream 4 → immagini

Se un pacchetto dello Stream 4 viene perso, gli altri stream possono continuare a procedere.

Questo può diventare particolarmente utile quando la rete non è perfettamente stabile.

È importante però precisare che HTTP/3 non elimina qualsiasi possibile forma di blocco o latenza. Risolve soprattutto il problema dell’Head-of-Line Blocking imposto da TCP tra stream indipendenti.

HTTP/3 e UDP: perché non usa più TCP?

TCP è un protocollo estremamente affidabile e rimane fondamentale per Internet.

Il problema è che modificarlo profondamente è difficile perché TCP viene gestito da sistemi operativi, router, firewall e numerosi dispositivi intermedi.

QUIC utilizza UDP come base e implementa molte funzionalità direttamente a livello software.

Questo consente di evolvere il protocollo più rapidamente senza dover modificare l’intero stack TCP dei sistemi operativi.

Non bisogna quindi pensare:

“UDP è più veloce perché non controlla niente.”

In HTTP/3 è QUIC a gestire affidabilità, ritrasmissioni e controllo della congestione.

HTTP/3 utilizza sempre connessioni cifrate

QUIC integra TLS 1.3 nel protocollo di trasporto.

HTTP/3 viene quindi utilizzato attraverso connessioni cifrate.

In HTTP/2 sopra HTTPS la sequenza semplificata comprende:

TCP handshake
↓
TLS handshake
↓
HTTP/2

Con QUIC trasporto e crittografia vengono integrati più strettamente:

QUIC + TLS 1.3
↓
HTTP/3

Questo permette di ridurre il lavoro necessario per creare una nuova connessione.

HTTP/3 può ridurre la latenza della connessione

Uno dei vantaggi di QUIC riguarda proprio l’instaurazione delle connessioni.

Ridurre il numero di round trip necessari può essere utile soprattutto quando client e server sono geograficamente distanti.

Immaginiamo:

Browser in Australia
↓
Server in Europa

Ogni round trip può richiedere decine o centinaia di millisecondi.

Ridurre anche un solo scambio di rete può quindi avere un impatto percepibile.

Su una rete locale o con server molto vicino all’utente il beneficio può invece essere praticamente impercettibile.

Cos’è 0-RTT in QUIC

QUIC può utilizzare una modalità conosciuta come 0-RTT nelle connessioni verso server già conosciuti.

In alcune condizioni il client può iniziare a inviare determinati dati senza attendere il completamento di un nuovo handshake completo.

Questo può ridurre ulteriormente la latenza delle connessioni ripetute.

0-RTT non deve però essere considerato una funzione da utilizzare indiscriminatamente.

Esistono considerazioni legate ai replay delle richieste e le applicazioni devono gestire correttamente le operazioni che potrebbero non essere sicure da ripetere.

HTTP/3 è particolarmente interessante sulle reti mobili

Uno degli scenari nei quali QUIC mostra caratteristiche particolarmente interessanti riguarda gli smartphone.

Durante una sessione mobile il dispositivo può passare continuamente tra:

• Wi-Fi domestico;
• rete 4G;
• rete 5G;
• Wi-Fi pubblico;
• reti con copertura instabile.

Con una connessione TCP tradizionale il cambio dell’indirizzo IP può richiedere la creazione di una nuova connessione.

QUIC utilizza identificatori di connessione che possono permettere di mantenere la sessione anche quando cambia il percorso di rete.

Questa caratteristica viene chiamata connection migration.

HTTP/2 vs HTTP/3

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

No.

È importante evitare il messaggio semplicistico:

“HTTP/3 rende qualsiasi sito molto più veloce.”

Il vantaggio dipende dalle condizioni della rete e dal sito.

Su una connessione stabile, veloce e con bassissima latenza, HTTP/2 può ottenere prestazioni molto simili.

I benefici di HTTP/3 diventano generalmente più interessanti quando aumentano:

• latenza;
• perdita di pacchetti;
• numero di richieste;
• instabilità della rete;
• cambi tra reti differenti.

Anche Cloudflare evidenzia come QUIC possa comportarsi meglio sulle reti soggette a perdita di pacchetti grazie alla gestione degli stream indipendenti.

HTTP/3 non risolve un sito lento

HTTP/3 migliora il protocollo di trasporto.

Non rende automaticamente veloce il codice applicativo.

Se una pagina impiega tre secondi perché PHP esegue query inefficienti, passare da HTTP/2 a HTTP/3 non elimina quei tre secondi.

Lo stesso vale per:

• database lento;
• CPU insufficiente;
• plugin inefficienti;
• JavaScript eccessivo;
• immagini troppo grandi;
• API esterne lente;
• cache assente;
• hosting sovraccarico.

La velocità reale dipende sempre dall’intera catena:

DNS
↓
rete
↓
HTTP
↓
web server
↓
cache
↓
PHP
↓
database
↓
HTML/CSS/JS
↓
browser

HTTP/3 migliora una parte di questo percorso, non tutte.

HTTP/3 e LiteSpeed

LiteSpeed Web Server supporta HTTP/3 direttamente.

LiteSpeed è stato tra i primi web server a introdurre un’implementazione HTTP/3 utilizzabile in produzione e continua a mantenere il supporto del protocollo.

La documentazione ufficiale LiteSpeed descrive la configurazione nella guida QUIC and HTTP/3 Support per LiteSpeed Web Server.

Questo è particolarmente interessante negli ambienti hosting perché HTTP/3 può essere gestito direttamente dal web server senza richiedere necessariamente un reverse proxy aggiuntivo.

Xlogic utilizza LiteSpeed Enterprise nei propri ambienti hosting compatibili.

Per approfondire il funzionamento del web server puoi leggere il confronto LiteSpeed vs Nginx vs Apache.

HTTP/3 e Cloudflare

HTTP/3 può essere fornito anche attraverso una CDN o un reverse proxy.

Cloudflare, per esempio, permette di attivare HTTP/3 sulla connessione tra visitatore e rete Cloudflare.

Il percorso può quindi essere:

Browser
↓ HTTP/3
Cloudflare
↓
Origin server

Questo dettaglio è importante perché il protocollo utilizzato tra browser e CDN non deve necessariamente essere identico a quello utilizzato tra CDN e server origin.

La documentazione Cloudflare specifica attualmente che la sua impostazione HTTP/3 riguarda la connessione tra l’utente e la rete Cloudflare.

È possibile approfondire nella documentazione HTTP/3 di Cloudflare.

Come sapere se un sito supporta HTTP/3

Esistono diversi modi per verificare HTTP/3.

Chrome DevTools

Apri gli strumenti per sviluppatori del browser:

1. apri Chrome o un browser Chromium;
2. premi F12;
3. apri la scheda Network;
4. ricarica la pagina;
5. aggiungi la colonna Protocol.

Quando HTTP/3 viene utilizzato il browser può mostrare valori come:

h3

Per HTTP/2 viene normalmente mostrato:

h2

Controllare alt-svc

Un server può pubblicizzare la disponibilità di HTTP/3 attraverso l’header:

alt-svc

Un esempio può essere:

alt-svc: h3=":443"; ma=86400

Questo indica al browser che per quel servizio è disponibile un endpoint HTTP/3.

La presenza di alt-svc indica la disponibilità annunciata del protocollo, ma non dimostra necessariamente che la singola richiesta osservata sia già stata effettuata via HTTP/3.

Verificare con curl

Se la propria build di curl supporta HTTP/3 è possibile provare:

curl --http3 -I https://example.com

Prima è utile verificare le caratteristiche della build:

curl -V

Non tutte le installazioni di curl sono compilate con supporto HTTP/3.

Perché a volte la prima richiesta usa HTTP/2

Un comportamento che può creare confusione durante i test è vedere la prima connessione effettuata tramite HTTP/2 e quelle successive tramite HTTP/3.

Uno dei metodi utilizzati per informare il browser della disponibilità di HTTP/3 è proprio l’header Alt-Svc.

Il browser può quindi:

1. connettersi inizialmente tramite HTTP/2;
2. ricevere l’indicazione che HTTP/3 è disponibile;
3. memorizzare l’informazione;
4. utilizzare HTTP/3 nelle connessioni successive.

Alcuni browser e meccanismi moderni possono inoltre conoscere la disponibilità del protocollo attraverso informazioni DNS e cache precedenti.

Perché HTTP/3 utilizza la porta UDP 443

HTTPS utilizza normalmente la porta TCP 443.

HTTP/3 utilizza invece QUIC su UDP 443.

Questo significa che un server che deve offrire direttamente HTTP/3 deve permettere il traffico UDP necessario.

Una configurazione firewall che consente soltanto TCP 443 può quindi impedire HTTP/3 anche se il web server è configurato correttamente.

Cosa succede se UDP è bloccato?

HTTP/3 è progettato per convivere con HTTP/2 e HTTP/1.1.

Se una rete aziendale, un firewall o un dispositivo intermedio impedisce il traffico QUIC, il browser può normalmente utilizzare una versione precedente supportata dal server.

Il sito non dovrebbe quindi diventare inutilizzabile semplicemente perché HTTP/3 non è disponibile.

Questa capacità di fallback è fondamentale durante la diffusione del protocollo.

HTTP/3 e Core Web Vitals

HTTP/3 può contribuire a ridurre parte della latenza di rete, ma non esiste un rapporto automatico tra attivazione del protocollo e miglioramento dei Core Web Vitals.

Metriche come Largest Contentful Paint dipendono da numerosi fattori:

• TTFB;
• immagine LCP;
• CSS;
• JavaScript;
• font;
• rendering;
• cache;
• rete;
• server.

HTTP/3 può migliorare la componente di rete, soprattutto in condizioni meno favorevoli.

Non può però correggere una hero image da diversi megabyte o un’applicazione che impiega troppo tempo per generare l’HTML.

HTTP/3 e immagini WebP o AVIF

HTTP/3 e formati immagine moderni risolvono problemi differenti.

HTTP/3 migliora il trasporto dei dati.

WebP e AVIF riducono invece la quantità di dati da trasferire.

Le due tecnologie possono quindi lavorare insieme:

HTTP/3
+
WebP / AVIF
+
cache
+
CDN
+
hosting performante

Abbiamo approfondito la scelta del formato nella guida WebP vs AVIF nel 2026.

HTTP/3 aumenta la capacità del server?

Non direttamente.

HTTP/3 può migliorare l’efficienza della comunicazione, ma le risorse necessarie per generare una pagina dinamica rimangono legate a:

• CPU;
• RAM;
• PHP;
• database;
• cache;
• I/O;
• applicazione.

Se un server riesce a generare soltanto 20 richieste dinamiche al secondo per un limite applicativo, HTTP/3 non trasforma automaticamente quel numero in 200.

Per aumentare la capacità bisogna individuare il vero collo di bottiglia.

HTTP/3 conviene su un hosting condiviso?

Sì, se l’infrastruttura hosting lo supporta correttamente.

L’utente non deve necessariamente amministrare QUIC manualmente.

Quando il web server e la rete sono già configurati dal provider, HTTP/3 può essere disponibile in modo trasparente.

Il browser negozia automaticamente la migliore versione disponibile senza richiedere modifiche all’HTML del sito.

Per questo HTTP/3 rappresenta soprattutto una caratteristica dell’infrastruttura piuttosto che una funzione che il proprietario del sito deve programmare.

Per un ambiente basato su LiteSpeed Enterprise puoi consultare i piani Hosting Condiviso Xlogic.

HTTP/3 richiede modifiche al sito?

Nella maggior parte dei casi no.

Un’applicazione non deve essere riscritta per passare da HTTP/2 a HTTP/3.

HTTP mantiene le stesse semantiche fondamentali.

Il browser e il server negoziano automaticamente il protocollo utilizzabile.

Questo significa che una normale pagina:

index.html

può essere servita via HTTP/1.1, HTTP/2 oppure HTTP/3 senza modificare il suo contenuto.

HTTP/3 sostituisce HTTP/2?

Nel lungo periodo HTTP/3 continuerà probabilmente a crescere, ma questo non significa che HTTP/2 debba essere disattivato.

I server moderni continuano normalmente a supportare più protocolli contemporaneamente.

La strategia corretta è offrire:

HTTP/3
HTTP/2
HTTP/1.1

e lasciare che client e server negozino quello più appropriato.

In questo modo rimane garantita la compatibilità anche con software o reti che non possono utilizzare QUIC.

HTTP/3 nel 2026: quando offre il vantaggio maggiore

HTTP/3 può essere particolarmente interessante nei seguenti scenari:

• utenti mobili;
• reti 4G e 5G;
• connessioni con perdita di pacchetti;
• utenti lontani geograficamente dal server;
• pagine con molte richieste;
• applicazioni web interattive;
• frequente cambio tra Wi-Fi e rete mobile;
• grandi volumi di traffico distribuito.

Il beneficio può invece essere molto ridotto quando:

• rete e server sono molto vicini;
• la latenza è già bassissima;
• il sito contiene pochissime risorse;
• il vero limite è PHP o il database;
• la pagina è dominata da JavaScript pesante;
• le immagini sono enormi;
• il server risponde lentamente indipendentemente dalla rete.

HTTP/3 su Xlogic e LiteSpeed Enterprise

L’infrastruttura Xlogic utilizza LiteSpeed Enterprise nei servizi compatibili, insieme a tecnologie dedicate alla gestione efficiente dei siti e delle applicazioni PHP.

LiteSpeed supporta HTTP/3 e QUIC nativamente e può quindi negoziare il protocollo con i browser compatibili quando rete e configurazione lo consentono.

Il vantaggio non deriva però dalla singola sigla HTTP/3.

Le prestazioni di un sito dipendono dall’interazione tra:

• web server;
• rete;
• PHP;
• OPcache;
• cache;
• database;
• storage;
• CPU e RAM;
• ottimizzazione del frontend.

HTTP/3 rappresenta quindi uno dei componenti di uno stack moderno, non una soluzione universale a qualsiasi problema di velocità.

Checklist HTTP/3

Per verificare che un ambiente sia pronto per HTTP/3 puoi controllare:

1. web server compatibile con HTTP/3;
2. HTTPS correttamente configurato;
3. TLS moderno;
4. UDP 443 disponibile;
5. firewall configurato correttamente;
6. header Alt-Svc quando previsto;
7. browser moderno;
8. negoziazione effettiva del protocollo;
9. fallback HTTP/2 funzionante;
10. test da reti differenti.

Conclusioni

HTTP/3 nel 2026 rappresenta un’evoluzione importante del modo in cui browser e server comunicano.

Il passaggio da TCP a QUIC permette di gestire stream indipendenti, ridurre gli effetti dell’Head-of-Line Blocking a livello di trasporto e integrare più strettamente la creazione della connessione con TLS.

Le caratteristiche di QUIC risultano particolarmente interessanti sulle reti mobili, sulle connessioni con perdita di pacchetti e nei collegamenti caratterizzati da latenza elevata.

Questo non significa però che qualsiasi sito diventi automaticamente molto più veloce.

HTTP/3 non risolve:

• PHP lento;
• database inefficiente;
• query pesanti;
• immagini enormi;
• JavaScript eccessivo;
• cache assente;
• risorse server insufficienti.

La strategia migliore consiste quindi nell’utilizzare HTTP/3 come parte di un’infrastruttura moderna insieme a:

LiteSpeed + cache + PHP ottimizzato + storage veloce + immagini moderne + frontend efficiente.

Per l’utente finale il passaggio è generalmente trasparente: browser e server negoziano automaticamente il miglior protocollo disponibile.

HTTP/3 non sostituisce una buona ottimizzazione del sito, ma rende il trasporto dei dati più adatto all’Internet moderno.

Domande frequenti su HTTP/3

Cos’è HTTP/3?

HTTP/3 è la più recente grande versione del protocollo HTTP. Utilizza QUIC come protocollo di trasporto invece di TCP ed è standardizzato dalla RFC 9114.

HTTP/3 utilizza TCP?

No. HTTP/3 utilizza QUIC, che viene eseguito sopra UDP. QUIC implementa direttamente funzioni come affidabilità, gestione degli stream, controllo della congestione e crittografia.

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

Può esserlo soprattutto su reti con latenza elevata, perdita di pacchetti o frequenti cambi di connessione. Su reti molto stabili e veloci il vantaggio rispetto a HTTP/2 può essere ridotto.

HTTP/3 funziona con HTTPS?

Sì. QUIC integra TLS 1.3 nel protocollo e HTTP/3 viene normalmente utilizzato attraverso connessioni cifrate.

Cos’è QUIC?

QUIC è un protocollo di trasporto standardizzato dalla IETF. È basato su UDP e fornisce stream multiplexati, controllo della congestione, ritrasmissione, crittografia e altre funzioni necessarie a HTTP/3.

HTTP/3 risolve il problema Head-of-Line Blocking?

QUIC elimina il blocco tra stream indipendenti causato dalla consegna ordinata della singola connessione TCP utilizzata da HTTP/2. Una perdita relativa a uno stream non deve quindi fermare automaticamente tutti gli altri stream.

LiteSpeed supporta HTTP/3?

Sì. LiteSpeed Web Server supporta HTTP/3 e QUIC nativamente. La disponibilità effettiva dipende comunque anche dalla configurazione della rete e del firewall.

Come verifico se il mio sito usa HTTP/3?

È possibile controllare il protocollo tramite la scheda Network dei Developer Tools del browser. Nei browser Chromium la colonna Protocol può mostrare h3 quando la richiesta viene effettuata tramite HTTP/3.

HTTP/3 usa la porta 443?

Sì, normalmente utilizza UDP sulla porta 443, mentre HTTPS tradizionale con HTTP/2 utilizza TCP 443.

Se HTTP/3 non funziona il sito diventa irraggiungibile?

Normalmente no. I server moderni continuano a supportare HTTP/2 e HTTP/1.1, permettendo al browser di utilizzare un protocollo alternativo quando QUIC non è disponibile.

HTTP/3 migliora automaticamente Core Web Vitals?

No. Può contribuire a ridurre la latenza di rete in determinati scenari, ma Core Web Vitals dipende anche da server, cache, immagini, CSS, JavaScript, font e rendering della pagina.

Devo modificare il codice HTML per usare HTTP/3?

No. Il protocollo viene negoziato tra browser e infrastruttura server. Nella maggior parte dei casi il sito non richiede modifiche applicative.