HTTP/2 comparé à HTTP/1.1 : Comment ces protocoles affectent-ils les performances web ?

HTTP/2 permet aux développeurs de personnaliser la définition de priorités ou l'ordre de chargement des ressources web. HTTP/2 offre également un certain nombre d'autres améliorations de performances par rapport à HTTP/1.

Share facebook icon linkedin icon twitter icon email icon

HTTP/2 & HTTP/1.1

Objectifs d’apprentissage

Après avoir lu cet article, vous :

  • Découvrez ce qu'est HTTP et les différences entre les différentes versions de HTTP
  • Comprendre comment fonctionne la hiérarchisation dans HTTP/2
  • Découvrez comment HTTP/2 améliore les performances web

Qu'est-ce que HTTP ? Pourquoi HTTP/2 est-il plus rapide que HTTP/1.1 ?

HTTP signifie protocole de transfert hypertexte. Il est à la base de presque toutes les applications Web. Plus précisément, HTTP est la méthode utilisée par les ordinateurs et les serveurs pour demander et envoyer des informations. Par exemple, lorsque quelqu'un accède à cloudflare.com sur son ordinateur portable, son navigateur web envoie une demande HTTP aux serveurs Cloudflare pour le contenu qui apparaît sur la page. Ensuite, les serveurs Cloudflare envoient des réponses HTTP avec le texte, les images et le formatage que le navigateur affiche à l'utilisateur.

La première version utilisable de HTTP a été créée en 1997. Parce qu'elle a traversé plusieurs phases de développement, cette première version de HTTP a été appelée HTTP/1.1. Cette version est toujours utilisée sur le web. En 2015, une nouvelle version de HTTP appelée HTTP/2 a été créée.

HTTP/2 résout plusieurs problèmes que les créateurs de HTTP/1.1 n'avaient pas anticipés. En particulier, HTTP/2 est beaucoup plus rapide et plus efficace que HTTP/1.1. Une des façons dont HTTP/2 est plus rapide réside dans la façon dont il priorise le contenu pendant le processus de chargement.

Qu'est-ce que la priorisation ?

Dans le contexte de la performance du web, la hiérarchisation fait référence à l'ordre dans lequel les éléments de contenu sont chargés. Supposons qu'un utilisateur visite un site web d'actualités et accède à un article. Quel élément doit être chargé en premier ? la photo en haut de l'article ? Le texte de l'article ? Les bannières publicitaires ?

La hiérarchisation affecte le temps de chargement d'une page web. Par exemple, certaines ressources, comme les fichiers JavaScript volumineux, peuvent empêcher le chargement du reste de la page si elles doivent être chargées en premier. Une plus grande partie de la page peut être chargée immédiatement si ces ressources bloquant le rendu sont chargées en dernier.

De plus, l'ordre dans lequel les ressources de page sont chargées affecte la façon dont l'utilisateur perçoit le temps de chargement de la page. Si seul le contenu en arrière-plan (comme un fichier CSS) ou le contenu que l'utilisateur ne peut pas voir immédiatement (comme les bannières publicitaires en bas de la page) est chargé en premier, l'utilisateur pensera que la page ne se charge pas du tout. Si le contenu le plus important pour l'utilisateur est chargé en premier, comme l'image en haut de la page, l'utilisateur aura l'impression que la page se charge plus rapidement.

Comment la priorisation dans HTTP/2 affecte-t-elle les performances ?

En HTTP/2, les développeurs ont un contrôle pratique et détaillé de la priorisation. Cela leur permet de maximiser la vitesse de chargement des pages perçue et réelle à un degré qui n'était pas possible en HTTP/1.1.

HTTP/2 offre une fonctionnalité appelée priorisation pondérée. Cela permet aux développeurs de décider à chaque fois quelles ressources de page seront chargées en premier. Dans HTTP/2, lorsqu'un client fait une demande de page web, le serveur envoie plusieurs flux de données au client à la fois, au lieu d'envoyer les choses les unes après les autres. Cette méthode de livraison de données est connue sous le nom de multiplexage. Les développeurs peuvent attribuer à chacun de ces flux de données une valeur pondérée différente, la valeur indiquant au client le flux de données à restituer en premier.

