introduzione

Nel 1991 è stata introdotta la prima versione documentata del protocollo HTTP richiesta-risposta (HTTP 0.9). Da allora, il web si è drasticamente ampliato e, 24 anni dopo, nel 2015 è stata rilasciata la versione più recente dell'HyperText Transfer Protocol (HTTP/2), che introduce una moltitudine di possibili vantaggi per le prestazioni del sito se implementato correttamente.

Questo articolo è rivolto ai SEO che desiderano implementare HTTP/2 come parte delle loro iniziative di ottimizzazione della velocità della pagina.

HTTP/2 è un argomento estremamente ricco che potrebbe essere discusso in dettaglio. C'è una grande quantità di informazioni online che discutono di HTTP/2 e offre vantaggi più ampi per utenti finali e sviluppatori, ma prima di ritrovarti immerso nella ricchezza di informazioni su HTTP/2, assicurati di ottenere le informazioni di cui hai bisogno. Questo inizia ponendo le domande giuste:

1. In che modo questo influirà direttamente sull'ottimizzazione dei motori di ricerca e/o sulla velocità della pagina?
2. È possibile formulare una raccomandazione sulla base dell'intuizione?
3. La raccomandazione può essere realisticamente eseguita?

Queste domande ti aiutano a chiedere "ciò che sto facendo è efficace e prezioso?" e infine metterti in una posizione migliore per valutare come HTTP/2 può aiutare a migliorare un sito web.

A causa dell'ampia natura dell'argomento, c'è una grande quantità di conoscenze su HTTP/2 che non sono necessarie quando si cerca di capire l'importanza per la SEO. Il vantaggio principale di HTTP/2 per la SEO è la velocità della pagina.

Per aiutarti a navigare attraverso la ricchezza di informazioni online, ecco un'introduzione a HTTP/2, che descrive l'evoluzione da HTTP 1.1 a Spdy compatibile con HTTP di Google e infine a HTTP/2.

Comprendere come si è evoluto il web aiuterà a mettere in evidenza i miglioramenti che sono stati apportati ad esso come conseguenza dell'aggiunta del protocollo HTTP/2.

In che modo Google valuta la velocità della pagina?

Per vedere come Google valuta Page Speed ​​non guardare oltre i rapporti sull'esperienza utente di Chrome . Questi rapporti forniscono metriche sull'esperienza utente su come gli utenti stanno vivendo le destinazioni popolari sul Web. Questo è alimentato utilizzando le metriche chiave del coinvolgimento degli utenti (First Paint, First Contentful Paint, First Meaningful Paint, Time to Interactive) ed è ulteriormente supportato tramite strumenti comuni come Page Speed ​​Insights, Public Google Big Query Project, Lighthouse e Web Page Test. L'utilizzo di queste metriche e strumenti può aiutare a apportare possibili miglioramenti alla velocità della pagina.

Introduzione a HTTP/2

HTTP 1.1

Entro il 2015, HTTP 1.1 era diventato obsoleto. Erano finiti i giorni in cui le pagine/siti web venivano costruiti/facevano affidamento su HTML, CSS e JavaScript di base e su numerose risorse e framework diversi. L'era precedente al 2015 si basava sull'idea che si fosse limitati a una richiesta per connessione TCP. Ciò ha portato a situazioni in cui i client Web avevano più risorse in coda per il download, causando congestione della rete e tempi di caricamento delle pagine lenti.

HTTP/2 è stato progettato per mirare a tre aree principali di miglioramento per alleviare i problemi discussi sopra:

• Semplicità
• Alte prestazioni
• Robustezza

Vantaggi SEO per HTTP/2

La velocità della pagina è probabilmente il motivo principale per cui i SEO prenderebbero in considerazione l'implementazione di HTTP/2 sui propri siti Web o su quelli dei propri clienti. Page Speed/Performance è un insieme di parametri che sono stati un fattore di ranking dal 2010 per le query desktop. A causa dell'aumento dell'utilizzo dei dispositivi mobili, nel luglio 2018 Google ha annunciato ufficialmente che Page Speed ​​sarebbe diventato un fattore di ranking per i dispositivi mobili.

HTTP/2 fornisce 3 funzionalità principali che possono essere utilizzate durante l'ottimizzazione dei siti per Page Speed:

