Cos'è HTTP/2?

HTTP/2 è la seconda versione principale del protocollo Hypertext Transfer Protocol, formalizzata come RFC 7540 nel maggio 2015. È stato il primo aggiornamento importante di HTTP dalla standardizzazione di HTTP/1.1 nel 1997, e ha affrontato problemi fondamentali di prestazioni che hanno afflitto il web per quasi due decenni. Se il tuo sito WordPress serve ancora contenuti tramite HTTP/1.1, probabilmente stai perdendo guadagni significativi in termini di prestazioni.

Il protocollo è nato dal protocollo sperimentale SPDY di Google, in uso dal 2012, che ha dimostrato che le idee centrali dietro HTTP/2 (multiplexing, compressione degli header, prioritizzazione) funzionavano bene in pratica. Quando l'IETF ha standardizzato HTTP/2, SPDY è stato dismesso e le sue idee sono diventate la base del nuovo standard.

Principali miglioramenti rispetto a HTTP/1.1

Per capire perché HTTP/2 è importante, devi prima sapere cosa c'era di sbagliato in HTTP/1.1. Sotto il vecchio protocollo, ogni connessione TCP poteva gestire solo una richiesta alla volta. Se il tuo browser doveva caricare 40 risorse (una pagina WordPress tipica), doveva aprire più connessioni (i browser tipicamente consentono 6 per dominio) e mettere in coda le richieste rimanenti. Questo creava colli di bottiglia artificiali che rallentavano ogni caricamento di pagina.

HTTP/2 risolve questo e altro:

Multiplexing: è il miglioramento più importante. HTTP/2 consente che più richieste e risposte siano in transito contemporaneamente su una singola connessione TCP. Il tuo browser può richiedere contemporaneamente il tuo file CSS, tre file JavaScript e dieci immagini, tutti su una connessione. Niente più attese, niente più code, nessun limite artificiale. Il server invia indietro le risposte non appena sono disponibili, e il browser le assembla. Questa singola modifica può ridurre drasticamente i tempi di caricamento per siti WordPress ricchi di risorse.

Compressione degli header (HPACK): gli header HTTP vengono inviati a ogni richiesta e risposta. In HTTP/1.1 questi header sono testo semplice e spesso ripetitivi. Gli stessi cookie, user-agent string e header accept vengono inviati di nuovo e di nuovo. HTTP/2 usa l'algoritmo di compressione HPACK, che mantiene una tabella condivisa di campi header comuni tra client e server. Dopo la prima richiesta, gli header successivi devono inviare solo le differenze. Per un sito WordPress che carica più di 50 risorse per pagina, può risparmiare decine di kilobyte per caricamento di pagina.

Binary framing: HTTP/1.1 è un protocollo basato su testo, il che significa che il parser deve cercare interruzioni di riga, gestire diverse codifiche di testo e occuparsi di vari casi limite. HTTP/2 usa un livello di binary framing che impacchetta tutta la comunicazione in frame ben definiti. I dati binari sono più veloci da analizzare, meno soggetti a errori e più compatti. Non lo noti come utente, ma riduce l'overhead di elaborazione sia su server che client.

Prioritizzazione degli stream: HTTP/2 consente al browser di dire al server quali risorse sono più importanti. Ad esempio, il browser può indicare che il file CSS principale dovrebbe essere consegnato prima delle immagini di sfondo. Il server può quindi allocare la larghezza di banda di conseguenza. In pratica, le implementazioni di prioritizzazione dei browser variano, e non tutti i server la gestiscono perfettamente, ma per molti siti offre comunque miglioramenti significativi.

Server Push: questa funzionalità consente al server di inviare risorse al browser prima ancora che le richieda. Quando il browser richiede una pagina HTML, il server può inviare in anticipo i file CSS e JavaScript di cui sa che il browser avrà bisogno dopo. Questo elimina il ritardo del round-trip con cui il browser deve prima scoprire di aver bisogno di una risorsa e poi richiederla. In pratica, Server Push ha avuto un'adozione limitata. È difficile da implementare correttamente (inviare risorse che il browser ha già in cache spreca larghezza di banda), e alcuni CDN ne hanno dismesso il supporto. Chrome ha rimosso Server Push nella versione 106 (2022). Il concetto sopravvive nel meccanismo 103 Early Hints, che è più semplice e pratico.

Perché il domain sharding non è più necessario

Nell'era HTTP/1.1, gli sviluppatori web usavano un trucco chiamato domain sharding per aggirare il limite di sei connessioni per dominio. Servivano immagini da img1.example.com, CSS da cdn.example.com e font da un altro sottodominio. Così moltiplicavano il numero di connessioni parallele che il browser poteva aprire.

Con HTTP/2 il domain sharding non solo è inutile, ma controproducente. Poiché HTTP/2 multiplexa tutte le richieste su una singola connessione, dividere le risorse su più domini costringe il browser a impostare connessioni TCP e handshake TLS aggiuntivi. Ogni nuova connessione aggiunge latenza. Un sito WordPress ottimizzato per HTTP/1.1 con domain sharding dovrebbe consolidare le sue risorse su meno domini quando passa a HTTP/2.

