Quando si parla di velocità di un sito, si pensa quasi sempre a ciò che il server fa per generare la pagina e a ciò che il browser fa per mostrarla. In mezzo c’è la rete, che di solito viene data per scontata. Eppure, su uno smartphone connesso a una rete mobile, una parte rilevante del tempo di caricamento non dipende né dal server né dal browser, ma dal numero di viaggi che i dati devono compiere e da ciò che succede quando qualche pacchetto si perde per strada.
HTTP/3, basato sul protocollo di trasporto QUIC, nasce proprio per ridurre questi costi. È supportato da tutti i browser principali, dalle maggiori CDN e da un numero crescente di server web, e una parte consistente del traffico web lo usa già. In questo articolo vediamo cosa cambia rispetto a HTTP/2, perché i vantaggi si concentrano sulle reti mobili, come attivarlo e cosa aspettarsi realisticamente sulle Core Web Vitals.
Da HTTP/1.1 a HTTP/3, in breve
Con HTTP/1.1 ogni connessione poteva gestire una sola richiesta alla volta: per scaricare molte risorse in parallelo, i browser aprivano fino a sei connessioni per dominio, ciascuna con il proprio costo di apertura. HTTP/2 ha introdotto il multiplexing: più richieste contemporanee sulla stessa connessione, suddivise in flussi indipendenti. È stato un grande passo avanti, ma con un limite strutturale: HTTP/2 viaggia su TCP, e TCP consegna i dati in un unico ordine rigoroso.
HTTP/3 mantiene lo stesso modello di HTTP/2, con richieste multiple su una connessione, ma sostituisce TCP con QUIC, un protocollo di trasporto costruito su UDP. QUIC integra la cifratura TLS 1.3 direttamente nel trasporto, gestisce ogni flusso in modo indipendente e identifica le connessioni con un proprio identificativo invece che con indirizzo e porta. Queste tre scelte producono i tre vantaggi principali: connessioni più rapide da aprire, nessun blocco a catena quando si perde un pacchetto e connessioni che sopravvivono al cambio di rete.
Primo vantaggio: meno viaggi per iniziare
Prima di poter chiedere una pagina con HTTP/2, il browser deve aprire una connessione TCP, che richiede un viaggio di andata e ritorno verso il server, e poi negoziare la cifratura TLS, che con TLS 1.3 richiede un altro viaggio. Solo al terzo viaggio parte la richiesta vera e propria. Con QUIC, apertura della connessione e negoziazione della cifratura avvengono insieme, in un solo viaggio. Quando il browser si è già collegato di recente allo stesso server, QUIC permette anche la ripresa 0-RTT: la richiesta viene inviata insieme al primo pacchetto, senza alcuna attesa preliminare.
Il valore di un viaggio dipende dalla latenza. Su una fibra con un server vicino, un viaggio può durare meno di 10 millisecondi, e risparmiarne uno è quasi irrilevante. Su una rete mobile, dove la latenza è spesso tra 50 e 150 millisecondi e può salire molto di più con segnale debole, ogni viaggio risparmiato si traduce direttamente in un TTFB più basso sulla prima richiesta. E poiché l’LCP comincia dal TTFB, il guadagno si propaga a tutta la pagina.
Va detto che la ripresa 0-RTT ha una limitazione di sicurezza: i dati inviati nel primo pacchetto potrebbero essere ritrasmessi da un malintenzionato che li abbia intercettati. Per questo si usa solo per richieste senza effetti collaterali, come il caricamento di una pagina, e i server la rifiutano per operazioni che modificano dati. È una scelta che gestiscono server e CDN, ma è utile conoscerla per capire perché il vantaggio 0-RTT non si applica a tutto.
Secondo vantaggio: nessun blocco a catena
Il limite più importante di HTTP/2 emerge quando la rete perde pacchetti, cosa normale su reti mobili e Wi-Fi congestionate. TCP garantisce che i dati arrivino all’applicazione esattamente nell’ordine in cui sono stati inviati: se un pacchetto si perde, tutti quelli arrivati dopo restano in attesa finché il pacchetto mancante non viene ritrasmesso. Con HTTP/2, dove HTML, CSS, immagini e script condividono la stessa connessione TCP, la perdita di un solo pacchetto del CSS blocca anche l’HTML e le immagini, che pure sono arrivati integri. È il cosiddetto blocco in testa alla coda, o head-of-line blocking.
QUIC risolve il problema gestendo l’ordinamento per singolo flusso. Se si perde un pacchetto del CSS, aspetta solo il CSS; HTML e immagini continuano ad arrivare e a essere elaborati. Su una rete stabile la differenza è minima, ma con una percentuale di perdita anche solo dell’uno o due per cento, frequente su mobile, la differenza nei tempi di caricamento diventa misurabile, soprattutto nella parte alta della distribuzione: i caricamenti peggiori migliorano più di quelli medi. Ed è proprio la parte alta della distribuzione che conta per le Core Web Vitals, valutate al 75° percentile.
Terzo vantaggio: il cambio di rete
Una connessione TCP è identificata da indirizzo e porta di entrambe le parti. Quando uno smartphone passa dal Wi-Fi alla rete mobile, per esempio uscendo di casa o da un negozio, il suo indirizzo cambia e tutte le connessioni TCP si interrompono: vanno riaperte da zero, con tutti i viaggi che comporta. QUIC identifica la connessione con un proprio identificativo, indipendente dall’indirizzo, e può quindi proseguire sulla nuova rete senza ricominciare. Per chi naviga in movimento è un vantaggio concreto, anche se difficile da vedere nei test di laboratorio.
Come il browser scopre HTTP/3
Un browser non sa a priori se un server supporta HTTP/3. Nel caso più comune, la prima connessione avviene con HTTP/2, e il server comunica il supporto a HTTP/3 con l’intestazione Alt-Svc:
alt-svc: h3=":443"; ma=86400Il browser memorizza l’informazione e, dalle richieste successive o dalla visita successiva, usa HTTP/3. Questo significa che la primissima visita di un utente spesso non ne beneficia. Per eliminare questo passaggio esiste il record DNS di tipo HTTPS, che annuncia i protocolli supportati già nella risoluzione del nome: il browser può così usare HTTP/3 fin dalla prima connessione. Le principali CDN lo pubblicano automaticamente quando HTTP/3 è attivo.
C’è anche un meccanismo di sicurezza: QUIC usa UDP, e alcune reti aziendali, alberghiere o pubbliche bloccano o limitano il traffico UDP sulla porta 443. In quel caso il browser torna automaticamente a HTTP/2 su TCP, senza errori per l’utente. HTTP/3 è quindi un miglioramento che si aggiunge, non una sostituzione che può rompere qualcosa.
Come attivarlo
Il modo più semplice è una CDN o un proxy che lo supporti: Cloudflare, Fastly, Akamai, Amazon CloudFront e molti altri offrono HTTP/3 verso gli utenti, spesso con un’opzione da attivare nel pannello. In questo caso la connessione HTTP/3 riguarda il tratto tra utente e nodo della CDN, che è proprio quello con la latenza e le perdite più alte; il tratto tra CDN e server d’origine continua a usare HTTP/1.1 o HTTP/2, su reti di qualità molto migliore. È anche uno dei vantaggi concreti di una CDN che vale la pena distinguere da altre funzionalità, come abbiamo visto parlando di Cloudflare.
Sul server, il supporto dipende dal software. LiteSpeed lo supporta nativamente da anni, ed è uno dei motivi per cui compare spesso nei confronti di prestazioni, come abbiamo visto in quando il benchmark non vede lo stesso sito. Nginx lo include nelle versioni recenti, con un modulo dedicato da abilitare in compilazione e in configurazione; Caddy lo attiva per impostazione predefinita; Apache non ha un supporto nativo e richiede un proxy davanti. In ogni caso serve aprire la porta UDP 443 nel firewall, un dettaglio che viene dimenticato spesso e che rende HTTP/3 annunciato ma irraggiungibile.
server {
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
http3 on;
# Annuncia HTTP/3 ai browser
add_header Alt-Svc 'h3=":443"; ma=86400' always;
}Un aspetto da considerare è il consumo di risorse. QUIC è implementato nello spazio utente invece che nel kernel del sistema operativo, e la cifratura di ogni pacchetto ha un costo: a parità di traffico, un server HTTP/3 usa in genere più CPU di un server HTTP/2. Per le CDN non è un problema, per un piccolo server condiviso può esserlo. È uno dei motivi per cui, su molte infrastrutture, affidare HTTP/3 al livello della CDN è la scelta più sensata.
Come verificare che funzioni
Nel pannello Network dei DevTools di Chrome si può aggiungere la colonna Protocol: le risorse servite con HTTP/3 riportano h3, quelle con HTTP/2 h2. Alla prima visita è normale vedere h2 sul documento e h3 sulle risorse successive, per effetto del meccanismo di scoperta. Da riga di comando, le versioni recenti di curl compilate con il supporto a HTTP/3 permettono di forzarlo con l’opzione --http3, utile per distinguere un problema di configurazione del server da un blocco della rete.
Sugli utenti reali, le API Navigation Timing e Resource Timing espongono la proprietà nextHopProtocol, che indica il protocollo usato per ciascuna richiesta. Raccolta in un sistema di monitoraggio insieme alle metriche, permette di sapere quale quota di visite usa effettivamente HTTP/3 e di confrontare TTFB e LCP tra le due popolazioni. Il Chrome UX Report non distingue i dati per protocollo, per cui l’effetto sui dati di campo si osserva soprattutto come miglioramento generale del TTFB su mobile dopo l’attivazione.
const nav = performance.getEntriesByType( 'navigation' )[ 0 ];
console.log( nav.nextHopProtocol ); // "h3", "h2" oppure "http/1.1"Cosa aspettarsi davvero
HTTP/3 non trasforma un sito lento in un sito veloce. Se il server impiega un secondo a generare la pagina perché manca una cache, risparmiare cento millisecondi di connessione cambia poco; se la pagina scarica tre megabyte di JavaScript, il protocollo non li renderà più leggeri. I vantaggi si sommano a un sito già ben ottimizzato e si concentrano dove la rete è il collo di bottiglia: utenti da mobile, reti con alta latenza, connessioni instabili, visitatori lontani dal server.
Proprio per questo, però, sono vantaggi che contano per le Core Web Vitals. I dati di campo sono dominati dal mobile, e il 75° percentile è fatto degli utenti con le condizioni peggiori: quelli con segnale debole, in movimento, su reti congestionate. Sono esattamente gli utenti per cui HTTP/3 fa la differenza maggiore, ed è per questo che, a parità di tutto il resto, attivarlo tende a migliorare soprattutto la coda della distribuzione più che la media.
Anche per questo i vantaggi di HTTP/3 si vedono poco nei test di laboratorio. Lighthouse e PageSpeed Insights simulano una rete lenta applicando un rallentamento calcolato, ma non riproducono perdite di pacchetti né cambi di rete, e la prima visita del test spesso avviene ancora in HTTP/2. Strumenti come WebPageTest permettono di scegliere profili di rete più realistici, ma il quadro affidabile resta quello dei dati di campo, come abbiamo visto parlando del motivo per cui CrUX e test di laboratorio servono entrambi.
In sintesi
HTTP/3 porta le richieste web su QUIC, un trasporto basato su UDP con cifratura integrata. Rispetto a HTTP/2 su TCP riduce i viaggi necessari per aprire una connessione, elimina il blocco a catena quando si perdono pacchetti e mantiene le connessioni attive nel passaggio tra reti diverse. Sono vantaggi modesti su una rete fissa veloce e significativi su quelle mobili, dove si misurano le Core Web Vitals più critiche.
Attivarlo è semplice con una CDN, possibile con i server web moderni ricordando di aprire la porta UDP 443, e sicuro grazie al ritorno automatico a HTTP/2 dove UDP è bloccato. Va verificato con la colonna Protocol dei DevTools e misurato sugli utenti reali con nextHopProtocol. Non sostituisce cache, immagini ottimizzate e JavaScript leggero, ma completa il lavoro nel punto in cui nessun’altra ottimizzazione può arrivare: il percorso dei dati tra il server e il telefono dell’utente.