1. Multiplexing
2. Spinta del server
3. Priorità del flusso

Multiplexing

Il multiplexing consente a un client Web di includere più richieste all'interno di una singola connessione TCP, con conseguente minor carico del server e riduzione della congestione della rete.

I client Web moderni (Chrome, Firefox, Safari e Opera) che utilizzano i vecchi protocolli HTTP 1/1.1 hanno un limite predefinito sul numero di connessioni TCP simultanee per nome host. Pertanto, un client Web che utilizza HTTP 1/1.1 può facilmente incontrare difficoltà con la congestione del TCP. Con i client Web moderni, questo problema viene risolto utilizzando il multiplexing, che può apportare alcuni dei miglioramenti più significativi alla velocità della pagina.

Di seguito è illustrato il vantaggio del multiplexing utilizzando un confronto di HTTP/1.1 e HTTP/2, che mostra il comportamento tipico per quando il multiplexing HTTP/2 è e non è abilitato.

( WebpageTest, HTTP/1.1, nessun multiplexing dimostrato )

( WebpageTest, HTTP/2, Multiplexing dimostrato )

Nelle immagini sopra viene utilizzata una cascata basata sulle prestazioni per dimostrare il caricamento di risorse tra un utente (che richiede le risorse) e il server (che risponde a quali risorse) di una pagina Web. In genere, le risorse della pagina includono HTML, JavaScript, CSS e immagini. La cascata basata sulle prestazioni mostra il punto esatto in cui una risorsa specifica viene chiamata, scaricata e renderizzata all'interno del client, il che è fondamentale per scoprire, valutare e analizzare i problemi di velocità della pagina su un sito. Come dimostrato dall'immagine sopra "HTTP/2", tutte le risorse iniziano a scaricarsi contemporaneamente senza che le risorse inizino a caricarsi in un punto diverso. Poiché HTTP/2 utilizza il multiplexing e non si basa più sull'invio di una sola richiesta su una singola connessione TCP, è possibile scaricare più risorse contemporaneamente come sopra. Al contrario, come dimostrato dall'immagine "HTTP/1.1", le risorse non vengono scaricate contemporaneamente poiché non sono in grado di utilizzare la funzionalità di multiplexing. Il browser moderno medio in HTTP/1.1 è in grado di avere contemporaneamente 6 connessioni, ma il vantaggio dell'implementazione di HTTP/2 è che non è necessario un handshake TCP per ogni richiesta, mentre non importa quante connessioni possono essere eseguite contemporaneamente con HTTP/1.1 un primo il processo di connessione deve essere completato ogni volta. Pertanto stanno iniziando a scaricare in punti diversi, causando così un caricamento della pagina più lungo per l'utente.

( Diagramma Upwork HTTP/1.1 vs HTTP/2 )

I crawler di ricerca come Google e Bing non traggono vantaggio direttamente dall'implementazione di HTTP/2. Come descritto sopra, il principale vantaggio di queste ottimizzazioni potrebbe essere potenzialmente per Page Speed. Pertanto, sebbene l'implementazione di HTTP/2 non influisca direttamente sul crawler di ricerca, può influire sulla velocità della pagina, che è un fattore di ranking diretto per le query di Google per desktop dal 2010 e per le query per dispositivi mobili da luglio 2018. Di conseguenza, è fondamentale che i siti Web non vengano pubblicati un'esperienza lenta per gli utenti, poiché Google potrebbe sopprimere le prestazioni influendo sul ranking o, più recentemente, segnalando agli utenti che il tuo sito potrebbe essere lento.

Spinta del server

Server Push consente al server specifico o alla rete perimetrale di inviare risorse ai client Web quando non sono state richieste dal client. Per comprendere come funziona il push del server, è innanzitutto importante comprendere il modello di richiesta-risposta seguito da un sito Web. Un utente richiede una pagina da un sito Web e il server risponde con il contenuto/risorsa richiesto.

Ipoteticamente, pensa a un sito che ha tutti i suoi stili definiti in un foglio di stile esterno chiamato styles.css. Quando l'utente richiede lo scheletro HTML per la pagina (diciamo in questo caso index.html) il server push può "spingere" il CSS all'utente subito dopo aver iniziato a inviare la risposta a index.html.

( S mashing Magazine, Server Push )

