HTTP/3 su WordPress: come si attiva e quanto cambia davvero

HTTP/3 è la terza versione del protocollo con cui il browser e il server si parlano. Non cambia il tuo sito: cambia il modo in cui i suoi file viaggiano, e lo fa abbandonando TCP per un trasporto costruito su UDP. Attivarlo su WordPress costa dieci minuti se hai una CDN davanti al sito, un pomeriggio se gestisci il server da solo.

Questa guida spiega che cos’è, quanto cambia davvero e in quali casi non cambia niente, quali sono i prerequisiti veri, come si attiva nei tre scenari più comuni e — la parte che manca quasi ovunque — come si verifica in dieci secondi che stia funzionando. Perché il modo più frequente di sbagliare con HTTP/3 non è configurarlo male: è credere di averlo attivo quando non lo è.

Versioni, percorsi dei pannelli e comandi sono stati verificati sulle fonti ufficiali il 3 settembre 2026.

Una versione precedente di questo articolo conteneva indicazioni non più corrette, tutte sistemate qui sotto. Diceva che NGINX non supportava ancora HTTP/3 nel ramo stabile e che bisognava compilarlo dai sorgenti: il supporto è invece nel ramo mainline dal maggio 2023 e in quello stabile dall’aprile 2024. Il blocco di configurazione conteneva inoltre una variabile inesistente, che impedisce a NGINX di avviarsi. Il percorso per attivare HTTP/3 su Cloudflare è cambiato, e la sezione su LiteSpeed ometteva il requisito che conta davvero, l’apertura della porta UDP 443.

Che cos’è HTTP/3, in due minuti

HTTP/3 è uno standard pubblicato, non una tecnologia sperimentale: la specifica è la RFC 9114 del giugno 2022, che poggia sul trasporto QUIC definito dalla RFC 9000 del maggio 2021. È il dato da tenere a mente quando si legge che «è ancora presto»: sono passati quattro anni, e i browser che lo parlano coprono oggi il 94% del traffico globale.

Perché è nato: il limite che si porta dietro TCP

HTTP/1.1 apriva una connessione per volta e caricava le risorse in fila. HTTP/2 ha risolto quel problema con il multiplexing: più richieste viaggiano insieme sulla stessa connessione. Ma HTTP/2 resta appoggiato a TCP, e TCP ha una regola rigida: i pacchetti vanno consegnati in ordine.

La conseguenza si chiama head-of-line blocking. Se si perde un pacchetto — cosa normale su una rete mobile — TCP blocca la consegna di tutto quello che è arrivato dopo, finché il pacchetto perso non viene ritrasmesso. Le altre dieci risorse sono già sul dispositivo dell’utente, ma restano in attesa. Su una connessione stabile non te ne accorgi. Su un treno, sì.

Che cosa cambia con QUIC

QUIC ricostruisce quel meccanismo sopra UDP, e in questo modo ottiene tre cose che TCP non può dare:

• Flussi indipendenti. La perdita di un pacchetto rallenta solo la risorsa a cui appartiene, non tutte le altre. È la differenza sostanziale rispetto a HTTP/2.
• TLS 1.3 integrato nel trasporto. La cifratura non è un livello che si negozia dopo: fa parte della stessa stretta di mano. Ne derivano meno round-trip per aprire la connessione, e la possibilità di riprendere una sessione già nota senza attese (0-RTT).
• La connessione non è più legata all’indirizzo IP ma a un identificatore. Quando il telefono passa dal Wi-Fi alla rete mobile, la connessione sopravvive invece di ricominciare da capo.

Da qui viene una conseguenza pratica che torna più avanti: HTTP/3 non richiede nessuna modifica al sito. Non tocca WordPress, non tocca il tema, non tocca i plugin. Si negozia fra browser e server, e o è disponibile o non lo è.

Una parola sullo 0-RTT, perché viene sempre citato come il vantaggio principale e raramente per intero. Permette al browser che ha già parlato con quel server di inviare la prima richiesta insieme alla stretta di mano, risparmiando un giro completo. In cambio, quei primi dati non godono della stessa protezione contro il rigioco: un attaccante che li intercetti può ritrasmetterli. Per una richiesta di lettura non cambia nulla, ed è il caso della quasi totalità del traffico di un sito di contenuti; per operazioni che modificano dati la specifica prescrive cautela, e server e CDN la applicano da soli limitando lo 0-RTT alle richieste sicure. Non è qualcosa che devi configurare, ma è utile sapere perché esiste quella distinzione.

