Cosa sono HTTP/2 e HTTP/3? Una guida pratica per i siti WordPress

HTTP/2 e HTTP/3 sono le due versioni attuali dell'Hypertext Transfer Protocol, il linguaggio che i browser usano per richiedere pagine ai server web. HTTP/2 è stato standardizzato nel 2015 ed è supportato dal 100% dei browser moderni. HTTP/3, finalizzato come RFC 9114 nel 2022, è supportato da ogni browser principale dal 2024. Entrambi sono aggiornamenti senza attriti rispetto a HTTP/1.1: stessi URL, stesso HTML, ma caricamenti di pagina significativamente più veloci, specialmente su reti mobili e connessioni ad alta latenza.

Risposta rapida: quale versione dovrebbe usare il mio sito WordPress?

Nel 2026, la risposta corretta è "HTTP/3 con fallback HTTP/2". Ogni browser negozia la versione più alta che entrambe le parti supportano, quindi non devi scegliere. Se il tuo server parla HTTP/3, i browser moderni lo usano; i browser più vecchi ripiegano su HTTP/2; i client antichi ripiegano su HTTP/1.1. Non esiste scenario in cui HTTP/2 o HTTP/3 sia più lento di HTTP/1.1 per una pagina WordPress reale, quindi la sola domanda è se il tuo stack di hosting lo supporti.

Quale problema risolve HTTP/2 rispetto a HTTP/1.1?

HTTP/1.1, il protocollo che ha tenuto in piedi il web dal 1997 al 2015, ha un difetto fatale su un sito moderno: apre una connessione TCP per risorsa, e solo sei in parallelo per dominio. Una tipica pagina WordPress carica da 50 a 150 risorse (CSS, JS, immagini, font, script di tracking). Sotto HTTP/1.1 quelle 100+ richieste si serializzano attraverso una coda di sei connessioni, ciascuna in attesa che la precedente finisca. Il browser sta letteralmente fermo aspettando che si liberino slot.

HTTP/2 risolve questo con tre cambiamenti:

• Multiplexing. Una singola connessione TCP trasporta un numero illimitato di coppie request/response parallele (chiamate stream). Tutte le 150 risorse viaggiano su una connessione, intrecciate.
• Compressione degli header (HPACK). Gli header HTTP (cookie, User-Agent, referer) spesso totalizzano diversi KB per richiesta. HPACK li comprime e ricorda gli header ripetuti, riducendo l'overhead per richiesta da kilobyte a byte.
• Framing binario. HTTP/1.1 è basato su testo e ambiguo da parsare. HTTP/2 usa un formato di frame binario più veloce da elaborare per server e proxy, ed elimina un'intera classe di attacchi di smuggling e parsing.

Effetto netto: una pagina WordPress che carica in 4 secondi su HTTP/1.1 carica tipicamente in 1,5 a 2,5 secondi su HTTP/2, sullo stesso server. Il miglioramento è maggiore su reti mobili perché l'overhead di setup della connessione è ammortizzato su tutte le richieste.

Cosa aggiunge HTTP/3 sopra HTTP/2?

HTTP/3 mantiene tutto ciò che HTTP/2 ha introdotto (multiplexing, compressione header, framing binario) ma sostituisce il trasporto sottostante. Invece di TCP, HTTP/3 gira su QUIC, un protocollo di trasporto costruito su UDP. Sembra un dettaglio implementativo ma risolve tre veri problemi di performance:

• Head-of-line blocking a livello TCP. HTTP/2 multiplexa stream su una connessione TCP, ma TCP stesso consegna i pacchetti in ordine. Se un pacchetto si perde, ogni stream su quella connessione si blocca finché non arriva la ritrasmissione. QUIC gestisce la perdita di pacchetti per stream, quindi un singolo pacchetto perso influisce solo sullo stream a cui appartiene.
• Setup di connessione più veloce. Stabilire una connessione HTTPS su TCP richiede tre round trip (handshake TCP, poi handshake TLS). QUIC li combina in un solo round trip per le connessioni prima volta, e zero round trip per le connessioni ripetute entro pochi minuti (chiamato 0-RTT). Su una connessione mobile con 100ms di latenza, questo risparmia 200-300ms prima che il primo byte di contenuto inizi a caricare.
• Migrazione di connessione. Le connessioni QUIC sono identificate da un connection ID, non da IP + porta. Quando un telefono passa da Wi-Fi a cellulare, la connessione QUIC sopravvive. Le connessioni TCP dovrebbero riconnettersi.