Prima di capire come Server Push può aiutare a migliorare la velocità della pagina, è importante capire come funziona un browser con diverse risorse come immagini, CSS e JavaScript da visualizzare all'interno del tuo browser. Vedete, il browser invia istruzioni su come scaricare immagini, risorse CSS e JavaScript. Quando visiti per la prima volta un sito web, di solito fai una richiesta GET, che è il file .html. Una volta ricevuto questo file .html, il browser lo scansiona per capirlo e quindi può effettuare richieste GET aggiuntive a seconda di ciò che è contenuto nel file HTML.

In che modo Server Push aiuta a migliorare la velocità della pagina?

Attraverso l'utilizzo di Server Push si riduce il numero di richieste GET necessarie dal browser (round trip) e si evitano ritardi nel rendering che causano un aumento dei tempi di caricamento delle pagine. Questo può aiutare notevolmente a migliorare il tempo di rendering per il client web, che aiuta la pagina web ad apparire più veloce per gli utenti fornendo loro un'esperienza di gran lunga migliore.

Sebbene Server Push non influisca direttamente sul modo in cui Googlebot esegue la scansione del tuo sito, o in effetti su altri crawler, il vantaggio SEO si ottiene migliorando i fattori incentrati sull'utente come First Paint e First Meaningful Content.

Utilizzando Web Page Test, Lighthouse, Page Speed ​​Insights e il rapporto sull'esperienza utente di Chrome, puoi determinare il rendimento di un sito/pagina rispetto ai concorrenti negli stessi settori. Di seguito sono riportate due immagini che dimostrano l'implementazione senza (immagine 1) e con Server Push (immagine 2).

(Test pagina web, senza server push)

(Test pagina web, HTTP/1.1, con server push)

Con il server push, il server può essere configurato in modo che invii sempre eventuali componenti aggiuntivi della pagina (come file CSS, JavaScript e immagini) se gli viene chiesto di inviare il file .html che li contiene.

Nelle cascate sopra possiamo vedere che push.php utilizza quattro file CSS.

Senza server push, il browser deve ricevere il file push.php, analizzare l'HTML e quindi fare richieste specifiche per ogni file CSS aggiuntivo. Solo una volta ricevuti tutti i file CSS può iniziare a usarli nel processo di rendering.

Quando il server push è abilitato, la richiesta di push.php attiva automaticamente il server per inviare i quattro file CSS. Il browser li riceve e può iniziare a usarli nel processo di rendering molto prima. Ciò significa che il browser può iniziare a eseguire il rendering del contenuto della pagina molto prima, il che si traduce in migliori metriche di velocità della pagina.

Priorità HTTP/2

La priorità HTTP/2 passa il controllo dell'ordine in cui le risorse vengono caricate, tornando ai proprietari del sito. Se eseguita correttamente, l'assegnazione delle priorità avvantaggia l'esperienza dell'utente e la velocità della pagina/sito fornendo le risorse della pagina in un ordine ottimizzato, creando così un'esperienza utente "veloce".

Se osserviamo il predecessore di HTTP/2, HTTP/1.1, il client Web controllava l'ordine di caricamento delle risorse. Come discusso in precedenza, ciò era dovuto al fatto che ogni connessione TCP era in grado di supportare solo una risorsa alla volta. Sta al browser programmare le richieste decidendo quali risorse scegliere e quante connessioni aprire in parallelo.

Prima di entrare nel modo in cui è stato fatto, è importante capire perché vorremmo utilizzare la definizione delle priorità per le nostre risorse.

Se abbiamo un'immagine nella parte superiore di una pagina e un'immagine nella parte inferiore della pagina, logicamente vorremmo assicurarci che l'immagine nella parte superiore venga caricata prima dell'immagine nella parte inferiore. Questo concetto aiuta a dimostrare l'importanza e l'impatto che la definizione delle priorità di HTTP/2 può portare. La definizione delle priorità HTTP/2 ci consente di specificare quali risorse devono essere consegnate per prime e caricate prima di altre (se si tratta di JavaScript, CSS o immagini), garantendo così il tempo di caricamento più rapido per la pagina.

