Qu'est-ce que HTTP/2 ?

HTTP/2 est la deuxième version majeure du protocole Hypertext Transfer Protocol, finalisée en tant que RFC 7540 en mai 2015. Il s'agissait de la première mise à jour significative de HTTP depuis la standardisation de HTTP/1.1 en 1997, et elle a résolu des problèmes de performance fondamentaux qui ont affecté le web pendant près de deux décennies. Si votre site WordPress diffuse encore son contenu via HTTP/1.1, vous laissez probablement passer des gains de performance importants.

Le protocole est issu du protocole expérimental SPDY de Google, utilisé depuis 2012, qui a démontré que les idées centrales de HTTP/2 (multiplexage, compression des en-têtes, priorisation) fonctionnaient bien en production. Lorsque l'IETF a standardisé HTTP/2, SPDY a été retiré et ses concepts sont devenus le fondement du nouveau standard.

Principales améliorations par rapport à HTTP/1.1

Pour comprendre l'importance de HTTP/2, il faut d'abord comprendre ce qui n'allait pas avec HTTP/1.1. Avec l'ancien protocole, chaque connexion TCP ne pouvait traiter qu'une seule requête à la fois. Si votre navigateur devait charger 40 ressources (une page WordPress typique), il devait ouvrir plusieurs connexions (les navigateurs autorisent généralement 6 par domaine) et mettre en file d'attente les requêtes restantes. Cela créait des goulots d'étranglement artificiels qui ralentissaient chaque chargement de page.

HTTP/2 corrige cela et bien plus :

Multiplexage : il s'agit de la plus grande amélioration. HTTP/2 permet à plusieurs requêtes et réponses d'être en cours simultanément sur une seule connexion TCP. Votre navigateur peut demander votre fichier CSS, trois fichiers JavaScript et dix images en même temps, sur une seule connexion. Plus d'attente, plus de file d'attente, plus de limites artificielles. Le serveur renvoie les réponses au fur et à mesure qu'elles deviennent disponibles, et le navigateur les assemble. Ce seul changement peut réduire considérablement les temps de chargement des sites WordPress riches en ressources.

Compression des en-têtes (HPACK) : les en-têtes HTTP sont envoyés à chaque requête et réponse. Dans HTTP/1.1, ces en-têtes sont en texte brut et souvent répétitifs. Les mêmes cookies, chaînes user-agent et en-têtes accept sont envoyés encore et encore. HTTP/2 utilise un algorithme de compression appelé HPACK qui maintient une table partagée des champs d'en-tête courants entre le client et le serveur. Après la première requête, les en-têtes suivants n'ont besoin d'envoyer que les différences. Pour un site WordPress qui charge 50 ressources ou plus par page, cela peut économiser des dizaines de kilo-octets par chargement de page.

Trame binaire : HTTP/1.1 est un protocole textuel, ce qui signifie que l'analyseur doit rechercher les sauts de ligne, gérer différents encodages de texte et traiter divers cas particuliers. HTTP/2 utilise une couche de trame binaire qui encapsule toute la communication dans des trames bien définies. Les données binaires sont plus rapides à analyser, moins sujettes aux erreurs et plus compactes. Vous ne le remarquerez jamais en tant qu'utilisateur, mais cela réduit la charge de traitement à la fois sur le serveur et sur le client.

Priorisation des flux : HTTP/2 permet au navigateur d'indiquer au serveur quelles ressources sont les plus importantes. Par exemple, le navigateur peut signaler que le fichier CSS principal doit être livré avant les images d'arrière-plan. Le serveur peut alors allouer la bande passante en conséquence. En pratique, les implémentations de la priorisation par les navigateurs varient et tous les serveurs ne la gèrent pas parfaitement, mais elle apporte tout de même des améliorations significatives pour de nombreux sites.