Quanto cambia davvero, e per chi

È la domanda che quasi nessuna guida affronta, e senza una risposta onesta il rischio è attivare HTTP/3 aspettandosi un salto di prestazioni che non arriverà. HTTP/3 lavora su un pezzo preciso del tempo di caricamento: la latenza con cui si apre e si mantiene la connessione. Su tutto il resto non ha voce.

Dove il guadagno si vede

• Sul mobile, e sulle reti che perdono pacchetti. È il caso per cui QUIC è stato progettato: niente head-of-line blocking, e la connessione che sopravvive al cambio di rete.
• Su visitatori geograficamente lontani dal server. Più aumenta il tempo di andata e ritorno, più pesano i round-trip risparmiati all’apertura della connessione.
• Su pagine con molte risorse dallo stesso host. Più flussi paralleli ci sono, più conta che uno non blocchi gli altri.
• Sulla prima visita. È lì che si paga per intero la stretta di mano che HTTP/3 accorcia.

Dove non si vede per niente

Ed è la lista più utile delle due, perché contiene le cause per cui i siti sono lenti davvero:

• Non abbassa il TTFB di un server lento. Se WordPress impiega ottocento millisecondi a costruire la pagina, il protocollo di trasporto non ha nulla da ottimizzare: il tempo se ne va prima, dentro PHP e nel database.
• Non compensa una pagina pesante. Quattro megabyte di immagini non ottimizzate restano quattro megabyte.
• Non risolve i plugin di troppo, né il JavaScript che blocca il rendering.
• Su fibra, vicino al datacenter, il guadagno è vicino a zero. Se misuri da casa con una buona connessione e il server è nella tua stessa città, probabilmente non vedrai alcuna differenza — e non significa che non stia funzionando.

Merita una riga a parte il rapporto con la cache, perché è la confusione più frequente. Un plugin di caching e HTTP/3 lavorano su due piani che non si toccano: il primo evita che WordPress ricostruisca la pagina a ogni visita, il secondo accorcia il viaggio di quella pagina fino al browser. Nessuno dei due sostituisce l’altro, e nessuno dei due attiva l’altro — se stai scegliendo fra W3 Total Cache e WP Rocket, quella decisione è indipendente da questa. La cache però va prima: risparmia centinaia di millisecondi dove HTTP/3 ne risparmia decine.

Detto in una riga: HTTP/3 è un’ottimizzazione dell’ultimo tratto, e va fatta dopo le altre. Se il tuo sito è lento, le ragioni sono quasi sempre altre sei, e le ho raccolte in sito lento: le cause reali e come risolverle. Attivare HTTP/3 prima di aver sistemato quelle è come cambiare le gomme a un’auto senza benzina.

Come misurarlo, prima e dopo

Se vuoi sapere se ha funzionato, la misura va impostata prima di attivarlo, e va fatta sui dati che riflettono il caso d’uso giusto: mobile, rete lenta, pagina interna, non la home aperta dal tuo computer. I dati di campo di Search Console si muovono su una finestra di 28 giorni, quindi il confronto onesto arriva dopo un mese; nel frattempo servono a verificare la direzione, non la misura.

La metrica su cui aspettarsi qualcosa è l’LCP, e solo per la quota di tempo che dipende dalla connessione. Se ti aspetti di veder cambiare l’INP resterai deluso: quello dipende da quanto JavaScript gira nel browser, che è materia di lazy loading, caching e minificazione.

C’è però una misura diretta che puoi fare subito, e isola esattamente la parte su cui HTTP/3 incide: il tempo di apertura della connessione, confrontato fra i due protocolli sullo stesso indirizzo.

# Stessa URL, due protocolli, tre tempi: DNS, connessione, primo byte.
FMT='dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s proto=%{http_version}\n'

curl -so /dev/null -w "$FMT" --http2      https://esempio.it/
curl -so /dev/null -w "$FMT" --http3-only https://esempio.it/