Imaginez qu'Alice veuille lire un roman que son ami Bob a écrit, mais Alice et Bob ne communiquent que par la poste. Alice envoie une lettre à Bob et lui demande de lui envoyer son roman. Bob décide d'envoyer le roman dans le style HTTP/1.1 : il envoie un chapitre à la fois et n'envoie le chapitre suivant qu'après avoir reçu une lettre de réponse d'Alice confirmant qu'elle a reçu le chapitre précédent. En utilisant cette méthode de diffusion de contenu, il faut plusieurs semaines à Alice pour lire le roman de Bob.

Imaginez maintenant que Bob décide d'envoyer à Alice son roman dans le style HTTP/2 : dans ce cas, il envoie chaque chapitre du roman séparément (pour respecter les limites de taille du service postal), mais tous les chapitres en même temps. Il numérote également chaque chapitre : Chapitre 1, Chapitre 2, etc. Cette fois, Alice reçoit le roman en une seule fois et peut l'assembler dans le bon ordre à son propre rythme. Si un chapitre manque, elle peut envoyer une réponse rapide en demandant le chapitre manquant, sinon le processus est terminé et Alice peut lire le roman en quelques jours seulement.

En HTTP/2, les données sont envoyées en une seule fois, tout comme Bob lorsqu'il envoie en même temps plusieurs chapitres à Alice. Et tout comme Bob, les développeurs peuvent numéroter les chapitres en HTTP/2. Ils peuvent décider si le texte d'une page web se charge en premier, ou les fichiers CSS, ou le JavaScript, ou tout ce qu'ils jugent primordial pour l'expérience utilisateur.

Quelles sont les autres différences entre HTTP/2 et HTTP/1.1 qui affectent la performance ?

Multiplexage : HTTP/1.1 charge les ressources les unes après les autres, donc si une ressource ne peut pas être chargée, elle bloque toutes les autres ressources derrière elle. En revanche, HTTP/2 est capable d'utiliser une seule connexion TCP pour envoyer plusieurs flux de données à la fois afin qu'aucune ressource ne bloque une autre ressource. HTTP/2 le fait en divisant les données en messages de code binaire et en numérotant ces messages afin que le client sache à quel flux appartient chaque message binaire.

Push serveur : en règle générale, un serveur ne sert le contenu à un périphérique client que si le client le demande. Cependant, cette approche n'est pas toujours pratique pour les pages web modernes, qui impliquent souvent plusieurs dizaines de ressources distinctes que le client doit demander. HTTP/2 résout ce problème en autorisant un serveur à « pousser » le contenu vers un client avant que le client ne le demande. Le serveur envoie également un message indiquant au client le contenu « poussé » auquel il peut s'attendre (comme si Bob avait envoyé à Alice une table des matières de son roman avant d'envoyer l'ensemble des chapitres).

Compression d'en-tête : les petits fichiers se chargent plus rapidement que les gros. Pour accélérer les performances web, HTTP/1.1 et HTTP/2 compressent les messages HTTP pour les réduire. Cependant, HTTP/2 utilise une méthode de compression plus avancée appelée HPACK qui élimine les informations redondantes dans les paquets d'en-tête HTTP. Cela élimine quelques octets de chaque paquet HTTP. Étant donné le volume de paquets HTTP impliqués dans le chargement d'une seule page web, ces octets s'additionnent rapidement, ce qui accélère le chargement.

Qu'est-ce que HTTP/3 ?

HTTP/3 est la prochaine version proposée du protocole HTTP. HTTP/3 n'est pas encore adopté à grande échelle sur le web, mais il est de plus en plus utilisé. La principale différence entre HTTP/3 et les versions précédentes du protocole est que HTTP/3 s'exécute sur QUIC au lieu de TCP. QUIC est un protocole de la couche transport plus rapide et plus sécurisé conçu pour les besoins de l'Internet moderne.

Comment Cloudflare aide-t-il les développeurs à implémenter HTTP/2 pour des performances plus rapides ?

Cloudflare prend en charge toutes les fonctionnalités de HTTP/2. Les propriétés web sur Cloudflare peuvent activer HTTP/2 gratuitement en un seul clic. Cloudflare prend en charge HTTP/3 en plus de HTTP/2.