HTTP/2, un salto evolutivo nel web (anche per i siti e per Google)
È stato definito un significativo passo in avanti nel complesso sistema del Web, in grado di una offrire una serie di opportunità completamente nuove per ottimizzare le applicazioni online e migliorare le prestazioni. Una presentazione certamente roboante per HTTP/2, la seconda versione del protocollo HTTP che – seppur forse più lentamente del previsto – sta emergendo anche nei discorsi legati alle ottimizzazioni tecniche dei siti. In effetti, Googlebot ha iniziato a supportarlo nelle sue scansioni a novembre 2020, mentre dal marzo 2021 è indicato per le network requests nei rapporti di Google Lighthouse e PageSpeed Insights. Ecco quindi una panoramica su HTTP2, per capire che cos’è, come funziona, perché dovrebbe interessarci e, in concreto, quali sono i pro e i contro del suo utilizzo e, non meno importante, quali possono essere i suoi aspetti positivi per la SEO.
Che cos’è HTTP2
HTTP/2 è l’acronimo di Hypertext Transfer Protocol version 2 e rappresenta la seconda versione del protocollo HTTP, realizzata con lo specifico obiettivo di migliorare la velocità e l’efficienza della trasmissione dei dati, rendendo le pagine web più veloci e reattive.
Più precisamente, è un’espressione ottimizzata della semantica dell’Hypertext Transfer Protocol (per tutti HTTP), il protocollo che serve il Web da oltre 20 anni, di cui rappresenta l’evoluzione, e quindi HTTP/2 è un protocollo per controllare la comunicazione tra un browser che effettua una richiesta e il server che contiene le informazioni richieste.
Oltre a garantire un passo avanti tecnico rispetto alla generazione precedente, mantenendo la massima compatibilità, il protocollo HTTP/2 migliora il caricamento delle pagine web sui vari browser e offre una grande semplicità applicativa agli utenti, che non devono apportare particolari modifiche al sito per applicare questa tecnologia.
In particolare, HTTP/2 consente un uso più efficiente delle risorse di rete e una percezione ridotta della latenza, introducendo la compressione del campo dell’header e consentendo più scambi simultanei sullo stesso collegamento; inoltre, introduce anche il push non richiesto di rappresentazioni dai server ai client.
La storia di HTTP/2: non solo un’evoluzione di HTTP
HTTP/2 è stato ufficialmente standardizzato nel 2015, quasi due decenni dopo l’introduzione del suo (ultimo) predecessore, HTTP/1.1 e circa 30 anni dopo le prime intuizioni, legate al periodo della nascita del Web.
L’Hyper Text Transfer Protocol è infatti il protocollo di applicazione che ha reso possibile il World Wide Web, e in questo lungo periodo è passato da un semplice mezzo di recupero delle risorse di rete a un sistema di comunicazione digitale veloce, sicuro e versatile.
La prima versione documentata di HTTP, HTTP 0.9, è stata rilasciata nel 1991 ed è il risultato della visione di Tim Berners-Lee, il pioniere del web, che lo ha progettato con l’obiettivo di semplificare la comunicazione di dati ad alto livello tra web server e client. Questa versione ha gettato le basi per l’evoluzione del protocollo, che ha visto l’introduzione di HTTP1.0 nel 1996 e di HTTP1.1 nel 1997: da allora, HTTP ha subito una serie di miglioramenti incrementali, mantenendo sempre al centro la sua missione originale: rendere la comunicazione di dati su Internet semplice ed efficiente.
La crescente complessità del web ha però reso necessario lo sviluppo di una nuova versione del protocollo, e in particolare l’aumento del numero e della dimensione delle risorse richieste per caricare una singola pagina web stava rendendo HTTP/1.1 sempre più inefficiente. HTTP/2 è stato quindi introdotto per affrontare queste inefficienze e migliorare la velocità e la sicurezza della navigazione web, consentendo un uso più efficiente delle risorse di rete, una ridotta percezione della latenza grazie alla compressione delle intestazioni e un numero di scambi simultanei sulla stessa connessione, a cui aggiunge anche l’introduzione di push del server.
Arriviamo così al febbraio 2015, quando l’HTTP Working Group della Internet Engineering Task Force (IETF) ha rilasciato HTTP/2, la seconda versione principale del protocollo, sviluppata in risposta al protocollo SPDY di Google, un progetto compatibile con HTTP che mirava a ridurre la latenza della navigazione web. Nel maggio 2015, la specifica di implementazione di HTTP/2 è stata ufficialmente standardizzata, segnando un nuovo capitolo nella storia di HTTP.
Il confronto tra HTTP/2 e SPDY non si è concluso con l’introduzione di HTTP/2, e la competizione tra i due protocolli ha stimolato un’ulteriore evoluzione di HTTP, spingendo verso l’adozione di funzionalità sempre più avanzate. Questo processo di continua innovazione è ciò che ha permesso a HTTP di rimanere al centro del World Wide Web, nonostante le sfide poste dalla crescente complessità del web.
Stando alle ultime rilevazioni di w3techs, ad oggi HTTP2 è utilizzato da più del 35 per cento di tutti i siti, un dato in calo rispetto al picco raggiunto a gennaio 2021 (quando lo stesso gruppo w3techs annunciò che HTTP/2 aveva superato quota 50 per cento di tutti i siti al mondo) anche per la successiva introduzione di HTTP/3, che infatti è già adottato dal 27 per cento dei siti.
HTTP/3 è stato introdotto per la prima volta come bozza di lavoro dall’Internet Engineering Task Force (IETF) nel novembre 2018 ed è stato effettivamente standardizzato come RFC 9114 il 6 giugno 2022. HTTP/3 mantiene tutte le funzionalità della precedente versione, aggiungendo l’adozione del protocollo QUIC al posto di TCP per il trasporto dei dati: QUIC, che sta per Quick UDP Internet Connections, è un protocollo di trasporto sviluppato da Google che combina le caratteristiche di TCP e UDP per fornire una connessione più veloce e affidabile, così da rendere HTTP/3 capace di offrire queste funzionalità con una maggiore efficienza e velocità.
A proposito di Google e HTTP/2, però, è importante notare che per ora Googlebot è capace di eseguire la scansione dei siti su HTTP/2 da novembre 2020 (e già a maggio 2021 John Mueller aveva confermato che eseguiva la scansione di oltre la metà di tutti gli URL con il protocollo HTTP/2), mentre non è ancora capace di fare crawling su HTTP/3.
Cos’è un protocollo e come funziona la comunicazione online
Per capire meglio il funzionamento di tale sistema è bene ricordare anche che cos’è un protocollo, servendoci dell’aiuto di Ruth Everett: essenzialmente, protocollo è l’insieme di regole in atto per gestire la richiesta tra client e server. Tipicamente si costituisce di tre parti principali: l’intestazione, payload e footer.
- L’intestazione o Header contiene informazioni come l’indirizzo di origine e di destinazione della pagina, nonché le dimensioni e i dettagli del tipo.
- Il Payload è l’informazione effettiva che verrà trasmessa.
- Il Footer, infine, indirizza la richiesta al destinatario previsto e garantisce che i dati siano privi di errori quando vengono trasmessi al browser.
Le caratteristiche di HTTP/2 e le funzionalità principali
HTTP/2 rende le applicazioni più veloci, più semplici e più robuste (“una combinazione rara”, afferma Ilya Grigorik di Google), consentendo di annullare molte delle soluzioni alternative HTTP/1.1 precedentemente adottate e di risolvere queste preoccupazioni all’interno del livello di trasporto stesso.
Sin dalla sua progettazione, questo protocollo aveva come obiettivi principali la riduzione della latenza, abilitando il multiplexing completo di richieste e risposte, la riduzione al minimo del sovraccarico del protocollo tramite una compressione efficiente dei campi di intestazione HTTP e l’aggiunta del supporto per la definizione delle priorità delle richieste e il push del server.
Tecnicamente, HTTP/2 si basa sulla stessa sintassi di HTTP/1, e quindi questo protocollo è più un aggiornamento che una migrazione completa; questa è stata una decisione intenzionale, per rendere la transizione il più agevole possibile.
Queste sono alcune delle caratteristiche tecniche principali di questo protocollo:
- Comandi binari
HTTP/2 introduce una modifica al protocollo di trasformazione, che passa da testuale a binario per completare la richiesta ai cicli di risposta: vengono eseguite le stesse attività, ma utilizzando solo comandi binari 1 e 0 anziché testo.
In questo modo, si semplificano le implementazioni dei comandi, che diventano più facili da generare e analizzare.
- Multiplex
Il multiplexing consente di effettuare più richieste contemporaneamente su una singola connessione: in questo modo, il payload è suddiviso in sequenze più piccole, analizzate e trasmesse su una singola connessione e poi riassemblate prima che raggiungano il browser.
L’obiettivo principale di questa modifica era risolvere i problemi relativi alle richieste che consumano risorse e aiutare a evitare che richieste e risposte blocchino le altre.
- Compressione dell’header
La compressione dell’intestazione è progettata per ridurre il sovraccarico fornito con il meccanismo di avvio lento in HTTP/1. Essendo la maggior parte dei siti Web ricca di grafica e contenuti, le richieste dei client causano l’invio di più frame di intestazione quasi identici al browser, il che può causare latenza e consumo non necessario di risorse di rete già limitate.
Il meccanismo di compressione dell’header offre la possibilità di comprimere un numero elevato di frame di intestazione ridondanti e consente al server di mantenere un elenco di header utilizzati nelle richieste precedenti; essenzialmente, le intestazioni verranno codificate in un blocco compresso e inviate insieme al client.
- Server Push
Il meccanismo server push consente di inserire le risorse che potrebbero essere utilizzate nella cache di un browser prima che vengano richieste; sono inviate, senza attendere la risposta di un altro client, anche le informazioni o le risorse che si prevede saranno presenti in richieste future (basate su richieste precedenti).
In questo modo, si evita la necessità di un altro round trip di richiesta e risposta e si riduce la latenza di rete che deriva da diverse risorse utilizzate per caricare una pagina.
- Priorità nel flusso
La Stream prioritization – assegnazione della priorità nel flusso – consente di dare la preferenza a particolari flussi di dati, in base alle dipendenze e al peso assegnati a ciascuno.
In tal modo, il server può ottimizzare l’allocazione delle risorse in base ai requisiti dell’utente finale.
- HTTP2 e HTTPS
Il supporto per HTTP/2 è disponibile solo tramite connessioni crittografate, e quindi richiede HTTPS. HTTP/2 richiede quindi sempre una connessione sicura, e ciò significa che tutti i siti che utilizzano HTTP/2 devono anche utilizzare HTTPS, migliorando la sicurezza generale del web.
Non sorprende che i due protocolli si completino a vicenda in molti modi: aumentano la sicurezza per utenti e applicazioni, ma richiedono anche un minor numero di handshake TLS e riducono il consumo di risorse sia lato client che lato server.
Come funzionano le richieste HTTP: l’analogia del camion
L’articolo di Everett riporta anche un’utile analogia per comprendere le richieste HTTP, usando un camion come riferimento.
Fondamentalmente, un camion rappresenta la richiesta dal client al server e la strada percorsa dal camion è la connessione di rete; quando il camion che trasporta la richiesta dal browser raggiunge il server, caricherà la risposta e la riporterà al browser.
Il protocollo HTTPS aggiunge un livello di protezione a queste risposte, per garantire che nessuno sia in grado di guardare all’interno del camion per vedere cosa contiene, ad esempio dati personali o informazioni sensibili.
Il problema principale è che i camion che fanno la richiesta non possono viaggiare più velocemente della velocità della luce: devono anche viaggiare a una velocità costante, indipendentemente da quanto sia grande la richiesta e quanto lontano devono percorrere per raggiungerla.
Inoltre, bisogna considerare anche che la maggior parte dei siti Web richiede una sequenza di molte richieste e risposte per caricare una pagina: ad esempio, anche i file di immagine, CSS e/o JavaScript possono avere le proprie dipendenze, che richiedono l’esecuzione di più viaggi tra il browser e il server.
Quando si effettuano richieste tramite HTTP/1, ogni camion necessita della propria strada o richiesta di rete, e per determinate richieste devono essere effettuate anche nuove richieste di rete; tutto questo si aggiunge alla latenza.
In genere, è possibile effettuare solo sei connessioni simultanee alla volta, e le altre richieste sono costrette ad attendere che le connessioni di rete siano libere. I diagrammi a cascata sono un modo utile per vedere questa latenza in azione.
Come cambiano le cose con HTTP/2
È in questo punto che può intervenire HTTP/2 e fornire un impatto positivo sui comportamenti delle richieste.
Ad esempio, grazie alla funzione multiplex più camion possono circolare su una singola strada contemporaneamente, quindi la connessione di rete è in grado di gestire più richieste e fornire più risposte più velocemente.
Il contenuto di queste richieste e risposte rimane lo stesso: sono solo gestite in un modo leggermente diverso.
Un’altra utile funzionalità di HTTP/2 è Server Push, che consente al server di rispondere a una richiesta con più risposte contemporaneamente. Quindi, se per esempio dobbiamo restituire i file CSS e JavaScript insieme all’HTML, questi possono essere inviati tutti contemporaneamente, invece di dover essere consegnati singolarmente al browser.
Le differenze tra HTTP/2 e HTTP
L’analogia ci permette anche di mettere in luce le principali differenze tra HTTP e HTTP/2, perché il nuovo protocollo non solo migliora l’efficienza del precedente, ma introduce anche una serie di funzionalità differenti.
Di base, HTTP/2 non modifica in alcun modo la semantica dell’applicazione HTTP: tutti i concetti fondamentali, come i metodi, i codici di stato, gli URI e i campi di intestazione rimangono in vigore. Invece, HTTP/2 modifica il modo in cui i dati vengono formattati e trasportati tra il client e il server, che gestiscono l’intero processo, e nasconde tutta la complessità alle applicazioni all’interno del nuovo livello di framing. Di conseguenza, tutte le applicazioni esistenti possono essere consegnate senza modifiche.
In breve, HTTP/2 scompone la comunicazione del protocollo HTTP in uno scambio di frame con codifica binaria, che vengono poi mappati su messaggi che appartengono a un flusso particolare, i quali vengono tutti multiplexati all’interno di una singola connessione TCP. Questa è la base che abilita tutte le altre funzionalità e ottimizzazioni delle prestazioni fornite dal protocollo HTTP/2.
Ritornando al confronto tra le versioni, una delle prime e più significative innovazioni sta nel fatto che HTTP/2 è un protocollo binario, a differenza di HTTP/1.1 che è un protocollo testuale capace di gestire una sola richiesta per connessione TCP: come chiarito, ciò permette a HTTP/2 di gestire le richieste e le risposte come flussi di bit, che sono più efficienti da analizzare e meno soggetti a errori rispetto ai testi, e di elaborare più richieste contemporaneamente, riducendo i tempi di caricamento delle pagine.
Nello specifico, in HTTP/1.1 ogni richiesta di risorsa (come un’immagine, un foglio di stile CSS o uno script JavaScript) richiede una connessione separata tra il browser e il server: questo può portare a un fenomeno noto come “blocco della testa di linea”, in cui la necessità di gestire molteplici connessioni contemporaneamente può rallentare l’intera connessione e provocare una congestione della rete. HTTP/2 risolve questo problema introducendo il multiplexing, che permette di gestire più richieste contemporaneamente su una singola connessione.
Un’altra importante differenza tra HTTP/1.1 e HTTP/2 è l’introduzione del server push. Nel protocollo precedente, il server può inviare risorse al browser solo in risposta a una richiesta specifica: pertanto, se una pagina web richiede molte risorse, il browser deve fare molte richieste separate, ognuna delle quali richiede tempo e può portare a una duplicazione dei dati sui cavi di trasmissione, richiedendo l’uso di protocolli aggiuntivi per garantire che le informazioni ricevute siano prive di errori. HTTP/2 introduce il concetto di server push, che permette al server di inviare attivamente risorse al browser prima che quest’ultimo le richieda, e ciò può ridurre ulteriormente i tempi di caricamento delle pagine, poiché il browser può iniziare a elaborare le risorse non appena le riceve, invece di dover aspettare di richiederle.
Infine, come detto, tutti i siti che utilizzano HTTP/2 devono anche utilizzare HTTPS, migliorando la sicurezza generale del web.
I vantaggi del protocollo HTTP2 per i siti
Essendo una tecnologia aggiornata, l’adozione di HTTP/2 porta alcuni vantaggi per i siti.
Il primo è di tipo tecnico e pratico: l’aggiornamento a HTTP2 non è una migrazione e non richiede modifiche agli URL, ma è più semplicemente un cambio di protocollo che non necessita di sforzi applicativi o interventi particolari.
Everett ha messo in evidenza “quattro dei maggiori vantaggi dal punto di vista SEO”, un elenco non esaustivo dei vantaggi complessivi di HTTP/2.
- Prestazioni web
Molte delle nuove funzionalità di HTTP/2 sono state progettate per migliorare le prestazioni dei siti e per aiutare a risparmiare le risorse necessarie per eseguire la scansione dei siti.
Ad esempio, il multiplexing significa che le richieste e le risposte non si bloccheranno a vicenda, fattore che aiuta a ridurre la latenza e, a sua volta, fornisce prestazioni web più veloci.
La possibilità di inviare e ricevere più dati per richiesta di comunicazione è un altro esempio pratico di vantaggi prestazionali.
Inoltre, la prioritizzazione del flusso consente un utilizzo efficace delle risorse, che riduce il tempo necessario per fornire le richieste di contenuto all’utente.
- Prestazioni mobili
Oltre alle prestazioni web complessive, anche le prestazioni mobile possono essere migliorate grazie a HTTP/2, che è progettato nel contesto delle odierne tendenze di utilizzo, che prediligono sicuramente i dispositivi mobili.
Il multiplexing e la compressione dell’header aiutano in particolare a ridurre la latenza nell’accesso alle pagine Web, e questo si verifica anche su reti mobili, che possono avere una larghezza di banda limitata.
In sostanza, HTTP/2 ottimizza l’esperienza web per gli utenti mobile in modi che in precedenza erano attribuiti solo agli utenti desktop, anche attraverso prestazioni e sicurezza.
- User Experience migliorata
I miglioramenti delle prestazioni influenzano positivamente anche l’user experience: è facile intuire che un sito a caricamento rapido porti a una maggiore soddisfazione del cliente e al favore generale del brand.
Come dice Google, c’è un aumento del 32% del bounce rate se il caricamento di una pagina va da 1 secondo a 3 secondi, e HTTP/2 è solo un modo in cui possiamo cercare di migliorare la velocità di caricamento.
- Maggiore sicurezza
Poiché HTTP/2 deve essere servito su HTTPS, garantisce che tutti i siti Web siano crittografati e protetti.
Inoltre, aiuta anche ad assicurare che le applicazioni stesse siano protette da eventuali attacchi dannosi, che potrebbero comportare sanzioni manuali per il sito o potenzialmente farlo rimuovere del tutto dai risultati di ricerca.
I possibili svantaggi
Accanto a questi “pro”, anche HTTP/2 porta alcuni svantaggi da considerare, come avviene con tutte le tecnologie.
Il primo aspetto negativo segnalato dall’articolo è che non tutti i browser supportano ancora HTTP/2. In realtà, già dal 2015 la maggior parte dei principali browser ha aggiunto il supporto per il nuovo protocollo, ma è bene assicurarsi che i browser principali da cui gli utenti accedono al sito siano supportati.
Questo è comunque un problema limitato, in quanto l’incompatibilità riguarda soprattutto versioni obsolete dei browser, che hanno un utilizzo globale basso, come rivela il grafico del sito Caniuse.com.
A causa della funzione push del server, c’è un potenziale spreco di larghezza di banda a causa dei dati che possono essere inviati al browser, ma non effettivamente utilizzati: “Solo perché una richiesta di caricamento di una pagina potrebbe richiedere una particolare risorsa o potrebbe essere prevista un’altra richiesta, non sempre significa che lo farà”, dice Everett, e ciò rischia di determinare che “risorse non necessarie possano essere inviate al browser”.
Inoltre, poiché il multiplexing può fare in modo che il server “riceva brevi raffiche di un numero di richieste contemporaneamente, questo ha il potenziale di sopraffare i server, in particolare se non sono limitati”. Potrebbero infine verificarsi lievi ritardi e complicazioni nel debug, a causa del formato binario utilizzato al posto del formato di testo utilizzato in HTTP/1.
Come implementare HTTP2 sul sito
Implementare HTTP/2 su un sito web è un processo che richiede una serie di passaggi chiave e una certa familiarità con i server web. Iniziamo con la verifica del supporto del server web per HTTP/2: i principali servizi come Apache, Nginx e Microsoft’s IIS supportano HTTP/2, ma potrebbe essere necessario aggiornarli alla versione più recente.
Una volta verificato il supporto del server, il passo successivo è abilitare HTTPS sul sito web, necessario per implementare effettivamente HTTP/2.
La procedura esatta per passare a HTTP/2 varia a seconda del server web che stiamo utilizzando, ma generalmente coinvolge la modifica del file di configurazione del server per abilitare HTTP/2 e poi riavviare il server.
Infine, una volta abilitato HTTP/2, è importante verificare che tutto funzioni come previsto, sfruttando uno dei vari strumenti online pensati per verificare se il sito web sta effettivamente utilizzando HTTP/2.
L’aggiornamento a HTTP/2 dipende in ultima analisi dal nostro server e dal provider di hosting: se, al momento, non siamo in grado di supportare HTTP/2, è necessario parlare con l’amministratore del server o con l’assistenza dell’hosting per ricevere le opportune indicazioni.
Se al contrario il server è in grado di supportare HTTP/2, potrebbe servire automaticamente il contenuto tramite il nuovo protocollo. Possiamo assicurarci “che il server sia in grado di supportarlo utilizzando un CDN che supporti anche HTTP/2 e disponendo di un certificato HTTPS aggiornato”; inoltre, possiamo verificare se il server è in grado di supportare HTTP/2 utilizzando il sito http2.pro, che informa sulle funzionalità del server rispetto al supporto di HTTP/2, ALPN e Server-push. Un altro tool utile è Chrome Dev Tools, che consente di controllare quali risorse sono attualmente servite su HTTP/2.
Google e HTTP2
Come anticipato, da metà novembre 2020 Google ha avviato la scansione dei siti su HTTP/2 e dopo circa sei mesi stava già eseguendo la scansione di oltre la metà di tutti gli URL con il nuovo protocollo. Tuttavia, Googlebot non supporta tutte le funzionalità introdotte dalla versione HTTP2 e, in particolare, alcune funzionalità come il push del server, che possono essere utili per il rendering, sono ancora in fase di valutazione.
Inoltre, da marzo 2021 anche lo strumento PageSpeed Insights utilizza HTTP/2 per effettuare richieste di rete, se il server lo supporta; se un sito è su HTTP/2, di conseguenza potrebbe vedere aumentare i suoi punteggi di PageSpeed Insights – ma ciò non significa un aumento di ranking, sia chiaro.
In precedenza, tutte le richieste venivano effettuate con HTTP/1.1 a causa di vincoli nell’infrastruttura di connettività; con questo miglioramento, è più probabile che ci sia “maggiore somiglianza tra i risultati di Lighthouse da PSI e da Lighthouse CLI e DevTools (che hanno sempre effettuato richieste con h2)”, anche se “la coerenza tra ambienti è quasi impossibile”, spiegano da Google.
Vale la pena notare che non è possibile “forzare” Googlebot a eseguire la scansione del nostro sito su HTTP/2: se il sito lo supporta, sarà automaticamente idoneo per essere sottoposto a scansione con il protocollo, ma per il momento Google lo farà solo se lo riterrà vantaggioso in termini di risparmio di risorse. Pertanto, se il sito supporta HTTP2, significa che è idoneo per la scansione su HTTP2, ma solo se ciò comporta un beneficio per il sito e per Googlebot, che altrimenti continuerà semplicemente a eseguire la scansione del sito tramite HTTP/1.1.
Al contrario, abbiamo un metodo per disattivare la scansione con protocollo HTTP/2: indicare al server di rispondere con un codice di stato HTTP 421 quando Googlebot tenta di eseguire la scansione del sito su HTTP2, oppure (in caso di problemi o impossibilità tecnica) inviare un messaggio al team di Googlebot per una soluzione temporanea.
In linea di massima, comunque, i test preliminari di Google non hanno riscontrato problemi o un impatto negativo sulla indicizzazione causati da scansione su HTTP/2.
HTTP2 e vantaggi per la SEO
Tutti gli aspetti positivi di questo protocollo, combinati insieme, possono avere anche un impatto positivo sulla SEO.
Ribadiamo che non c’è un aumento diretto del ranking derivante dall’uso di HTTP2, come confermato più volte da Google, ma ad ogni modo gli incrementi di performance e UX possono comunque contribuire a raggiungere gli obiettivi fissati dal complesso di segnali che formano la Page Experience, oltre che influire, in qualche modo, sulla visibilità di un sito in Google Search e sulle conversioni.
C’è poi un altro aspetto interessante, rivelato da John Mueller in un intervento a Google I/O 2021 e riportato da Seroundtable, perché la scansione in HTTP2 potrebbe migliorare il crawl budget, ovvero “un mix tra quanti URL Google vuole scansionare dal tuo sito web – la richiesta di scansione (crawl demand) e quanti tuoi URL i nostri sistemi pensano che il tuo server possa gestire senza problemi – la capacità di scansione (crawl capacity)”.
Con la scansione HTTP/2, spiega Mueller, questo diventa un po’ più complicato “perché una singola connessione può includere più URL”; nel complesso, comunque, Google pensa “che la scansione HTTP/2 offre ai nostri sistemi la possibilità di richiedere più URL con un simile carico sui tuoi server”.
Ad ogni modo, la decisione di eseguire la scansione con HTTP/2 “si basa sul fatto che il server lo supporti e che i nostri sistemi determinino un possibile aumento dell’efficienza”; ciò significa che Googlebot “non avrà bisogno di dedicare tanto tempo alla scansione del tuo server come prima”, e che in generale il nuovo protocollo, con le sue caratteristiche, apporta miglioramenti che aiutano sia la scansione di Google che l’infrastruttura di servizio del sito web.
In linea teorica, ha chiarito anche la successiva guida ufficiale di Google, l’adozione di HTTP2 per Googlebot dovrebbe rendere la scansione più efficiente in termini di utilizzo delle risorse del server: con HTTP2, Googlebot può aprire una singola connessione TCP con il server e trasferire in modo efficiente più file su questo protocollo in parallelo, invece di richiedere più connessioni. Minore è il numero di connessioni aperte, minore è il numero di risorse che il server e Googlebot devono impiegare per la scansione.
Semplificando, ciò significa un risparmio di risorse, sia sul lato server che per Googlebot. Tuttavia, p lo stesso documento che rivela più avanti che l’utilizzo di HTTP1 o HTTP2 per la scansione “non influisce sulle modalità di indicizzazione di un sito e, di conseguenza, non influisce sulla frequenza di scansione di un sito da parte di Google”.