Server Push : cette fonctionnalité permet au serveur d'envoyer des ressources au navigateur avant même que celui-ci ne les demande. Lorsque le navigateur demande une page HTML, le serveur peut pousser les fichiers CSS et JavaScript dont il sait que le navigateur aura besoin ensuite. Cela élimine le délai d'aller-retour pendant lequel le navigateur découvre qu'il a besoin d'une ressource, puis la demande. Cependant, Server Push a connu une adoption limitée en pratique. Il est délicat à mettre en œuvre correctement (pousser des ressources que le navigateur a déjà en cache gaspille de la bande passante), et certains CDN ont abandonné sa prise en charge. Chrome a supprimé la prise en charge de Server Push dans la version 106 (2022). Le concept perdure dans le mécanisme 103 Early Hints, plus simple et plus pratique.

Pourquoi le sharding de domaines n'est plus nécessaire

À l'ère de HTTP/1.1, les développeurs web utilisaient une astuce appelée sharding de domaines pour contourner la limite de 6 connexions par domaine. Ils servaient les images depuis img1.example.com, le CSS depuis cdn.example.com et les polices depuis encore un autre sous-domaine. Cela multipliait le nombre de connexions parallèles que le navigateur pouvait ouvrir.

Avec HTTP/2, le sharding de domaines est non seulement inutile, mais en réalité contre-productif. Comme HTTP/2 multiplexe toutes les requêtes sur une seule connexion, répartir les ressources sur plusieurs domaines force le navigateur à établir des connexions TCP et des poignées de main TLS supplémentaires. Chaque nouvelle connexion ajoute de la latence. Un site WordPress optimisé avec le sharding de domaines pour HTTP/1.1 devrait consolider ses ressources sur moins de domaines lors du passage à HTTP/2.

De même, concaténer les fichiers CSS et JavaScript en bundles uniques (une autre optimisation courante de HTTP/1.1) devient moins important avec HTTP/2. L'envoi de nombreux petits fichiers fonctionne efficacement grâce au multiplexage, et présente l'avantage supplémentaire d'une meilleure mise en cache : lorsqu'un petit fichier change, seul ce fichier doit être retéléchargé, pas le bundle concaténé entier.

HTTP/2 nécessite HTTPS en pratique

La spécification HTTP/2 ne nécessite techniquement pas le chiffrement. Vous pouvez avoir HTTP/2 sur du TCP en clair (appelé h2c, pour HTTP/2 cleartext). Cependant, tous les navigateurs majeurs (Chrome, Firefox, Safari, Edge) ont décidé de n'implémenter HTTP/2 que sur TLS (appelé h2). Cela signifie qu'à toutes fins pratiques, vous avez besoin d'un certificat SSL/TLS pour utiliser HTTP/2.

Ce n'est plus vraiment une limitation aujourd'hui. Les certificats gratuits de Let's Encrypt ont rendu HTTPS accessible à tous, et la plupart des hébergeurs WordPress incluent des certificats SSL dans leurs offres. Si votre site WordPress est encore en HTTP simple, le passage à HTTPS est un prérequis pour HTTP/2, et apporte ses propres bénéfices en matière de sécurité.

HTTP/3 et QUIC : l'étape suivante

HTTP/3 (RFC 9114, finalisé en juin 2022) est l'évolution suivante. Alors que HTTP/2 fonctionne au-dessus de TCP, HTTP/3 remplace entièrement TCP par un nouveau protocole de transport appelé QUIC. QUIC est construit sur UDP et intègre directement le chiffrement TLS 1.3 dans la couche de transport. Les principaux avantages de HTTP/3 par rapport à HTTP/2 sont :