Lancia ogni riga tre o quattro volte e guarda i valori più bassi, non la media: la prima esecuzione paga la risoluzione DNS e non è confrontabile. La differenza che cerchi è su connect; se anche ttfb resta identico, hai la conferma sperimentale di quanto scritto sopra — il tempo se ne va dentro il server, e il protocollo non c’entra. È un test che vale la pena fare anche da una connessione mobile in tethering, che è lo scenario in cui HTTP/3 dà il meglio.

I prerequisiti, in ordine di quanto costa scoprirli tardi

Prima dei tre, un prerequisito zero che salta quasi sempre: hai già HTTP/2? Sembra scontato nel 2026 e non lo è — sugli hosting condivisi più economici e su qualche VPS configurato a mano anni fa si viaggia ancora in HTTP/1.1. Il salto da HTTP/1.1 a HTTP/2 vale molto più di quello da HTTP/2 a HTTP/3, perché è lì che arriva il multiplexing, cioè il grosso del guadagno. Si verifica con lo stesso comando della sezione sulle verifiche, cambiando l’opzione in --http2: se la risposta dice HTTP/1.1, chiudi questa pagina e parti da lì.

1. Qualcosa che parli HTTP/3 davanti al sito

O il server web, o una CDN. Non serve verificare l’uno e l’altra: se metti una CDN davanti al sito, è lei a parlare con il browser, e il protocollo fra CDN e server di origine è un’altra faccenda che non riguarda i tuoi visitatori.

Sull’hosting condiviso non hai voce in capitolo: o il provider lo offre, o non lo attivi. Invece di fidarti di un elenco di fornitori — che invecchia nel giro di mesi — il criterio è verificarlo da solo in trenta secondi con il comando della sezione successiva, puntandolo a un sito ospitato da quel provider. Se il provider non lo supporta e ci tieni, le strade sono due: mettere davanti una CDN che lo faccia, oppure cambiare hosting senza restare offline. La prima costa molto meno.

2. Un certificato valido, con TLS 1.3

Non è una raccomandazione, è un requisito della specifica: HTTP/3 esiste solo cifrato. Un certificato gratuito Let’s Encrypt va benissimo — la parte che conta è che il server sia configurato per negoziare TLS 1.3, cosa vera per impostazione predefinita su qualunque installazione recente. Se stai sistemando anche il resto, il certificato è il controllo numero uno della checklist di sicurezza WordPress.

3. La porta UDP 443 aperta — è qui che si arenano quasi tutti

HTTP/3 viaggia su UDP. La porta 443 che hai già aperto è quella TCP, e sono due cose distinte: sul firewall del server, sul firewall del provider e su qualunque apparato in mezzo. È la causa più frequente per cui HTTP/3 «non si attiva» pur essendo configurato correttamente, e non compare quasi mai nelle guide perché chi le scrive lavora su macchine dove UDP 443 era già aperta.

# Aprire UDP 443 (esempio con ufw su Debian/Ubuntu)
sudo ufw allow 443/udp
sudo ufw status | grep 443

# Verificare che il server stia davvero ascoltando su UDP 443
sudo ss -ulnp | grep :443

Se l’ultimo comando non restituisce nulla, non c’è configurazione di HTTP/3 che possa funzionare: nessun processo sta ascoltando.

Come si attiva: le tre strade

Con Cloudflare — dieci minuti, ed è la via più comune

Se il dominio passa già da Cloudflare, è un interruttore. Il percorso nel pannello è cambiato rispetto a qualche anno fa, ed è oggi:

1. Dalla dashboard, seleziona l’account e il dominio.
2. Vai su Speed → Settings.
3. Apri Protocol Optimization.
4. Porta su On l’interruttore HTTP/3.

È disponibile su tutti i piani, incluso quello gratuito, e non richiede alcuna modifica al sito: da quel momento Cloudflare negozia HTTP/3 con i browser che lo supportano e continua a servire gli altri in HTTP/2. Nota che la CDN davanti al sito fa anche altro, a partire dalla protezione contro attacchi DDoS e brute force: se la stai valutando solo per il protocollo, stai sottovalutando il resto.

Con LiteSpeed o OpenLiteSpeed — probabilmente è già attivo

