HTTP/3 è il protocollo che, attivato su WordPress via Cloudflare, può ridurre sensibilmente i tempi di caricamento percepiti dagli utenti, soprattutto su connessioni mobile instabili. Non è una configurazione complessa da attivare, ma capire cosa fa concretamente, e perché impatta i Core Web Vitals, fa la differenza tra chi lo gestisce in modo consapevole e chi lo lascia disattivo per default.
Cloudflare supporta HTTP/3 con QUIC da anni. Il problema è che su molte installazioni WordPress che riceviamo in gestione, questa funzione non è abilitata, semplicemente perché nessuno ci ha mai messo mano. Per le agenzie che portano siti in produzione e devono garantire performance solide ai propri clienti, è un’ottimizzazione che vale la pena capire, attivare e saper comunicare.
Noi di Blurr usiamo Cloudflare come parte dello stack standard su tutti i progetti WordPress che sviluppiamo. HTTP/3 è attivo di default sulle nostre configurazioni da diverso tempo, e la differenza rispetto a HTTP/2 si vede in modo più netto di quanto ci aspettassimo inizialmente.
Cos’è HTTP/3 e perché il protocollo QUIC cambia le cose
HTTP/3 non è semplicemente “la versione nuova di HTTP/2”. Il cambiamento sostanziale è sotto: invece di usare TCP come protocollo di trasporto, HTTP/3 usa QUIC, un protocollo sviluppato da Google costruito su UDP.
Perché importa? TCP ha un problema noto chiamato “head-of-line blocking”: se un pacchetto dati si perde durante la trasmissione, tutti gli altri pacchetti in coda aspettano che il pacchetto perso venga ritrasmesso, anche se appartengono a risorse completamente diverse. QUIC elimina questo problema: ogni flusso di dati è indipendente, e la perdita di un pacchetto blocca solo quel flusso, non gli altri.
Su connessioni stabili in fibra, la differenza è limitata. Su connessioni mobile con segnale variabile, in ambienti con pacchetti persi frequenti (reti affollate, 4G in movimento), l’impatto diventa molto visibile. Ed è esattamente in questo contesto che vengono misurati i Core Web Vitals di Google.
L’impatto sui Core Web Vitals: dove si vede la differenza
I Core Web Vitals si misurano su connessioni reali degli utenti reali, non in laboratorio. Questo è un dettaglio che cambia completamente il ragionamento su HTTP/3.
Il metrico più influenzato da HTTP/3 è LCP (Largest Contentful Paint): il tempo che impiega l’elemento principale della pagina a diventare visibile. Con HTTP/3 attivo, le risorse critiche, soprattutto immagini e font, viaggiano più velocemente su connessioni instabili perché non aspettano pacchetti persi su altri flussi. Il guadagno che abbiamo osservato sui siti che gestiamo in manutenzione è nell’ordine di 200-400 millisecondi su LCP misurato da Google Search Console, su dati reali di campo. Non è una rivoluzione, ma in un contesto dove si lavora per portare LCP sotto i 2,5 secondi, quei millisecondi pesano.
FID e INP, i metrici che misurano la reattività all’interazione, beneficiano in modo più indiretto: una connessione più fluida significa che JavaScript e CSS arrivano prima, e il browser può renderizzare la pagina prima che l’utente interagisca.
Cloudflare WordPress: come HTTP/3 si inserisce nello stack
Cloudflare non è solo un CDN. È il layer che si occupa di terminare le connessioni HTTP dal browser dell’utente, servire risorse dalla cache edge, e poi comunicare con il server d’origine. Questo significa che HTTP/3 si attiva tra il browser dell’utente e i data center Cloudflare, non necessariamente tra Cloudflare e il server WordPress. Il server d’origine può continuare a usare HTTP/2 o HTTP/1.1 senza problemi.
Questo punto è importante per le agenzie: non serve intervenire sull’hosting o sul server per beneficiare di HTTP/3. Basta attivarlo nel pannello Cloudflare. Il server d’origine rimane invariato.
Sul fronte del caching, HTTP/3 lavora in sinergia con i plugin di caching come SuperPageCache, che genera pagine statiche servite poi dalla rete Cloudflare. Una pagina già cachata viene servita ancora più velocemente con HTTP/3 perché l’handshake di connessione iniziale è più rapido: QUIC ha un meccanismo chiamato “0-RTT” che permette, per connessioni ripetute dallo stesso utente, di eliminare completamente il round trip iniziale di handshake.
Cosa verificare prima e dopo l’attivazione
Prima di attivare HTTP/3, è utile che l’agenzia abbia un punto di riferimento. Misurare LCP attuale su PageSpeed Insights con almeno tre rilevazioni su diverse condizioni di rete, salvare i dati di Google Search Console sui Core Web Vitals del campo, e tenere traccia delle versioni nei log di accesso del server sono operazioni che trasformano un’attivazione in un dato misurabile da mostrare al cliente.
Un aspetto che non tutti considerano: HTTP/3 richiede che la porta UDP 443 sia aperta tra client e server Cloudflare. Alcuni firewall aziendali o reti Wi-Fi corporate bloccano il traffico UDP, il che significa che in questi ambienti il browser tornerà automaticamente a HTTP/2. Non è un problema, è un fallback gestito in modo trasparente, ma va saputo per rispondere correttamente se un cliente segnala che “su certi computer la velocità non cambia”.
Qualche mese fa un’agenzia di Milano che seguiamo ci ha segnalato questo scenario esatto: il responsabile IT del cliente finale lavorava su una rete aziendale che bloccava UDP, e vedeva tempi di caricamento identici prima e dopo la migrazione. Non era un problema di configurazione, era un firewall di rete. Una spiegazione tecnica chiara al cliente ha risolto la situazione senza dover rimettere mano al sito.
Perché è rilevante per chi fa produzione siti in outsourcing
Se come agenzia affidate la produzione tecnica a un partner esterno, vale la pena verificare che le configurazioni Cloudflare siano ottimizzate e che HTTP/3 sia attivo prima della consegna. Non è una verifica complessa, ma è il tipo di dettaglio che separa una consegna professionale da una standard.
Noi di Blurr, studio WordPress white label con sede a Calliano (Trento), includiamo la configurazione Cloudflare ottimizzata, con HTTP/3 attivo, come parte del workflow standard su ogni progetto che sviluppiamo per le agenzie partner. Le agenzie che ci affidano la produzione trovano i siti già configurati correttamente su questo livello, senza dover intervenire dopo la consegna.
Se stai cercando un partner tecnico per la produzione WordPress con configurazioni Cloudflare già ottimizzate, puoi contattarci su blurr.it/contatti/ per una valutazione del tuo workflow attuale.
FAQ
No, va abilitato manualmente dal pannello Cloudflare nella sezione Velocità > Ottimizzazione > Protocolli. Su piani gratuiti e Pro è disponibile senza costi aggiuntivi. Il browser dell’utente deve supportare HTTP/3 per usarlo, ma i browser moderni, Chrome, Firefox, Edge e Safari aggiornati, lo supportano tutti. Il fallback automatico a HTTP/2 garantisce compatibilità totale.
Il browser negozia il protocollo alla connessione: se sia il server Cloudflare che il browser supportano HTTP/3, usano quello. Altrimenti scendono a HTTP/2 o HTTP/1.1 in modo trasparente. Non è una scelta binaria, è una negoziazione automatica. Attivare HTTP/3 non disabilita HTTP/2.
Anche su desktop il protocollo QUIC migliora la gestione della congestione di rete e riduce la latenza su connessioni con perdita di pacchetti. Il guadagno è meno marcato rispetto a mobile, ma presente. Per siti con traffico misto desktop/mobile, i benefici netti rimangono positivi.
Sì, non ci sono incompatibilità specifiche con WordPress Multisite. HTTP/3 opera a livello di protocollo di rete, prima ancora che il server processi la richiesta PHP. L’unica verifica necessaria è che tutte le zone Cloudflare associate al multisite abbiano HTTP/3 abilitato, specialmente se si usano domini diversi per i sottodomini.