Benvenuto HTTP/2! Migliori prestazioni per il web

Il protocollo HTTP è quello che ha reso possibile la realizzazione del web come lo conosciamo oggi, ma sai veramente di cosa sto parlando? Recentemente ha visto un grosso aggiornamento e in questo articolo voglio farti capire perché è importante conoscerlo e che cosa ci mette a disposizione.

Però sei di fronte a un sito dedicato a sviluppatori e in questo articolo non troverai neanche una singola riga di codice, fai bene a continuare a leggerlo?

Dal mio punto di vista sì perché ti permetterà di conoscere meglio uno degli strumenti più importanti che hai a disposizione e che per il quale non dovrai fare assolutamente niente per sfruttarlo. Se credevo che leggere questo articolo sarebbe stata una perdita di tempo non avrei investito ore in ricerca e nella sua stesura!

Quando pubblico un articolo su questo blog il mio desiderio è sempre quello di ottenere il miglior risultato possibile, per te che leggi e per me che scrivo.

Dovremmo quindi essere d’accordo sul fatto che conoscere gli strumenti che ci permettono di fare bene il nostro lavoro è una componente essenziale giusto? Ed è proprio per questo motivo che ho deciso di scrivere un articolo su HTTP, anche se questo protocollo lavora dietro le quinte è bene conoscere le sue potenzialità e sapere che cosa chiedere al nostro hosting e browser per sfruttare al meglio le sue caratteristiche.

Scopriamo la storia dietro HTTP

Era il lontano 1997, proprio 20 anni fa, quando la prima specifica di HTTP ha visto la luce. Pensa che questa specifica non era ancora ritenuta stabile ma era comunque in grado di servire le pagine web da una parte all’altra del mondo.

Come penso tu sappia molto bene, ai tempi le pagine web erano basate su un semplice scambio di informazioni testuali. Da una parte dell’emisfero si trovava un server connesso a Internet contenente file HTML e dall’altra parte trovavamo un client che, grazie all’uso di un’applicazione chiamata browser, richiedeva una pagina specifica di un sito web.

Anche se questo comportamento era ideale negli anni novanta, dove si trovavano connesse poche migliaia di persone e il formato di documento scambiato con maggior frequenza era proprio quello HTML, oggi siamo molto più affamati di risorse perché all’interno delle nostre pagine si trovano moltissime chiamate ad altri file.

Sono sicuro che se ti fermi un attimo a pensarci te ne accorgi anche da solo.

In una singola pagina HTML troviamo collegato un file CSS, un file JavaScript e una manciata di immagini. Però questa è soltanto l’analisi “ottimistica” di una pagina web perché se invece ci guardiamo attorno e analizziamo i siti web che popolano la rete troviamo che la situazione è molto diversa.

Al di là di quelle che possono essere le buone pratiche di ottimizzazione, la maggior parte delle pagine web ha decine di file CSS e JavaScript (talvolta anche centinaia) e altrettante immagini che inevitabilmente rallentano il caricamento delle nostre pagine.

Sono consapevole che il più delle volte basta investire sul ferro (ovvero ottenere server e connessioni migliori) per risolvere il problema, ma non voglio pensare soltanto alla soluzione “facile” perché questa è la cosa che ha portato a galla il tallone di achille del protocollo HTTP, ovvero l’impossibilità di caricare in modo asincrono le informazioni di un sito web.

Quindi, fino a poco tempo fa, scaricare una pagina web significava indirizzare il proprio browser verso un dominio e lasciare che i file venissero scaricati uno ad uno. Già con l’avvento della versione 1.1 del protocollo HTTP le cose sono leggermente cambiate perché è diventato possibile avere fino a 8 connessioni simultanee per scaricare i file di un sito web, ma come puoi capire anche da solo questa non era altro che una soluzione precaria che sarebbe stata revisionata nel tempo.

Dal punto di vista di uno sviluppatore web, le soluzioni implementate per risolvere questo problema sono state molte. Le prime che mi vengono in mente sono:

• uso di codice inline direttamente nella pagina
• creazione di immagini sprite grazie alle quali si potevano salvare numerose chiamate HTTP
• la concatenazione di più file in uno singolo (cosa che portava molto spesso grattacapi)
• trasformazione delle immagini in base64 all’interno dei CSS
• e molte altre tecniche…

Praticamente lo sviluppatore web, oltre che dover saper scrivere buon codice, era anche incaricato della sua massima ottimizzazione andando a gestire un problema che rappresentava principalmente un limite non valicabile, ovvero la gestione del protocollo HTTP.