Mentre il browser ora può richiedere più risorse contemporaneamente su una singola connessione TCP utilizzando il multiplexing, ora può anche specificare le informazioni sulla priorità con ciascuna richiesta per aiutare a determinare quando/come la risorsa deve essere consegnata. Se sia il server che il browser supportano la prioritizzazione HTTP/2, il browser dovrebbe definire le regole per la prioritizzazione utilizzando la larghezza di banda completa senza che le risorse competano tra loro. Per comprendere meglio come funziona il processo di definizione delle priorità, è importante discutere tre parametri importanti per la definizione delle priorità HTTP/2:

Stream: questo è un flusso bidirezionale di byte all'interno di una connessione stabilita che può contenere uno o messaggi.

Flusso principale: questo è un flusso da cui dipendono le risorse

Flusso figlio: questo è un flusso dipendente del flusso padre. Condividono lo stesso genitore e quindi sono conosciuti come flusso figlio

Peso: questo è un numero allocato tra 1 e 256 che identifica quanta larghezza di banda allocare allo streaming se più flussi condividono una connessione. La larghezza di banda viene allocata rispetto ai pesi di tutti gli altri flussi attivi.

Bit esclusivo: questo è un flag che indica che lo stream deve essere scaricato senza condividere la larghezza di banda con altri stream.

Headers Frame: Questa è l'identificazione del flusso a cui appartiene il frame

Binary Framing Layer: ecco come i messaggi HTTP vengono incapsulati e trasferiti tra client e server

Un esempio di seguito mostra un esempio di quanto sopra:

( Priorità del flusso HTTP/2 di Google Developers )

Per eseguire la prioritizzazione HTTP/2, dovrai aggiungere le informazioni sulla prioritizzazione all'interno del frame delle intestazioni situato all'interno del nuovo livello di frame binario HTTP/2. Il flusso padre e la dipendenza/non dipendenza da altri flussi figlio determineranno la priorità/ponderazione e quindi la consegna al client Web della risorsa.

Sebbene la definizione delle priorità HTTP/2 sia ora supportata su numerose piattaforme, molti CDN e provider di hosting non supportano la definizione delle priorità HTTP/2. È quindi importante assicurarsi di utilizzare un provider CDN/hosting che supporti la definizione delle priorità HTTP/2 se si desidera utilizzare questa tecnica di ottimizzazione. Di seguito è riportata una tabella che descrive quali CDN/hosting/server sono in grado e non sono in grado di supportare la priorità HTTP/2.

Priorità HTTP/2 - Compatibilità server/hosting/CDN comuni

Questo confronto era corretto il 02/01/2020 , ma vale la pena verificare se i potenziali fornitori di servizi hanno migliorato la loro compatibilità prima di decidere quale scegliere.

È anche importante esaminare in modo critico browser specifici perché sfortunatamente non tutti i browser supportano l'assegnazione di priorità HTTP/2 e assegnano priorità in modo diverso a causa dei diversi client Web. Di seguito è riportata una tabella che descrive quali client Web sono in grado di supportare la priorità HTTP/2.

Compatibilità client Web con priorità HTTP/2

La definizione delle priorità HTTP/2 può migliorare significativamente la percezione di un utente della velocità della pagina/del sito e avrà un impatto positivo sui dati accumulati nel rapporto sull'esperienza utente di Chrome. Sebbene questa ottimizzazione non abbia alcun impatto sui crawler di ricerca come Googlebot, strumenti come Lighthouse e Page Speed ​​Insights ti aiuteranno a valutare l'impatto della definizione delle priorità HTTP/2 sul rendimento della velocità della pagina dal punto di vista dell'utente.

Configurando correttamente il peso del flusso sia con il server che con il client che utilizza un CDN/host supportato da HTTP/2, sarai in grado di migliorare drasticamente le metriche di velocità della tua pagina per il tuo client.

Quali sono i prerequisiti per HTTP/2

Prima di poter sfruttare i vantaggi in termini di velocità di HTTP/2, assicurati di essere in grado di utilizzarlo. Ci sono alcuni prerequisiti che devono essere presi in considerazione:

1. È importante assicurarsi che HTTPS sia abilitato.
2. Utilizzare un certificato TLS da un'autorità autenticata e attivare e installare il certificato.
3. Assicurati che il software del tuo server Web come Nginx, Apache e IIS supporti HTTP/2. Un elenco completo autenticato per il supporto può essere trovato su http://ayi.ma/browserhttp2 che mostrerà il supporto del browser per HTTP/2. Se stai cercando il supporto HTTP/2 per CDN/Hosting, fai riferimento a http://ayi.ma/serverhosting .