Allo stesso modo, concatenare file CSS e JavaScript in un unico bundle (un'altra comune ottimizzazione HTTP/1.1) diventa meno importante con HTTP/2. L'invio di molti file più piccoli funziona in modo efficiente grazie al multiplexing, e ha il vantaggio aggiuntivo che il caching funziona meglio: se un file piccolo cambia, solo quel file deve essere riscaricato, non l'intero bundle concatenato.

HTTP/2 richiede in pratica HTTPS

La specifica HTTP/2 tecnicamente non richiede la cifratura. Può funzionare su TCP semplice (h2c, per HTTP/2 cleartext). Tuttavia, tutti i principali browser (Chrome, Firefox, Safari, Edge) hanno deciso di implementare HTTP/2 solo su TLS (h2). Questo significa che in tutti i casi pratici, hai bisogno di un certificato SSL/TLS per usare HTTP/2.

Questa non è più davvero una limitazione. I certificati gratuiti di Let's Encrypt hanno reso HTTPS accessibile a tutti, e la maggior parte dei provider di hosting WordPress include certificati SSL nei loro pacchetti. Se il tuo sito WordPress è ancora su HTTP semplice, passare a HTTPS è un prerequisito per HTTP/2, e porta con sé i propri vantaggi di sicurezza.

HTTP/3 e QUIC: il prossimo passo

HTTP/3 (RFC 9114, formalizzato nel giugno 2022) è la prossima evoluzione. Mentre HTTP/2 gira su TCP, HTTP/3 sostituisce completamente TCP con un nuovo protocollo di trasporto chiamato QUIC. QUIC è costruito su UDP e integra direttamente la cifratura TLS 1.3 nel livello di trasporto. I principali vantaggi di HTTP/3 rispetto a HTTP/2 sono:

• Impostazione più rapida della connessione: QUIC combina l'handshake TCP e l'handshake TLS in un round-trip, abbreviando l'impostazione della connessione. Per i visitatori di ritorno, può essere raggiunta anche la ripresa zero-round-trip.
• Niente head-of-line blocking: in HTTP/2 su TCP, in caso di perdita di un pacchetto, tutti gli stream su quella connessione si bloccano fino al ritrasmissione del pacchetto. QUIC gestisce la perdita di pacchetti per stream, quindi un pacchetto perso rallenta solo lo stream colpito, non tutto.
• Migliori prestazioni mobili: QUIC gestisce i cambiamenti di rete (come il passaggio da wifi a internet mobile) in modo più fluido, perché le connessioni sono identificate da un ID di connessione invece che da indirizzo IP e porta.

I principali provider CDN come Cloudflare e Fastly supportano già HTTP/3. La maggior parte dei provider di hosting è ancora in fase di adozione. Per i proprietari di siti WordPress, il supporto HTTP/3 è in gran parte una questione lato server; non devi modificare nulla in WordPress stesso.

Come controllare se il tuo host supporta HTTP/2

Ci sono diversi modi per verificare se il tuo sito WordPress è servito tramite HTTP/2:

• DevTools del browser: in Chrome DevTools apri la scheda Network, clicca con il tasto destro sulle intestazioni delle colonne e abilita la colonna "Protocollo". Dovresti vedere h2 per le richieste HTTP/2.
• Strumenti online: siti come il test HTTP/2 di KeyCDN o il controllore HTTP/2 su tools.keycdn.com possono verificare il supporto HTTP/2 per qualsiasi URL.
• Riga di comando: esegui curl -I --http2 -s https://tuosito.com e cerca HTTP/2 200 nella risposta.
• InspectWP: il report indica la versione HTTP rilevata del tuo sito WordPress.

Se il tuo host non supporta HTTP/2, un CDN come Cloudflare può essere posto davanti al tuo sito per fornire HTTP/2 (e HTTP/3), anche se il tuo server di origine parla solo HTTP/1.1. Il CDN gestisce la connessione HTTP/2 con il browser del visitatore e comunica con il tuo server di origine tramite il protocollo che supporta.

Implicazioni sulle prestazioni WordPress

Una pagina WordPress tipica carica tra 20 e 80 risorse separate: fogli di stile del tema e dei plugin, file JavaScript, webfont, immagini e talvolta risorse esterne da CDN e servizi di terze parti. Sotto HTTP/1.1, il caricamento di tutte queste risorse era la principale causa del tempo di caricamento, a causa dei limiti di connessione e coda.

Dopo il passaggio a HTTP/2, la maggior parte dei siti WordPress vede miglioramenti significativi in Time to First Contentful Paint e nel tempo complessivo di caricamento della pagina. Il miglioramento esatto dipende da quante risorse carica il tuo sito, ma riduzioni del 20-50% nel tempo di caricamento sono comuni per siti che erano precedentemente su HTTP/1.1. I siti con molte risorse piccole (tipici di WordPress con più plugin attivi) beneficiano di più.

Tieni presente che HTTP/2 non sostituisce altre ottimizzazioni delle prestazioni. Hai ancora bisogno di caching corretto, ottimizzazione delle immagini e codice efficiente. Ma HTTP/2 rimuove un importante collo di bottiglia infrastrutturale che non può essere risolto con alcuna ottimizzazione di plugin WordPress.

Cosa controlla InspectWP

InspectWP rileva la versione del protocollo HTTP usata dal tuo sito WordPress esaminando gli header di risposta. Se il tuo sito è servito tramite HTTP/1.1, il report lo segnala come problema di prestazioni e raccomanda di aggiornare a HTTP/2. Se viene rilevato HTTP/2 o HTTP/3, viene segnalato come positivo. La versione HTTP è mostrata nella sezione prestazioni del report, accanto ad altre statistiche a livello di server come compressione e header di risposta.