Ci sono altre motivazioni che ci hanno portato alla sostituzione di HTTP/1.1 ma non credi che sia ancora più interessante scoprire quali sono le novità introdotte da questo nuovo protocollo?

Avere HTTP/2 è un bene, ecco perché!

Per essere onesti c’è da dire che tra il 1999 (anno di rilascio di HTTP/1.1) e il 2015 (anno di rilascio di HTTP/2) il web non è rimasto fermo a guardare nella speranza che il team di sviluppatori coinvolti nell’HTTP Working Group si svegliassero e risolvessero la situazione. Infatti nel 2009 due sviluppatori Google (Roberto Peon e Will Chan)  hanno fatto conoscere a tutto il mondo un progetto che stavano curando da tempo e che prometteva di incrementare sensibilmente la velocità delle nostre connessioni.

Il progetto prendeva il nome di SPDY (pronunciato SPeeDY) e anche se inizialmente è stato adottato da moltissimi browser e server web (NGINX fu uno trai i primi), al giorno d’oggi la sua diffusione si è molto limitata fino a scomparire del tutto con l’avvento del HTTP/2.

Come spesso accade nello sviluppo, non si tende a buttar via le belle idee infatti molte delle intuizioni che vennero implementate in SPDY sono oggi vive e vegete all’interno di HTTP/2. Probabilmente ti starai chiedendo ma quali sono queste soluzioni e perché mi dovrebbe interessare questo nuovo protocollo?

Diciamo per prima cosa che molto probabilmente stai già usando HTTP/2!

Se stai usando un browser moderno e stai visitando questa pagina stai già utilizzando questo protocollo, infatti i server su cui è ospitato SkillsAndMore sono stati configurati per l’utilizzo di questo protocollo. Se vuoi sapere se anche il tuo sito web supporta HTTP/2 non dovrai far altro che utilizzare questo semplicissimo tool online offerto da KeyCDN.

Però se stai leggendo questo articolo ti interessa sapere perché è stato alzato tutto questo polverone nei confronti di un protocollo per il quale non dobbiamo fare assolutamente nulla per la sua implementazione, giusto?

Cercherò quindi di presentarti le varie informazioni nel minor tempo possibile.

HTTP/2 offre un multiplex streaming

Cerchiamo di partire con il piede giusto parlando di una delle componenti più interessanti di tutto questo aggiornamento. Ricordi quando prima ti ho parlato dei problemi del numero di connessioni che un browser può avere nei confronti di un server web?

Ebbene i vari rallentamenti che si subivano erano dovuti al fatto che quando il nostro browser richiedeva il file style.css veniva stabilita una connessione TCP verso il server che avrebbe servito l’intero file, in una singola connessione. Finché si parla di un singolo file CSS che (si spera) può pesare al massimo qualche centinaio di kilobyte non ci sono grossi problemi, ma che cosa succede quando viene richiesta un’immagine di grande risoluzione o peggio ancora un video?

Si aspetta che il browser abbia terminato il download!

Anche se con HTTP/1.1 si è tentato di risolvere questo problema aumentando il numero di connessioni TCP simultanee, se all’interno della nostra pagina web sono presenti immagini di grandi dimensioni avremmo sempre finito ad aspettare il loro download…

Con HTTP/2 questo non è più un problema perché grazie a questo protocollo è diventato possibile il multiplexing, ovvero è possibile mandare un numero maggiore di richieste all’interno di una singola connessione TCP. Questo incrementa moltissimo le prestazioni del nostro browser andando a ridurre i tempi di caricamento di una pagina web a un quarto del tempo.

Un buon esempio che mette in esame gli streaming multiplexed di HTTP/2 è questo, potrai notare il tempo di caricamento di una immagine suddifisa in 200 immagini più piccole con i due protocolli e ti accorgerai anche a occhio nudo dove e quando questo protocollo può tornare molto utile.

HTTP/2 invia le Server Push

Fino a poco tempo fa, ovvero fintanto che abbiamo utilizziamo il protocollo HTTP/1.1, quando un browser richiedeva una pagina web il server non faceva altro che inviarla. Una volta ricevuta il browser si accorge che mancano delle immagini e dei file (CSS e JavaScript in primis) e non fa altro che inviare nuovamente delle richieste al server. Ovviamente questo “botta e risposta” implica il rispetto dei classici tempi di attesa per instaurare una nuova connessione rallentando di conseguenza la nostra esperienza utente.

Grazie a HTTP/2 questo non è più necessario perché il server sarà in grado di inviare, oltre che la pagina web, anche tutte le risorse che riterrà opportune per la consultazione del sito web stesso.

Questa è ancora una tecnologia sperimentale e ci sono alcune discussioni su come gestire al meglio i file da inviare ma già diverse aziende, come CloudFlare, hanno dichiarato la propria compatibilità con questa feature.