Guadagno reale sopra HTTP/2: tipicamente 5-15% più veloce per i primi caricamenti di pagina, di più su reti mobili con perdite, di meno su una connessione cablata stabile.

Come verifico quale versione HTTP sta usando attualmente il mio sito WordPress?

Quattro metodi affidabili, dal più veloce al più autorevole:

1. Report InspectWP. La sezione Performance di qualsiasi report InspectWP elenca la versione HTTP negoziata per il documento principale. Una riga, nessun setup.
2. Chrome DevTools. Apri DevTools (F12), tab Network, ricarica la pagina, clic destro su qualsiasi intestazione di colonna e abilita "Protocol". La colonna mostra h2 per HTTP/2 e h3 per HTTP/3 (anche chiamato http/3 in alcune versioni di Chrome).
3. Riga di comando con curl. Esegui curl -I --http2 https://tuosito.com per HTTP/2 o curl -I --http3 https://tuosito.com per HTTP/3 (curl 7.66+ richiesto). La riga di risposta mostra HTTP/2 200 o HTTP/3 200.
4. Strumenti pubblici di test. https://http3check.net testa specificamente il supporto HTTP/3. https://tools.keycdn.com/http2-test testa il supporto HTTP/2. Entrambi restituiscono la versione negoziata e l'header Alt-Svc (che pubblicizza il supporto HTTP/3).

Un trabocchetto: un sito può pubblicizzare HTTP/3 nel suo header Alt-Svc senza che HTTP/3 funzioni realmente. L'header dice al browser "la prossima volta, prova HTTP/3 sulla porta UDP 443", ma se UDP è bloccato in qualche punto del percorso, il browser ripiega silenziosamente su HTTP/2. Verifica sempre con una richiesta reale, non solo l'header Alt-Svc.

Come abilito HTTP/2 o HTTP/3 su un sito WordPress?

Le versioni HTTP sono negoziate a livello di server web. WordPress di per sé non ha nulla a che fare con questo; la scelta è tra il tuo stack di hosting e il browser. Tre scenari coprono quasi tutti i siti:

Scenario 1: hosting WordPress gestito

Quasi ogni host WordPress gestito (Kinsta, WP Engine, Raidboxes, SiteGround, Pressable, Cloudways) consegna HTTP/2 di default dal 2018. Il supporto HTTP/3 è ora diffuso ma non universale nel 2026. Kinsta, Cloudways, SiteGround, Raidboxes e Pressable hanno HTTP/3 abilitato di default. WP Engine lo offre come toggle. Se il tuo host non è in questa lista, chiedi al supporto; di solito è un cambio in un clic.

Scenario 2: hosting condiviso con cPanel o Plesk

Gli host cPanel (IONOS, Hostinger, molti rivenditori) tipicamente consegnano HTTP/2 di default e HTTP/3 sugli account più recenti. Verifica abilitando EasyApache 4 con il modulo mod_http2 se non già presente. HTTP/3 in Apache richiede il modulo mod_http3 che è ancora considerato sperimentale. La via pragmatica sull'hosting condiviso è mettere Cloudflare davanti (il tier gratuito basta) e lasciare a Cloudflare la terminazione HTTP/3, che è il loro default dal 2019.

Scenario 3: VPS o server dedicato autogestito

La configurazione dipende dal tuo server web:

• nginx. HTTP/2 richiede nginx 1.9.5+ e la direttiva http2 sulla tua linea listen: listen 443 ssl http2;. HTTP/3 richiede nginx 1.25+ compilato con supporto QUIC: listen 443 quic reuseport; listen 443 ssl; più add_header Alt-Svc 'h3=":443"; ma=86400';. Il flag reuseport è critico, altrimenti HTTP/3 silenziosamente non si avvia.
• Apache. HTTP/2 richiede mod_http2 abilitato e la direttiva Protocols h2 h2c http/1.1 nel tuo virtual host. HTTP/3 in Apache è ancora sperimentale; la maggior parte dei setup Apache di produzione si fermano a HTTP/2 e mettono nginx, Caddy o Cloudflare davanti per HTTP/3.
• Caddy. HTTP/3 è abilitato di default da Caddy 2.6. Niente da configurare; se HTTPS funziona, HTTP/3 funziona.
• LiteSpeed e OpenLiteSpeed. Entrambi consegnano HTTP/3 di default. Una ragione per cui LiteSpeed ha guadagnato quote nel mercato dell'hosting WordPress.

Un requisito che spesso si dimentica nei setup autogestiti: HTTP/3 richiede la porta UDP 443 aperta nel firewall. Molte configurazioni di server di default aprono solo TCP 443. Esegui sudo ufw allow 443/udp su Ubuntu o l'equivalente per il tuo stack firewall.

