Internet, tel que nous le connaissons tous aujourd'hui, n'aurait pas pu exister sans le protocole HTTP. Ce protocole est le coeur et l'âme qui définit tous nos contenus. Il nous rend possible la lecture des dernières nouvelles en ligne, il nous permet de regarder des vidéos sur YouTube et d'apprendre de nos sites Web préférés sur tous les types d'appareils, du poste de travail avec écran 27 pouces aux ordinateurs portables, téléphones mobiles ou tablettes.
Malheureusement, ce protocole n'a pas été modifié depuis 1999 avec la version 1.1.
Alors lorsque HTTP/2 a pointé le bout de son nez, autant vous dire que cela a généré une certaine excitation dans la communauté web. Comme on en a l'habitude maintenant, l'équipe de SiteGround a immédiatement commencé à travailler dessus et nous a aujourd'hui gratifié de cette technologie sur l'ensemble de leur infrastructure serveurs :-) Cela comprend donc tous leur hébergements mutualisés mais aussi leur Cloud server.
Pourquoi HTTP a-t-il eu besoin de cette évolution ?
Les applications et sites web modernes sollicitent des centaines de demandes HTTP 1.1 et il n'est pas très bien conçu pour répondre à ces nouveaux besoins de performance du web moderne, ajouté au fait que les exigences des utilisateurs ne cessent de croître, notamment en terme de temps de réponse.
Au cours de ces 17 dernières années, de nombreuses nouvelles technologies sont apparues et les développeurs web ont su contourner les limites techniques de HTTP 1.1. Mais il était temps pour le protocole lui-même d'introduire des nouvelles fonctionnalités permettant d'offrir de meilleures performances.
Quels sont les apports de HTTP/2 ?
HTTP/2 est basé sur SPDY et se concentre sur l'amélioration des performances. Il permet les améliorations suivantes:
Multiplexage pour un transfert plus rapide des données
Les sites web modernes utilisent des navigateurs Web faisant un grand nombre de requêtes. Au début, HTTP/1.0 n'autorisait qu'une seule demande via une connexion TCP unique. Avec HTTP/1.1, les navigateurs pouvaient charger simultanément de nombreuses ressources. Malheureusement, un autre problème appelé "blocage de la tête de ligne (head-of-line blocking)" n'a pas été résolu.
Lorsque HTTP/1.1 est utilisé, le flux de demandes est généralement le suivant : le navigateur envoie une requête et doit attendre la réponse du serveur pour envoyer la demande suivante. Les sites webs modernes ont généralement plus de 100 objets et même lorsque les navigateurs utilisent plusieurs connexions de cette façon, les demandes peuvent prendre beaucoup de temps en raison du fameux "head-of-line blocking".
La solution offerte par HTTP/2 est appelé multiplexage. C'est un moyen simple de demander et de recevoir des objets Web multiples simultanément par le biais d'une connexion unique. C'est la solution qui résoud ce problème de "head-of-line blocking".
Plus précisément, HTTP/2 résout ce problème en utilisant des trames.
Chaque trame contient des méta-informations à propos des demandes / réponses ce qui permet à une connexion d'être utilisée en lecture simultanée sans provoquer de confusion sur la réponse qui est associée à la demande. Lorsque HTTP/2 est utilisé, l'utilisateur envoie plusieurs demandes et peut les recevoir dans n'importe quel ordre. Les pages se chargent donc plus rapidement.
Par exemple, si le serveur a besoin de plus de temps pour gérer la deuxième demande, l'envoi de la troisième n'est pas bloquée.
Compression des en-têtes pour transferer moins de données
La deuxième grande amélioration de HTTP/2 concerne les en-têtes HTTP.
Les clients utilisent les en-têtes pour informer les serveurs de quelle information est nécessaire et sous quelle forme l'information devrait leur être livrée. Par exemple, un navigateur Web envoie habituellement des en-têtes pour informer aux serveurs qu'ils prennent en charge des données compressées Gzip. Les cookies sont également communiqués via des en-têtes et la taille de certains cookies peut devenir trop importante.
Le problème est que les en-têtes ne changent pas beaucoup entre les demandes. Aussi, avec HTTP/1.1, les en-têtes devaient être fournis pour chaque requête, ce qui bien sûr est inutile quand les en-têtes ne changent pas. Maintenant avec HTTP/2, non seulement il envoie des en-têtes par connexion, mais il offre également une compression.
Cela signifie qu'une page web, qui contient en moyenne 80 à 90 objets, peut maintenant être chargée beaucoup plus rapidement car le navigateur web devra simplement réaliser un aller-retour pour envoyer toutes les en-têtes de tous les objets.
Mise en priorité des objets pour un meilleur rendu des pages
Le troisième problème que HTTP/2 résout vient de la compression des en-têtes en multiplexage. Certains objets sont plus importants que d'autres, par exemple les objets CSS, et devraient être livrés au début afin que le site puisse s'afficher correctement. Si le multiplexage est utilisé vous ne pouvez pas être sûr que le CSS sera livré avant le reste des objets.
Les concepteurs du protocole ont donc décidé de traiter cette question dans le protocole lui-même. Dorénavant, les clients sont maintenant en mesure de communiquer avec le serveur en indiquant des priorités pour certains objets. De cette façon les serveurs Web peuvent prendre des décisions sur les objets qui devraient être livrés en priorité aux clients.
Le protocol HTTP/2 a besoin de SSL / TLS
Vous avez besoin d'un certificat SSL sur votre site web afin de profiter des avantages de HTTP/2. Vous trouverez plus d'informations sur HTTP/2 ici : https://http2.github.io/faq/
Est-ce que HTTP/2 est déjà utilisé ?
HTTP/2 est déjà déployé et vous l'avez probablement déjà utilisé si vous utilisez un navigateur moderne comme Chrome, Firefox ou Opera. Et donc maintenant, tous les serveurs muituallisés et Cloud de SiteGround supportent HTTP/2.
Quelle conclusion tirer de tout ça ?
En résumé, comprenez que quand HTTP/2 est supporté par votre hébergeur, la mise en place d'un certificat SSL sur votre site (https) devient vraiment un must-have, surtout avec Let's Encrypt qui permet maintenant la mise en place de certificat SSL gratuitement ! Et devinez qui sont les 1ers à avoir implémenté Let's Encrypt sur leur serveurs mutualisés et leur Cloud Server (voir notre tuto sur la miseen place de Let's Encrypt chez Siteground) ?? Bref, du SiteGround, la routine... :-)
Si vous voulez vous faire un avis plus précis sur SiteGround, jetez un oeil à cet article.
Articles qui devraient vous intéresser
Quel hébergeur et hébergement Joomla 3.9 faut-il choisir ?
Comment réaliser un formulaire de contact compatible RGPD