Semplice compressione degli Header

Con l’uso di HTTP/1.1 ogni richiesta che veniva fatta sul protocollo conteneva un header nel quale veniva dichiarato lo stato della richiesta e altre informazioni, come per esempio il codice HTML che compone una pagina.

HTTP/1.x 200 OK 
Transfer-Encoding: chunked 
Date: Sat, 28 Nov 2019 04:36:25 GMT 
Server: LiteSpeed 
Connection: close 
X-Powered-By: W3 Total Cache/0.8
Pragma: public 
Expires: Sat, 28 Nov 2019 05:36:25 
GMT Etag: "pub1259380237;gz" 
Cache-Control: max-age=3600, public 
Content-Type: text/html; charset=UTF-8 
Last-Modified: Sat, 28 Nov 2009 03:50:37 GMT 
Content-Encoding: gzip 
Vary: Accept-Encoding, Cookie, User-Agent

Questo qua sopra è un semplicissimo header che ho preso da un articolo presente su un sito di settore ma come puoi notare tu stesso, non è tanto la quantità di testo quella che può preoccupare ma soprattutto il fatto che per ogni singola richiesta che facciamo, e in media ne facciamo più di 100 per caricare un’intera pagina web, dobbiamo sprecare dello spazio e risorse per mantenere attive queste informazioni. Di conseguenza aumentiamo anche il tempo impiegato per passare delle informazioni che il browser potrebbe già avere.

Con HTTP/2 le cose sono diverse, infatti non è più necessario scambiarsi queste informazioni perché tutti gli header vengono compressi all’interno di un blocco specifico e questo rende le connessioni più leggere e di conseguenza più veloci 🙂

Uso di codice binario al posto del testo

Se ci pensiamo per un secondo, ogni singola lettera che puoi leggere in questo articolo è composta da un bit (una serie di 1 e 0 di otto cifre) e questo rende le nostre connessioni ancora più pesanti del dovuto.

In modo da ottimizzare ulteriormente il nuovo protocollo è stato deciso di trasformarlo direttamente in codice binario, senza dover passare dal testo. In questo modo i computer (server e client) comunicano in un linguaggio a loro nativo senza dover sprecare altro spazio per tradurre le informazioni in linguaggio umano. Questo diminuisce inoltre la possibilità di errori di comunicazione tra server e client cosa che rende ancora più efficaci le nostre connessioni.

Conclusioni

Prima di concludere vorrei fare un piccolo chiarimento sulla necessità o meno di criptare le comunicazioni del nostro server, ovvero utilizzare dei certificati SSL/TLS come Let’s Encrypt per il proprio server. Durante il lancio di questo nuovo protocollo in molti addetti ai lavori hanno dichiarato la necessità di questo certificato per far funzionare al meglio il neonato protocollo ma, come chiarisce la stessa pagina di HTTP/2, questo certificato non sarebbe necessario per il corretto funzionamento. Purtroppo non esiste alcun browser che ha rispettato questa specifica e per poterlo utilizzare il server web deve anche servire un certificato specifico.

Che sia chiaro, io non sono contrario a questa scelta perché in fin dei conti rende le comunicazioni con il nostro server più sicure e ci permette di scambiare i nostri dati sensibili con il sito che stiamo consultando. Quello che sto dicendo è soltanto che le specifiche del protocollo HTTP/2 non richiedono la presenza di questo certificato e se un domani i browser decideranno di rispettare la specifica non sarà essenziale avere questo certificato installato sui propri server.

Adesso che conosci le principali caratteristiche di questo protocollo lascia che ti faccia una domanda: hai trovato interessante la lettura?

Onestamente ho scritto questo articolo in maggior parte per fornirti una base di conoscenza in grado di aiutarti a muoverti al meglio in questo mondo tecnologico e in continua evoluzione. Allo stesso tempo ho intenzione di tornare nuovamente su questo argomento perché voglio parlarti di come uno sviluppatore web si dovrebbe muovere per sfruttare al meglio le caratteristiche del protocollo HTTP/2.

Soprattutto perché tante delle ottimizzazioni che abbiamo messo in atto negli anni per ottimizzare le nostre pagine web con le precedenti versioni non sono più valide e anzi sono sconsigilate perché non tendono a sfruttare le nuove funzionalità.

Ecco perché ci tenevo a condividere con te queste informazioni riguardanti il protocollo HTTP/2. Fammi sapere che ne pensi all’interno dei commenti e non esitare a condividerlo per aiutare altri colleghi sviluppatori a migliorare le proprie conoscenze!