• Établissement de connexion plus rapide : QUIC combine la poignée de main TCP et la poignée de main TLS en un seul aller-retour, réduisant le temps d'établissement de la connexion. Pour les visiteurs récurrents, il peut même atteindre une reprise de connexion sans aller-retour.
• Pas de blocage de tête de file : dans HTTP/2 sur TCP, si un seul paquet est perdu, tous les flux de cette connexion sont bloqués jusqu'à ce que le paquet soit retransmis. QUIC gère la perte de paquets par flux, de sorte qu'un paquet perdu ne retarde que le flux affecté, pas tout le reste.
• Meilleures performances mobiles : QUIC gère plus élégamment les changements de réseau (comme le passage du WiFi à la téléphonie mobile) car les connexions sont identifiées par un identifiant de connexion plutôt que par une adresse IP et un port.

Les principaux fournisseurs de CDN comme Cloudflare et Fastly prennent déjà en charge HTTP/3. La plupart des hébergeurs sont encore en train de l'adopter. Pour les propriétaires de sites WordPress, la prise en charge de HTTP/3 est largement une question côté serveur ; vous n'avez rien à changer dans WordPress lui-même.

Comment vérifier si votre hébergeur prend en charge HTTP/2

Il existe plusieurs façons de vérifier si votre site WordPress est servi via HTTP/2 :

• Outils de développement du navigateur : ouvrez l'onglet Réseau dans les DevTools de Chrome, faites un clic droit sur les en-têtes de colonnes et activez la colonne « Protocol ». Vous devriez voir h2 pour les requêtes HTTP/2.
• Outils en ligne : des sites comme le test HTTP/2 de KeyCDN ou le vérificateur HTTP/2 sur tools.keycdn.com peuvent vérifier la prise en charge de HTTP/2 pour n'importe quelle URL.
• Ligne de commande : exécutez curl -I --http2 -s https://yoursite.com et recherchez HTTP/2 200 dans la réponse.
• InspectWP : le rapport inclut la version HTTP détectée pour votre site WordPress.

Si votre hébergeur ne prend pas en charge HTTP/2, placer un CDN comme Cloudflare devant votre site peut fournir la prise en charge de HTTP/2 (et HTTP/3) même si votre serveur d'origine ne parle que HTTP/1.1. Le CDN gère la connexion HTTP/2 avec le navigateur du visiteur et communique avec votre serveur d'origine en utilisant le protocole qu'il prend en charge.

Implications pour les performances WordPress

Une page WordPress typique charge entre 20 et 80 ressources individuelles : feuilles de style du thème et des extensions, fichiers JavaScript, polices web, images et parfois des ressources externes provenant de CDN et de services tiers. Avec HTTP/1.1, le chargement de toutes ces ressources était le principal contributeur au temps de chargement de la page en raison des limitations de connexion et de file d'attente.

Après le passage à HTTP/2, la plupart des sites WordPress constatent des améliorations significatives du Time to First Contentful Paint et du temps de chargement global. L'amélioration exacte dépend du nombre de ressources chargées par votre site, mais des réductions de 20 à 50 % du temps de chargement sont courantes pour les sites précédemment sur HTTP/1.1. Les sites avec de nombreuses petites ressources (typique pour WordPress avec plusieurs extensions actives) en bénéficient le plus.

Gardez à l'esprit que HTTP/2 ne remplace pas les autres optimisations de performance. Vous avez toujours besoin d'une mise en cache appropriée, d'une optimisation des images et d'un code efficace. Mais HTTP/2 supprime un goulot d'étranglement important au niveau de l'infrastructure qu'aucune optimisation d'extension WordPress ne peut corriger.

Ce que vérifie InspectWP

InspectWP détecte la version du protocole HTTP utilisée par votre site WordPress en examinant les en-têtes de réponse. Si votre site est servi via HTTP/1.1, le rapport signale cela comme un problème de performance et recommande la mise à niveau vers HTTP/2. Si HTTP/2 ou HTTP/3 est détecté, c'est rapporté comme un résultat positif. La version HTTP est affichée dans la section performance du rapport, aux côtés d'autres métriques au niveau du serveur comme la compression et les en-têtes de réponse.