Insidie ​​comuni/Cose che devono cambiare con l'introduzione di HTTP/2

A causa delle limitazioni dei precedenti protocolli HTTP 1.0 e HTTP 1.1, gli sviluppatori e i SEO si sono sforzati di trovare un modo per aggirare la moltitudine di problemi che queste limitazioni presentavano per le prestazioni e la sicurezza della velocità della pagina.

Alla fine, sono stati in grado di trovare "hack" per aggirare alcune di queste limitazioni, ma molti di questi metodi hanno causato agli sviluppatori ancora più lavoro. Quali sono alcuni di questi hack che potresti chiedere? Ecco alcuni degli hack più comuni che vedrai sui siti che possono essere risolti attraverso la corretta implementazione di HTTP/2.

Evita il partizionamento del dominio

Sorprendentemente, una moltitudine di siti utilizza ancora questo hack anche se HTTP/2 è implementato correttamente. Quando HTTP/2 è abilitato, sarà importante evitare di utilizzare il partizionamento orizzontale del dominio. Il Domain Sharding è la tecnica per suddividere le risorse tra diversi nomi host, consentendo così di servire più risorse contemporaneamente.

Grazie al protocollo HTTP/2 aggiornato, il Domain Sharding non è più necessario e infatti causa più problemi di quanti ne risolva. Se HTTP/2 è configurato e abilitato correttamente per il tuo sito e utilizzi anche Domain Sharding, stai effettivamente contrastando alcuni dei vantaggi di HTTP/2 poiché il browser non sarà in grado di trarre vantaggio dal multiplexing e dai download su più nomi host.

Inoltre, tramite Domain Sharding stai effettivamente interrompendo la priorità del flusso e le tue risorse non potranno essere caricate per ottenere il massimo dalla velocità della pagina.

Utilizzare correttamente il server push

Server Push presenta alcuni inconvenienti di cui dovresti essere a conoscenza. Server Push può infatti essere abusato e dovresti essere selettivo quando scegli quando usarlo. Non si desidera necessariamente eseguire il push di troppe risorse poiché ciò potrebbe causare il download del client Web non solo dell'HTML ma di tutto ciò con cui viene "spinto". Ciò significa che la pagina potrebbe effettivamente richiedere più tempo per il caricamento e il rendering (aumento delle metriche incentrate sull'utente su cui si concentra Google come Time to Interactive).

Una seconda trappola comune per il push del server è capire come non inviare risorse che il client web ha già. Questo può essere controllato attraverso numerosi metodi. Un metodo consiste nel scegliere di non inviare le risorse agli utenti di ritorno e quindi consentire agli utenti restituiti di utilizzare le proprie risorse memorizzate nella cache. Questa è di gran lunga l'implementazione più semplice. Questo può essere fatto semplicemente controllando le intestazioni della cache per le risorse assicurandosi che le intestazioni non si sovrappongano all'implementazione push del server.

Test di vita reale in HTTP/2

La conoscenza teorica è sempre importante per gettare le basi per comprendere HTTP/2 e i suoi vantaggi. Una volta che i concetti sono stati afferrati e compresi, è importante testare queste teorie per misurare l'impatto che HTTP/2 può avere su Page Speed.

La parte 2 di questa serie sulla velocità della pagina HTTP/2 nella vita reale - l'utilizzo di test e analisi del sito Web discuterà il vero vantaggio di HTTP/2 per quanto riguarda la velocità della pagina e il valore per la SEO, quindi non perdere l'occasione!

E HTTP/3?

Sebbene HTTP/3 dimostri un chiaro potenziale come protocollo successore di HTTP/2, non segnala e non dovrebbe segnalare la fine di HTTP/2 per i SEO sul Web. Come per ogni nuovo importante sviluppo nel web mondiale, passerà attraverso una normale fase di rollout e probabilmente ci vorrà del tempo prima che un sito adotti il ​​nuovo protocollo e prima che diventi uno standard de facto nel settore SEO. L'implementazione di HTTP/2 rappresenta comunque un vantaggio semplice e vantaggioso che, se implementato correttamente, può aiutare a migliorare le prestazioni del tuo sito.