Qual è il ruolo di Cloudflare e di altri CDN?

Un CDN davanti al tuo server di origine tipicamente termina il protocollo moderno al bordo, poi parla con il tuo origine via HTTP/1.1 o HTTP/2. Dal punto di vista del visitatore, la connessione al nodo edge del CDN (spesso 20-50ms di distanza) è HTTP/3, veloce e moderna. Il link dal CDN all'origine avviene server-a-server in reti datacenter dove il protocollo conta molto meno. Ecco perché mettere Cloudflare davanti a un host condiviso che gira solo HTTP/1.1 dà comunque la maggior parte del beneficio in velocità. Il visitatore non tocca mai direttamente il tuo origine.

Il rovescio: se il tuo origine restituisce un header cache-busting (no-cache, no-store) o il tuo contenuto non è cacheable (pagine WordPress loggate, carrello WooCommerce), il CDN deve andare all'origine ad ogni richiesta, e il lento salto origine-a-CDN diventa il collo di bottiglia. Per quei casi, il protocollo sull'origine conta ancora.

Errori comuni e come evitarli

• Trattare HTTP/2 come una bacchetta magica per siti lenti. HTTP/2 risolve l'overhead di connessione. Non risolve PHP lento, query non ottimizzate, immagini hero da 5MB o JavaScript bloccante il rendering. Se il tuo TTFB (time to first byte) è di 2 secondi, passare a HTTP/3 ti risparmia 200ms. I restanti 1800ms sono ancora PHP e database.
• Dimenticare di mantenere HTTP/1.1 abilitato. I crawler dei motori di ricerca, gli strumenti di monitoraggio e le vecchie librerie client a volte parlano solo HTTP/1.1. Disabilitare HTTP/1.1 interamente le rompe. I server web moderni negoziano automaticamente la versione più alta mutuamente supportata; tieni abilitati tutti e tre (h3, h2, http/1.1).
• Concatenare e inlineare asset per abitudine HTTP/1.1. Sotto HTTP/1.1, combinare 30 file CSS in 1 era una grande vittoria a causa del limite di connessioni. Sotto HTTP/2 e HTTP/3 quell'ottimizzazione cessa di contare e può anche danneggiare (un singolo grande bundle invalida la cache per qualsiasi cambiamento; 30 piccoli file invalidano solo quelli che sono cambiati). La maggior parte dei plugin di performance WordPress impostano ancora "combina tutto" di default perché gli utenti se lo aspettano, ma non è più il default corretto nel 2026.
• Assumere che Alt-Svc significhi che HTTP/3 funziona. L'header pubblicizza il supporto HTTP/3; non garantisce che la connessione si stabilisca davvero. Verifica sempre con curl o DevTools.
• Bloccare UDP al firewall. Una causa comune del non funzionamento silenzioso di HTTP/3. Controlla sia il firewall del server sia quello di rete (security group del provider cloud, filtraggio a livello ISP sulle connessioni consumer).

HTTP/2, HTTP/3 e Core Web Vitals

I Core Web Vitals di Google misurano Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Dei tre, LCP è quello più influenzato dalla versione HTTP. L'elemento LCP (solitamente l'immagine hero o il blocco più grande sopra la piega) deve scaricarsi completamente prima che LCP possa essere riportato, e la velocità di download è esattamente ciò che HTTP/2 e HTTP/3 migliorano. I siti che passano da HTTP/1.1 a HTTP/2 vedono LCP calare di 300-800ms in media. Il salto da HTTP/2 a HTTP/3 è più piccolo, tipicamente 50-200ms, ma su reti mobili con perdita di pacchetti può essere maggiore.

Cosa controlla InspectWP

La sezione Performance di ogni report InspectWP mostra quale versione HTTP è stata negoziata per il documento principale, più la codifica di contenuto (gzip, Brotli) e la dimensione totale dell'HTML. Se il tuo sito è ancora su HTTP/1.1 nel 2026, il report lo segnala come avvertimento, perché è una delle vittorie di performance a più alto impatto e minor sforzo disponibili, solitamente un singolo interruttore nel pannello dell'hosting. Se sei su HTTP/2 ma non su HTTP/3, ciò appare come informativo; HTTP/3 è il default moderno ma HTTP/2 è ancora del tutto accettabile. La versione che vede il tuo browser è la versione che ricevono i tuoi visitatori, quindi il report riflette la performance reale, non la configurazione teorica.