Qui c’è il fraintendimento più diffuso. Sui server LiteSpeed QUIC e HTTP/3 sono attivi per impostazione predefinita, e la documentazione è esplicita nel dire che non serve alcuna modifica di configurazione. Se non funziona, il problema non è un’opzione da spuntare: è la porta UDP 443 della sezione precedente.

L’interruttore esiste comunque, e vale la pena sapere dov’è nel caso qualcuno l’abbia disattivato: nella WebAdmin Console sta nella scheda SSL, alla voce Enable HTTP3/QUIC, sia a livello di listener sia a livello di server — e perché il listener funzioni, l’impostazione dev’essere attiva anche a livello di server.

Sullo stesso stack gira QUIC.cloud, la CDN sviluppata dal team di LiteSpeed, che serve i contenuti in HTTP/3 dai propri nodi ed è pensata per funzionare con il plugin LiteSpeed Cache. È un’alternativa a Cloudflare, non un complemento: due CDN davanti allo stesso sito sono un problema, non un vantaggio.

Con NGINX su un VPS — e qui va corretta una cosa che si legge ovunque

Non serve più compilare NGINX dai sorgenti. Il supporto a HTTP/3 è arrivato nel ramo mainline con la versione 1.25.0 del 23 maggio 2023 ed è nel ramo stabile dalla serie 1.26, dell’aprile 2024. Alla data di questa revisione i rami correnti sono 1.31 per il mainline e 1.30 per lo stable: qualunque pacchetto recente lo include. Le guide che ti mandano a compilare il ramo nginx-quic da GitHub sono ferme a prima del 2023.

Prima di configurare, verifica che il binario che hai installato includa il modulo:

nginx -v
nginx -V 2>&1 | tr ' ' '\n' | grep http_v3

Se il secondo comando stampa --with-http_v3_module, sei a posto. La configurazione minima è questa, e le due direttive listen servono entrambe:

server {
    listen 443 quic reuseport;   # HTTP/3, su UDP
    listen 443 ssl;              # HTTP/2 e HTTP/1.1, su TCP: il fallback

    server_name esempio.it;

    http2 on;                    # dalla 1.25.1 è una direttiva a sé, e il default è off

    ssl_certificate     /etc/letsencrypt/live/esempio.it/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/esempio.it/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    # Annuncia ai browser che HTTP/3 è disponibile sulla stessa porta.
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    # Utile in fase di verifica: registra il protocollo negoziato.
    add_header X-Protocol $http3 always;
}

Tre avvertenze, e la seconda è quella che fa perdere il pomeriggio.

• reuseport va indicato una volta sola in tutta la configurazione, non su ogni blocco server: ripeterlo impedisce a NGINX di avviarsi.
• La variabile che espone il protocollo negoziato è $http3 — vale h3 su una connessione HTTP/3 e stringa vuota altrimenti. Molte guide riportano $quic, che non esiste: con una variabile sconosciuta NGINX non parte proprio, e l’errore che leggi nei log parla di una variabile ignota, non di HTTP/3.
• Senza l’intestazione Alt-Svc nessun browser proverà HTTP/3: è così che il server annuncia che la porta UDP è disponibile.
• La riga http2 on; non è un di più. Dalla versione 1.25.1 HTTP/2 si attiva con una direttiva propria, e il suo valore predefinito è off: senza quella riga il fallback per chi non parla HTTP/3 non è HTTP/2 ma HTTP/1.1, e avresti attivato il protocollo nuovo peggiorando l’esperienza di tutti gli altri.

Poi, come sempre, si verifica la sintassi prima di ricaricare — su un VPS l’errore di configurazione è la via più rapida per mettere offline il sito, e vale quanto detto nella guida su installare e configurare WordPress su hosting condiviso o VPS:

sudo nginx -t && sudo systemctl reload nginx

Come verificare che sia davvero attivo

Questo è il passaggio che nella maggior parte delle guide manca, ed è quello che distingue «l’ho attivato» da «funziona».

Dalla riga di comando, in dieci secondi

# 1. Il tuo curl parla HTTP/3? Cerca "HTTP3" fra le Features.
curl --version

# 2. Il server ANNUNCIA HTTP/3? Si legge nell'intestazione Alt-Svc.
curl -sI https://esempio.it/ | grep -i alt-svc

