{"id":19336,"date":"2026-08-29T16:41:32","date_gmt":"2026-08-29T14:41:32","guid":{"rendered":"https:\/\/xlogic.org\/blog\/?p=19336"},"modified":"2026-08-29T17:01:37","modified_gmt":"2026-08-29T15:01:37","slug":"http-3-quic-2026","status":"publish","type":"post","link":"https:\/\/xlogic.org\/blog\/http-3-quic-2026.html\/","title":{"rendered":"HTTP\/3 e QUIC nel 2026: cos&#8217;\u00e8, come funziona e perch\u00e9 pu\u00f2 velocizzare un sito"},"content":{"rendered":"<p><strong>HTTP\/3<\/strong> \u00e8 la pi\u00f9 recente evoluzione principale del protocollo HTTP e nel 2026 \u00e8 ormai una tecnologia concreta utilizzata da browser, CDN e web server moderni.<\/p>\n<p>La differenza pi\u00f9 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 <strong>QUIC<\/strong>, un protocollo moderno costruito sopra UDP.<\/p>\n<p>L&#8217;obiettivo \u00e8 ridurre alcune delle limitazioni delle connessioni TCP tradizionali, migliorare la gestione di pi\u00f9 flussi simultanei e offrire prestazioni pi\u00f9 stabili soprattutto su reti con latenza elevata, perdita di pacchetti o frequenti cambiamenti di connessione.<\/p>\n<p>Ma <strong>HTTP\/3 rende davvero un sito pi\u00f9 veloce?<\/strong> Conviene abilitarlo? Qual \u00e8 la differenza rispetto a HTTP\/2? E perch\u00e9 LiteSpeed, CDN e browser moderni lo utilizzano?<\/p>\n<p>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\u00f2 offrire un vantaggio reale.<\/p>\n<h2>HTTP\/3: cos&#8217;\u00e8<\/h2>\n<p><strong>HTTP\/3<\/strong> \u00e8 la terza grande versione del protocollo utilizzato dai browser per comunicare con i server web.<\/p>\n<p>\u00c8 standardizzato dalla IETF attraverso la <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc9114.html\" target=\"_blank\" rel=\"noopener\">RFC 9114 dedicata a HTTP\/3<\/a>.<\/p>\n<p>HTTP continua a definire concetti familiari come:<\/p>\n<ul>\n<li>richieste;<\/li>\n<li>risposte;<\/li>\n<li>header;<\/li>\n<li>metodi GET e POST;<\/li>\n<li>status code;<\/li>\n<li>contenuti HTML, CSS, JavaScript e immagini.<\/li>\n<\/ul>\n<p>La grande differenza riguarda il livello sottostante.<\/p>\n<p>HTTP\/1.1 e HTTP\/2 utilizzano normalmente TCP.<\/p>\n<p>HTTP\/3 utilizza invece <strong>QUIC<\/strong>.<\/p>\n<p>Lo schema semplificato diventa:<\/p>\n<pre><code>HTTP\/1.1 \u2192 TCP \u2192 IP\r\n\r\nHTTP\/2 \u2192 TCP \u2192 IP\r\n\r\nHTTP\/3 \u2192 QUIC \u2192 UDP \u2192 IP<\/code><\/pre>\n<p>QUIC non \u00e8 semplicemente &#8220;HTTP via UDP&#8221;. \u00c8 un vero protocollo di trasporto che implementa gestione delle connessioni, flussi, ritrasmissioni, controllo della congestione e crittografia.<\/p>\n<h2>Cos&#8217;\u00e8 QUIC<\/h2>\n<p><strong>QUIC<\/strong> \u00e8 il protocollo di trasporto utilizzato da HTTP\/3.<\/p>\n<p>La sua specifica principale \u00e8 definita nella <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc9000.html\" target=\"_blank\" rel=\"noopener\">RFC 9000 della IETF<\/a>.<\/p>\n<p>QUIC utilizza UDP come base ma implementa molte delle funzionalit\u00e0 normalmente associate a TCP direttamente all&#8217;interno del protocollo.<\/p>\n<p>Tra queste troviamo:<\/p>\n<ul>\n<li>connessioni affidabili;<\/li>\n<li>gestione della perdita dei pacchetti;<\/li>\n<li>controllo della congestione;<\/li>\n<li>stream multipli;<\/li>\n<li>ritrasmissione dei dati;<\/li>\n<li>controllo del flusso;<\/li>\n<li>crittografia integrata;<\/li>\n<li>migrazione della connessione.<\/li>\n<\/ul>\n<p>QUIC integra inoltre TLS 1.3 nel processo di creazione della connessione.<\/p>\n<p>Questo permette di ridurre alcuni round trip necessari durante l&#8217;apertura di una nuova comunicazione.<\/p>\n<h2>Da HTTP\/1.1 a HTTP\/2<\/h2>\n<p>Per capire il vantaggio di HTTP\/3 bisogna prima osservare come funzionavano le versioni precedenti.<\/p>\n<p>Con HTTP\/1.1 il browser poteva utilizzare pi\u00f9 connessioni TCP parallele per scaricare contemporaneamente differenti risorse.<\/p>\n<p>Una pagina moderna pu\u00f2 per\u00f2 contenere decine o centinaia di elementi:<\/p>\n<ul>\n<li>HTML;<\/li>\n<li>CSS;<\/li>\n<li>JavaScript;<\/li>\n<li>font;<\/li>\n<li>immagini;<\/li>\n<li>API;<\/li>\n<li>file multimediali.<\/li>\n<\/ul>\n<p>Creare molte connessioni separate introduce inevitabilmente overhead.<\/p>\n<p>HTTP\/2 ha risolto parte del problema introducendo il <strong>multiplexing<\/strong>.<\/p>\n<p>Pi\u00f9 richieste possono viaggiare contemporaneamente attraverso la stessa connessione TCP.<\/p>\n<p>Questo \u00e8 stato un miglioramento fondamentale.<\/p>\n<h2>Il limite di HTTP\/2: TCP Head-of-Line Blocking<\/h2>\n<p>HTTP\/2 pu\u00f2 trasportare molti flussi contemporaneamente, ma tutti questi flussi continuano a viaggiare all&#8217;interno della stessa connessione TCP.<\/p>\n<p>TCP garantisce che i dati vengano consegnati nell&#8217;ordine corretto.<\/p>\n<p>Se un pacchetto viene perso, i dati successivi non possono essere consegnati all&#8217;applicazione finch\u00e9 il pacchetto mancante non viene recuperato.<\/p>\n<p>Questo fenomeno viene chiamato <strong>TCP Head-of-Line Blocking<\/strong>.<\/p>\n<p>Immaginiamo che una pagina stia scaricando contemporaneamente:<\/p>\n<pre><code>HTML\r\nCSS\r\nJavaScript\r\nimmagine 1\r\nimmagine 2\r\nfont<\/code><\/pre>\n<p>HTTP\/2 considera questi contenuti come stream distinti, ma TCP vede il traffico come una sequenza ordinata di byte.<\/p>\n<p>Se un pacchetto viene perso durante il percorso, il recupero pu\u00f2 rallentare temporaneamente anche dati appartenenti ad altri stream.<\/p>\n<p>La <a href=\"https:\/\/www.rfc-editor.org\/info\/rfc9114\/\" target=\"_blank\" rel=\"noopener\">specifica HTTP\/3<\/a> descrive proprio questo limite di HTTP\/2 sopra TCP.<\/p>\n<h2>Come HTTP\/3 riduce l&#8217;Head-of-Line Blocking<\/h2>\n<p>QUIC gestisce gli stream in modo indipendente a livello di trasporto.<\/p>\n<p>Questo significa che la perdita di dati appartenenti a uno stream non deve necessariamente impedire agli altri stream di continuare a essere elaborati.<\/p>\n<p>In uno scenario semplificato:<\/p>\n<pre><code>Stream 1 \u2192 HTML\r\nStream 2 \u2192 CSS\r\nStream 3 \u2192 JavaScript\r\nStream 4 \u2192 immagini<\/code><\/pre>\n<p>Se un pacchetto dello Stream 4 viene perso, gli altri stream possono continuare a procedere.<\/p>\n<p>Questo pu\u00f2 diventare particolarmente utile quando la rete non \u00e8 perfettamente stabile.<\/p>\n<p>\u00c8 importante per\u00f2 precisare che HTTP\/3 non elimina qualsiasi possibile forma di blocco o latenza. Risolve soprattutto il problema dell&#8217;Head-of-Line Blocking imposto da TCP tra stream indipendenti.<\/p>\n<h2>HTTP\/3 e UDP: perch\u00e9 non usa pi\u00f9 TCP?<\/h2>\n<p>TCP \u00e8 un protocollo estremamente affidabile e rimane fondamentale per Internet.<\/p>\n<p>Il problema \u00e8 che modificarlo profondamente \u00e8 difficile perch\u00e9 TCP viene gestito da sistemi operativi, router, firewall e numerosi dispositivi intermedi.<\/p>\n<p>QUIC utilizza UDP come base e implementa molte funzionalit\u00e0 direttamente a livello software.<\/p>\n<p>Questo consente di evolvere il protocollo pi\u00f9 rapidamente senza dover modificare l&#8217;intero stack TCP dei sistemi operativi.<\/p>\n<p>Non bisogna quindi pensare:<\/p>\n<p><strong>&#8220;UDP \u00e8 pi\u00f9 veloce perch\u00e9 non controlla niente.&#8221;<\/strong><\/p>\n<p>In HTTP\/3 \u00e8 QUIC a gestire affidabilit\u00e0, ritrasmissioni e controllo della congestione.<\/p>\n<h2>HTTP\/3 utilizza sempre connessioni cifrate<\/h2>\n<p>QUIC integra TLS 1.3 nel protocollo di trasporto.<\/p>\n<p>HTTP\/3 viene quindi utilizzato attraverso connessioni cifrate.<\/p>\n<p>In HTTP\/2 sopra HTTPS la sequenza semplificata comprende:<\/p>\n<pre><code>TCP handshake\r\n\u2193\r\nTLS handshake\r\n\u2193\r\nHTTP\/2<\/code><\/pre>\n<p>Con QUIC trasporto e crittografia vengono integrati pi\u00f9 strettamente:<\/p>\n<pre><code>QUIC + TLS 1.3\r\n\u2193\r\nHTTP\/3<\/code><\/pre>\n<p>Questo permette di ridurre il lavoro necessario per creare una nuova connessione.<\/p>\n<h2>HTTP\/3 pu\u00f2 ridurre la latenza della connessione<\/h2>\n<p>Uno dei vantaggi di QUIC riguarda proprio l&#8217;instaurazione delle connessioni.<\/p>\n<p>Ridurre il numero di round trip necessari pu\u00f2 essere utile soprattutto quando client e server sono geograficamente distanti.<\/p>\n<p>Immaginiamo:<\/p>\n<pre><code>Browser in Australia\r\n\u2193\r\nServer in Europa<\/code><\/pre>\n<p>Ogni round trip pu\u00f2 richiedere decine o centinaia di millisecondi.<\/p>\n<p>Ridurre anche un solo scambio di rete pu\u00f2 quindi avere un impatto percepibile.<\/p>\n<p>Su una rete locale o con server molto vicino all&#8217;utente il beneficio pu\u00f2 invece essere praticamente impercettibile.<\/p>\n<h2>Cos&#8217;\u00e8 0-RTT in QUIC<\/h2>\n<p>QUIC pu\u00f2 utilizzare una modalit\u00e0 conosciuta come <strong>0-RTT<\/strong> nelle connessioni verso server gi\u00e0 conosciuti.<\/p>\n<p>In alcune condizioni il client pu\u00f2 iniziare a inviare determinati dati senza attendere il completamento di un nuovo handshake completo.<\/p>\n<p>Questo pu\u00f2 ridurre ulteriormente la latenza delle connessioni ripetute.<\/p>\n<p>0-RTT non deve per\u00f2 essere considerato una funzione da utilizzare indiscriminatamente.<\/p>\n<p>Esistono considerazioni legate ai replay delle richieste e le applicazioni devono gestire correttamente le operazioni che potrebbero non essere sicure da ripetere.<\/p>\n<h2>HTTP\/3 \u00e8 particolarmente interessante sulle reti mobili<\/h2>\n<p>Uno degli scenari nei quali QUIC mostra caratteristiche particolarmente interessanti riguarda gli smartphone.<\/p>\n<p>Durante una sessione mobile il dispositivo pu\u00f2 passare continuamente tra:<\/p>\n<ul>\n<li>Wi-Fi domestico;<\/li>\n<li>rete 4G;<\/li>\n<li>rete 5G;<\/li>\n<li>Wi-Fi pubblico;<\/li>\n<li>reti con copertura instabile.<\/li>\n<\/ul>\n<p>Con una connessione TCP tradizionale il cambio dell&#8217;indirizzo IP pu\u00f2 richiedere la creazione di una nuova connessione.<\/p>\n<p>QUIC utilizza identificatori di connessione che possono permettere di mantenere la sessione anche quando cambia il percorso di rete.<\/p>\n<p>Questa caratteristica viene chiamata <strong>connection migration<\/strong>.<\/p>\n<h2>HTTP\/2 vs HTTP\/3<\/h2>\n<table>\n<thead>\n<tr>\n<th>Caratteristica<\/th>\n<th>HTTP\/2<\/th>\n<th>HTTP\/3<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Protocollo di trasporto<\/td>\n<td>TCP<\/td>\n<td>QUIC su UDP<\/td>\n<\/tr>\n<tr>\n<td>Multiplexing<\/td>\n<td>S\u00ec<\/td>\n<td>S\u00ec<\/td>\n<\/tr>\n<tr>\n<td>Head-of-Line Blocking TCP<\/td>\n<td>Presente<\/td>\n<td>Ridotto grazie agli stream QUIC<\/td>\n<\/tr>\n<tr>\n<td>TLS<\/td>\n<td>Separato dal trasporto TCP<\/td>\n<td>Integrato in QUIC<\/td>\n<\/tr>\n<tr>\n<td>Gestione cambio rete<\/td>\n<td>Richiede normalmente nuova connessione<\/td>\n<td>Pu\u00f2 utilizzare connection migration<\/td>\n<\/tr>\n<tr>\n<td>Trasporto<\/td>\n<td>TCP<\/td>\n<td>UDP<\/td>\n<\/tr>\n<tr>\n<td>Supporto browser moderni<\/td>\n<td>S\u00ec<\/td>\n<td>S\u00ec<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>HTTP\/3 \u00e8 sempre pi\u00f9 veloce di HTTP\/2?<\/h2>\n<p>No.<\/p>\n<p>\u00c8 importante evitare il messaggio semplicistico:<\/p>\n<p><strong>&#8220;HTTP\/3 rende qualsiasi sito molto pi\u00f9 veloce.&#8221;<\/strong><\/p>\n<p>Il vantaggio dipende dalle condizioni della rete e dal sito.<\/p>\n<p>Su una connessione stabile, veloce e con bassissima latenza, HTTP\/2 pu\u00f2 ottenere prestazioni molto simili.<\/p>\n<p>I benefici di HTTP\/3 diventano generalmente pi\u00f9 interessanti quando aumentano:<\/p>\n<ul>\n<li>latenza;<\/li>\n<li>perdita di pacchetti;<\/li>\n<li>numero di richieste;<\/li>\n<li>instabilit\u00e0 della rete;<\/li>\n<li>cambi tra reti differenti.<\/li>\n<\/ul>\n<p>Anche Cloudflare evidenzia come QUIC possa comportarsi meglio sulle <a href=\"https:\/\/developers.cloudflare.com\/speed\/optimization\/protocol\/http3\/\" target=\"_blank\" rel=\"noopener\">reti soggette a perdita di pacchetti grazie alla gestione degli stream indipendenti<\/a>.<\/p>\n<h2>HTTP\/3 non risolve un sito lento<\/h2>\n<p>HTTP\/3 migliora il protocollo di trasporto.<\/p>\n<p>Non rende automaticamente veloce il codice applicativo.<\/p>\n<p>Se una pagina impiega tre secondi perch\u00e9 PHP esegue query inefficienti, passare da HTTP\/2 a HTTP\/3 non elimina quei tre secondi.<\/p>\n<p>Lo stesso vale per:<\/p>\n<ul>\n<li>database lento;<\/li>\n<li>CPU insufficiente;<\/li>\n<li>plugin inefficienti;<\/li>\n<li>JavaScript eccessivo;<\/li>\n<li>immagini troppo grandi;<\/li>\n<li>API esterne lente;<\/li>\n<li>cache assente;<\/li>\n<li>hosting sovraccarico.<\/li>\n<\/ul>\n<p>La velocit\u00e0 reale dipende sempre dall&#8217;intera catena:<\/p>\n<pre><code>DNS\r\n\u2193\r\nrete\r\n\u2193\r\nHTTP\r\n\u2193\r\nweb server\r\n\u2193\r\ncache\r\n\u2193\r\nPHP\r\n\u2193\r\ndatabase\r\n\u2193\r\nHTML\/CSS\/JS\r\n\u2193\r\nbrowser<\/code><\/pre>\n<p>HTTP\/3 migliora una parte di questo percorso, non tutte.<\/p>\n<h2>HTTP\/3 e LiteSpeed<\/h2>\n<p><strong>LiteSpeed Web Server supporta HTTP\/3<\/strong> direttamente.<\/p>\n<p>LiteSpeed \u00e8 stato tra i primi web server a introdurre un&#8217;implementazione HTTP\/3 utilizzabile in produzione e continua a mantenere il supporto del protocollo.<\/p>\n<p>La documentazione ufficiale LiteSpeed descrive la configurazione nella guida <a href=\"https:\/\/docs.litespeedtech.com\/lsws\/cp\/cpanel\/quic-http3\/\" target=\"_blank\" rel=\"noopener\">QUIC and HTTP\/3 Support per LiteSpeed Web Server<\/a>.<\/p>\n<p>Questo \u00e8 particolarmente interessante negli ambienti hosting perch\u00e9 HTTP\/3 pu\u00f2 essere gestito direttamente dal web server senza richiedere necessariamente un reverse proxy aggiuntivo.<\/p>\n<p>Xlogic utilizza <strong>LiteSpeed Enterprise<\/strong> nei propri ambienti hosting compatibili.<\/p>\n<p>Per approfondire il funzionamento del web server puoi leggere il confronto <a href=\"https:\/\/xlogic.org\/blog\/litespeed-vs-nginx-vs-apache.html\/\"><strong>LiteSpeed vs Nginx vs Apache<\/strong><\/a>.<\/p>\n<h2>HTTP\/3 e Cloudflare<\/h2>\n<p>HTTP\/3 pu\u00f2 essere fornito anche attraverso una CDN o un reverse proxy.<\/p>\n<p>Cloudflare, per esempio, permette di attivare HTTP\/3 sulla connessione tra visitatore e rete Cloudflare.<\/p>\n<p>Il percorso pu\u00f2 quindi essere:<\/p>\n<pre><code>Browser\r\n\u2193 HTTP\/3\r\nCloudflare\r\n\u2193\r\nOrigin server<\/code><\/pre>\n<p>Questo dettaglio \u00e8 importante perch\u00e9 il protocollo utilizzato tra browser e CDN non deve necessariamente essere identico a quello utilizzato tra CDN e server origin.<\/p>\n<p>La documentazione Cloudflare specifica attualmente che la sua impostazione HTTP\/3 riguarda la connessione tra l&#8217;utente e la rete Cloudflare.<\/p>\n<p>\u00c8 possibile approfondire nella <a href=\"https:\/\/developers.cloudflare.com\/speed\/optimization\/protocol\/http3\/\" target=\"_blank\" rel=\"noopener\">documentazione HTTP\/3 di Cloudflare<\/a>.<\/p>\n<h2>Come sapere se un sito supporta HTTP\/3<\/h2>\n<p>Esistono diversi modi per verificare HTTP\/3.<\/p>\n<h3>Chrome DevTools<\/h3>\n<p>Apri gli strumenti per sviluppatori del browser:<\/p>\n<ol>\n<li>apri Chrome o un browser Chromium;<\/li>\n<li>premi F12;<\/li>\n<li>apri la scheda Network;<\/li>\n<li>ricarica la pagina;<\/li>\n<li>aggiungi la colonna Protocol.<\/li>\n<\/ol>\n<p>Quando HTTP\/3 viene utilizzato il browser pu\u00f2 mostrare valori come:<\/p>\n<pre><code>h3<\/code><\/pre>\n<p>Per HTTP\/2 viene normalmente mostrato:<\/p>\n<pre><code>h2<\/code><\/pre>\n<h3>Controllare alt-svc<\/h3>\n<p>Un server pu\u00f2 pubblicizzare la disponibilit\u00e0 di HTTP\/3 attraverso l&#8217;header:<\/p>\n<pre><code>alt-svc<\/code><\/pre>\n<p>Un esempio pu\u00f2 essere:<\/p>\n<pre><code>alt-svc: h3=\":443\"; ma=86400<\/code><\/pre>\n<p>Questo indica al browser che per quel servizio \u00e8 disponibile un endpoint HTTP\/3.<\/p>\n<p>La presenza di <code>alt-svc<\/code> indica la disponibilit\u00e0 annunciata del protocollo, ma non dimostra necessariamente che la singola richiesta osservata sia gi\u00e0 stata effettuata via HTTP\/3.<\/p>\n<h3>Verificare con curl<\/h3>\n<p>Se la propria build di curl supporta HTTP\/3 \u00e8 possibile provare:<\/p>\n<pre><code>curl --http3 -I https:\/\/example.com<\/code><\/pre>\n<p>Prima \u00e8 utile verificare le caratteristiche della build:<\/p>\n<pre><code>curl -V<\/code><\/pre>\n<p>Non tutte le installazioni di curl sono compilate con supporto HTTP\/3.<\/p>\n<h2>Perch\u00e9 a volte la prima richiesta usa HTTP\/2<\/h2>\n<p>Un comportamento che pu\u00f2 creare confusione durante i test \u00e8 vedere la prima connessione effettuata tramite HTTP\/2 e quelle successive tramite HTTP\/3.<\/p>\n<p>Uno dei metodi utilizzati per informare il browser della disponibilit\u00e0 di HTTP\/3 \u00e8 proprio l&#8217;header <code>Alt-Svc<\/code>.<\/p>\n<p>Il browser pu\u00f2 quindi:<\/p>\n<ol>\n<li>connettersi inizialmente tramite HTTP\/2;<\/li>\n<li>ricevere l&#8217;indicazione che HTTP\/3 \u00e8 disponibile;<\/li>\n<li>memorizzare l&#8217;informazione;<\/li>\n<li>utilizzare HTTP\/3 nelle connessioni successive.<\/li>\n<\/ol>\n<p>Alcuni browser e meccanismi moderni possono inoltre conoscere la disponibilit\u00e0 del protocollo attraverso informazioni DNS e cache precedenti.<\/p>\n<h2>Perch\u00e9 HTTP\/3 utilizza la porta UDP 443<\/h2>\n<p>HTTPS utilizza normalmente la porta TCP 443.<\/p>\n<p>HTTP\/3 utilizza invece QUIC su <strong>UDP 443<\/strong>.<\/p>\n<p>Questo significa che un server che deve offrire direttamente HTTP\/3 deve permettere il traffico UDP necessario.<\/p>\n<p>Una configurazione firewall che consente soltanto TCP 443 pu\u00f2 quindi impedire HTTP\/3 anche se il web server \u00e8 configurato correttamente.<\/p>\n<h2>Cosa succede se UDP \u00e8 bloccato?<\/h2>\n<p>HTTP\/3 \u00e8 progettato per convivere con HTTP\/2 e HTTP\/1.1.<\/p>\n<p>Se una rete aziendale, un firewall o un dispositivo intermedio impedisce il traffico QUIC, il browser pu\u00f2 normalmente utilizzare una versione precedente supportata dal server.<\/p>\n<p>Il sito non dovrebbe quindi diventare inutilizzabile semplicemente perch\u00e9 HTTP\/3 non \u00e8 disponibile.<\/p>\n<p>Questa capacit\u00e0 di fallback \u00e8 fondamentale durante la diffusione del protocollo.<\/p>\n<h2>HTTP\/3 e Core Web Vitals<\/h2>\n<p>HTTP\/3 pu\u00f2 contribuire a ridurre parte della latenza di rete, ma non esiste un rapporto automatico tra attivazione del protocollo e miglioramento dei Core Web Vitals.<\/p>\n<p>Metriche come Largest Contentful Paint dipendono da numerosi fattori:<\/p>\n<ul>\n<li>TTFB;<\/li>\n<li>immagine LCP;<\/li>\n<li>CSS;<\/li>\n<li>JavaScript;<\/li>\n<li>font;<\/li>\n<li>rendering;<\/li>\n<li>cache;<\/li>\n<li>rete;<\/li>\n<li>server.<\/li>\n<\/ul>\n<p>HTTP\/3 pu\u00f2 migliorare la componente di rete, soprattutto in condizioni meno favorevoli.<\/p>\n<p>Non pu\u00f2 per\u00f2 correggere una hero image da diversi megabyte o un&#8217;applicazione che impiega troppo tempo per generare l&#8217;HTML.<\/p>\n<h2>HTTP\/3 e immagini WebP o AVIF<\/h2>\n<p>HTTP\/3 e formati immagine moderni risolvono problemi differenti.<\/p>\n<p>HTTP\/3 migliora il trasporto dei dati.<\/p>\n<p>WebP e AVIF riducono invece la quantit\u00e0 di dati da trasferire.<\/p>\n<p>Le due tecnologie possono quindi lavorare insieme:<\/p>\n<pre><code>HTTP\/3\r\n+\r\nWebP \/ AVIF\r\n+\r\ncache\r\n+\r\nCDN\r\n+\r\nhosting performante<\/code><\/pre>\n<p>Abbiamo approfondito la scelta del formato nella guida <a href=\"https:\/\/xlogic.org\/blog\/webp-vs-avif-2026.html\/\"><strong>WebP vs AVIF nel 2026<\/strong><\/a>.<\/p>\n<h2>HTTP\/3 aumenta la capacit\u00e0 del server?<\/h2>\n<p>Non direttamente.<\/p>\n<p>HTTP\/3 pu\u00f2 migliorare l&#8217;efficienza della comunicazione, ma le risorse necessarie per generare una pagina dinamica rimangono legate a:<\/p>\n<ul>\n<li>CPU;<\/li>\n<li>RAM;<\/li>\n<li>PHP;<\/li>\n<li>database;<\/li>\n<li>cache;<\/li>\n<li>I\/O;<\/li>\n<li>applicazione.<\/li>\n<\/ul>\n<p>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.<\/p>\n<p>Per aumentare la capacit\u00e0 bisogna individuare il vero collo di bottiglia.<\/p>\n<h2>HTTP\/3 conviene su un hosting condiviso?<\/h2>\n<p>S\u00ec, se l&#8217;infrastruttura hosting lo supporta correttamente.<\/p>\n<p>L&#8217;utente non deve necessariamente amministrare QUIC manualmente.<\/p>\n<p>Quando il web server e la rete sono gi\u00e0 configurati dal provider, HTTP\/3 pu\u00f2 essere disponibile in modo trasparente.<\/p>\n<p>Il browser negozia automaticamente la migliore versione disponibile senza richiedere modifiche all&#8217;HTML del sito.<\/p>\n<p>Per questo HTTP\/3 rappresenta soprattutto una caratteristica dell&#8217;infrastruttura piuttosto che una funzione che il proprietario del sito deve programmare.<\/p>\n<p>Per un ambiente basato su LiteSpeed Enterprise puoi consultare i piani <a href=\"https:\/\/xlogic.org\/hosting-condiviso\/\"><strong>Hosting Condiviso Xlogic<\/strong><\/a>.<\/p>\n<h2>HTTP\/3 richiede modifiche al sito?<\/h2>\n<p>Nella maggior parte dei casi no.<\/p>\n<p>Un&#8217;applicazione non deve essere riscritta per passare da HTTP\/2 a HTTP\/3.<\/p>\n<p>HTTP mantiene le stesse semantiche fondamentali.<\/p>\n<p>Il browser e il server negoziano automaticamente il protocollo utilizzabile.<\/p>\n<p>Questo significa che una normale pagina:<\/p>\n<pre><code>index.html<\/code><\/pre>\n<p>pu\u00f2 essere servita via HTTP\/1.1, HTTP\/2 oppure HTTP\/3 senza modificare il suo contenuto.<\/p>\n<h2>HTTP\/3 sostituisce HTTP\/2?<\/h2>\n<p>Nel lungo periodo HTTP\/3 continuer\u00e0 probabilmente a crescere, ma questo non significa che HTTP\/2 debba essere disattivato.<\/p>\n<p>I server moderni continuano normalmente a supportare pi\u00f9 protocolli contemporaneamente.<\/p>\n<p>La strategia corretta \u00e8 offrire:<\/p>\n<pre><code>HTTP\/3\r\nHTTP\/2\r\nHTTP\/1.1<\/code><\/pre>\n<p>e lasciare che client e server negozino quello pi\u00f9 appropriato.<\/p>\n<p>In questo modo rimane garantita la compatibilit\u00e0 anche con software o reti che non possono utilizzare QUIC.<\/p>\n<h2>HTTP\/3 nel 2026: quando offre il vantaggio maggiore<\/h2>\n<p>HTTP\/3 pu\u00f2 essere particolarmente interessante nei seguenti scenari:<\/p>\n<ul>\n<li>utenti mobili;<\/li>\n<li>reti 4G e 5G;<\/li>\n<li>connessioni con perdita di pacchetti;<\/li>\n<li>utenti lontani geograficamente dal server;<\/li>\n<li>pagine con molte richieste;<\/li>\n<li>applicazioni web interattive;<\/li>\n<li>frequente cambio tra Wi-Fi e rete mobile;<\/li>\n<li>grandi volumi di traffico distribuito.<\/li>\n<\/ul>\n<p>Il beneficio pu\u00f2 invece essere molto ridotto quando:<\/p>\n<ul>\n<li>rete e server sono molto vicini;<\/li>\n<li>la latenza \u00e8 gi\u00e0 bassissima;<\/li>\n<li>il sito contiene pochissime risorse;<\/li>\n<li>il vero limite \u00e8 PHP o il database;<\/li>\n<li>la pagina \u00e8 dominata da JavaScript pesante;<\/li>\n<li>le immagini sono enormi;<\/li>\n<li>il server risponde lentamente indipendentemente dalla rete.<\/li>\n<\/ul>\n<h2>HTTP\/3 su Xlogic e LiteSpeed Enterprise<\/h2>\n<p>L&#8217;infrastruttura Xlogic utilizza LiteSpeed Enterprise nei servizi compatibili, insieme a tecnologie dedicate alla gestione efficiente dei siti e delle applicazioni PHP.<\/p>\n<p>LiteSpeed supporta HTTP\/3 e QUIC nativamente e pu\u00f2 quindi negoziare il protocollo con i browser compatibili quando rete e configurazione lo consentono.<\/p>\n<p>Il vantaggio non deriva per\u00f2 dalla singola sigla HTTP\/3.<\/p>\n<p>Le prestazioni di un sito dipendono dall&#8217;interazione tra:<\/p>\n<ul>\n<li>web server;<\/li>\n<li>rete;<\/li>\n<li>PHP;<\/li>\n<li>OPcache;<\/li>\n<li>cache;<\/li>\n<li>database;<\/li>\n<li>storage;<\/li>\n<li>CPU e RAM;<\/li>\n<li>ottimizzazione del frontend.<\/li>\n<\/ul>\n<p>HTTP\/3 rappresenta quindi uno dei componenti di uno stack moderno, non una soluzione universale a qualsiasi problema di velocit\u00e0.<\/p>\n<h2>Checklist HTTP\/3<\/h2>\n<p>Per verificare che un ambiente sia pronto per HTTP\/3 puoi controllare:<\/p>\n<ol>\n<li>web server compatibile con HTTP\/3;<\/li>\n<li>HTTPS correttamente configurato;<\/li>\n<li>TLS moderno;<\/li>\n<li>UDP 443 disponibile;<\/li>\n<li>firewall configurato correttamente;<\/li>\n<li>header Alt-Svc quando previsto;<\/li>\n<li>browser moderno;<\/li>\n<li>negoziazione effettiva del protocollo;<\/li>\n<li>fallback HTTP\/2 funzionante;<\/li>\n<li>test da reti differenti.<\/li>\n<\/ol>\n<h2>Conclusioni<\/h2>\n<p><strong>HTTP\/3 nel 2026<\/strong> rappresenta un&#8217;evoluzione importante del modo in cui browser e server comunicano.<\/p>\n<p>Il passaggio da TCP a QUIC permette di gestire stream indipendenti, ridurre gli effetti dell&#8217;Head-of-Line Blocking a livello di trasporto e integrare pi\u00f9 strettamente la creazione della connessione con TLS.<\/p>\n<p>Le caratteristiche di QUIC risultano particolarmente interessanti sulle reti mobili, sulle connessioni con perdita di pacchetti e nei collegamenti caratterizzati da latenza elevata.<\/p>\n<p>Questo non significa per\u00f2 che qualsiasi sito diventi automaticamente molto pi\u00f9 veloce.<\/p>\n<p>HTTP\/3 non risolve:<\/p>\n<ul>\n<li>PHP lento;<\/li>\n<li>database inefficiente;<\/li>\n<li>query pesanti;<\/li>\n<li>immagini enormi;<\/li>\n<li>JavaScript eccessivo;<\/li>\n<li>cache assente;<\/li>\n<li>risorse server insufficienti.<\/li>\n<\/ul>\n<p>La strategia migliore consiste quindi nell&#8217;utilizzare HTTP\/3 come parte di un&#8217;infrastruttura moderna insieme a:<\/p>\n<p><strong>LiteSpeed + cache + PHP ottimizzato + storage veloce + immagini moderne + frontend efficiente.<\/strong><\/p>\n<p>Per l&#8217;utente finale il passaggio \u00e8 generalmente trasparente: browser e server negoziano automaticamente il miglior protocollo disponibile.<\/p>\n<p><strong>HTTP\/3 non sostituisce una buona ottimizzazione del sito, ma rende il trasporto dei dati pi\u00f9 adatto all&#8217;Internet moderno.<\/strong><\/p>\n<h2>Domande frequenti su HTTP\/3<\/h2>\n<h3>Cos&#8217;\u00e8 HTTP\/3?<\/h3>\n<p>HTTP\/3 \u00e8 la pi\u00f9 recente grande versione del protocollo HTTP. Utilizza QUIC come protocollo di trasporto invece di TCP ed \u00e8 standardizzato dalla RFC 9114.<\/p>\n<h3>HTTP\/3 utilizza TCP?<\/h3>\n<p>No. HTTP\/3 utilizza QUIC, che viene eseguito sopra UDP. QUIC implementa direttamente funzioni come affidabilit\u00e0, gestione degli stream, controllo della congestione e crittografia.<\/p>\n<h3>HTTP\/3 \u00e8 pi\u00f9 veloce di HTTP\/2?<\/h3>\n<p>Pu\u00f2 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\u00f2 essere ridotto.<\/p>\n<h3>HTTP\/3 funziona con HTTPS?<\/h3>\n<p>S\u00ec. QUIC integra TLS 1.3 nel protocollo e HTTP\/3 viene normalmente utilizzato attraverso connessioni cifrate.<\/p>\n<h3>Cos&#8217;\u00e8 QUIC?<\/h3>\n<p>QUIC \u00e8 un protocollo di trasporto standardizzato dalla IETF. \u00c8 basato su UDP e fornisce stream multiplexati, controllo della congestione, ritrasmissione, crittografia e altre funzioni necessarie a HTTP\/3.<\/p>\n<h3>HTTP\/3 risolve il problema Head-of-Line Blocking?<\/h3>\n<p>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.<\/p>\n<h3>LiteSpeed supporta HTTP\/3?<\/h3>\n<p>S\u00ec. LiteSpeed Web Server supporta HTTP\/3 e QUIC nativamente. La disponibilit\u00e0 effettiva dipende comunque anche dalla configurazione della rete e del firewall.<\/p>\n<h3>Come verifico se il mio sito usa HTTP\/3?<\/h3>\n<p>\u00c8 possibile controllare il protocollo tramite la scheda Network dei Developer Tools del browser. Nei browser Chromium la colonna Protocol pu\u00f2 mostrare <code>h3<\/code> quando la richiesta viene effettuata tramite HTTP\/3.<\/p>\n<h3>HTTP\/3 usa la porta 443?<\/h3>\n<p>S\u00ec, normalmente utilizza UDP sulla porta 443, mentre HTTPS tradizionale con HTTP\/2 utilizza TCP 443.<\/p>\n<h3>Se HTTP\/3 non funziona il sito diventa irraggiungibile?<\/h3>\n<p>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 \u00e8 disponibile.<\/p>\n<h3>HTTP\/3 migliora automaticamente Core Web Vitals?<\/h3>\n<p>No. Pu\u00f2 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.<\/p>\n<h3>Devo modificare il codice HTML per usare HTTP\/3?<\/h3>\n<p>No. Il protocollo viene negoziato tra browser e infrastruttura server. Nella maggior parte dei casi il sito non richiede modifiche applicative.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>HTTP\/3 \u00e8 la pi\u00f9 recente evoluzione principale del protocollo HTTP e nel 2026 \u00e8 ormai una tecnologia concreta utilizzata da browser, CDN e web server moderni. La differenza pi\u00f9 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 [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":19346,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"no","_lmt_disable":"","footnotes":""},"categories":[5],"tags":[],"class_list":["post-19336","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"modified_by":"Team tecnico Xlogic","_links":{"self":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts\/19336","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/comments?post=19336"}],"version-history":[{"count":1,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts\/19336\/revisions"}],"predecessor-version":[{"id":19347,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts\/19336\/revisions\/19347"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/media\/19346"}],"wp:attachment":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/media?parent=19336"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/categories?post=19336"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/tags?post=19336"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}