# 3. Il server SERVE davvero HTTP/3?
curl -sI --http3-only https://esempio.it/

Il dettaglio che conta è nel terzo comando: si usa --http3-only, non --http3. La seconda opzione tenta HTTP/3 ma ricade su HTTP/2 o HTTP/1.1 se la connessione QUIC non si stabilisce in fretta — comodo per navigare, inutile per collaudare, perché ti restituisce una risposta valida anche quando HTTP/3 non c’è. Con --http3-only, se non funziona, il comando fallisce, ed è esattamente quello che vuoi sapere.

Se il primo comando non mostra HTTP3 fra le funzionalità, il curl installato non è stato compilato con il supporto: non è il tuo sito a non funzionare, è lo strumento con cui lo stai misurando.

Dal browser

In Chrome apri gli strumenti per sviluppatori, scheda Network, clic destro sull’intestazione delle colonne e aggiungi Protocol. Ricarica: le risorse servite in HTTP/3 mostrano h3. Due avvertenze pratiche: la prima visita spesso mostra ancora h2, perché il browser deve prima leggere l’annuncio Alt-Svc e solo dalla richiesta successiva prova QUIC; e le risorse servite da domini terzi seguono il protocollo di quei domini, non del tuo.

Gli strumenti online

Esistono servizi che fanno il controllo da una pagina web, come http3check.net. Sono comodi per un controllo veloce da un dispositivo su cui non hai un terminale, ma testano dalla loro rete e non dalla tua, e possono sparire senza preavviso: il comando curl resta il riferimento. Per misurare l’effetto sulle prestazioni, invece, servono gli strumenti che simulano condizioni di rete reali — l’argomento è trattato per esteso nella checklist SEO on-page, dove le performance sono uno dei quindici controlli.

Che cosa può andare storto

I casi che incontro più spesso, in ordine di frequenza.

Vale la pena insistere sul penultimo: una quota dei tuoi visitatori non userà HTTP/3 comunque, per via di reti che filtrano UDP. È il motivo per cui la riga listen 443 ssl; non è opzionale, e per cui HTTP/3 va pensato come un miglioramento per la maggioranza, non come una sostituzione.

C’è poi un effetto collaterale che coglie di sorpresa chi gestisce il proprio server: il traffico UDP viene contato e filtrato in modo diverso da quello TCP. Regole di protezione anti-DDoS impostate anni fa, che ignoravano UDP perché sulla porta 443 non passava nulla, possono ora limitare o scartare traffico legittimo — con il risultato di un sito che funziona per la maggior parte delle persone e non per alcune, in modo apparentemente casuale. Se dopo l’attivazione compaiono segnalazioni sporadiche e irriproducibili, quelle regole sono il primo posto dove guardare.

Infine, una nota che riguarda il lungo periodo. HTTP/3 non è un’attivazione da fare una volta e dimenticare: dipende da componenti che cambiano sotto di te — un aggiornamento del server web, una modifica alle regole del firewall, un cambio di piano della CDN. Il controllo giusto è il comando di verifica, ripetuto ogni tanto, ed è il tipo di cosa che sta bene in una lista di manutenzione periodica insieme a backup e aggiornamenti, non nella memoria di chi l’ha configurato.

Domande frequenti

In sintesi: quando vale la pena

Se hai già una CDN davanti al sito, attivalo: è un interruttore, non ha controindicazioni e su una parte dei tuoi visitatori qualcosa guadagni. Se gestisci il server, mettilo in lista dopo aver sistemato le cose che pesano di più — hosting, immagini, cache, JavaScript — perché è lì che stanno i secondi, non i millisecondi.

E qualunque strada tu prenda, verifica. Il modo più comune di sbagliare con HTTP/3 non è configurarlo male: è darlo per attivo quando una porta UDP chiusa lo tiene spento da mesi, e continuare a leggere numeri che non cambiano chiedendosi perché.

Se preferisci che a occuparsene sia qualcuno che lo fa di mestiere — dalla misura iniziale alla configurazione, fino alla verifica che stia funzionando davvero — posso farlo io, insieme al resto degli interventi sulle prestazioni.

Parliamo delle prestazioni del tuo sito »