HTTP/2 vs HTTP/3 : ce qui a réellement changé et ce que cela signifie pour votre site

Pourquoi HTTP/1.1 devait partir

Une page moderne a besoin de dizaines de ressources — HTML, CSS, scripts, images, polices. HTTP/1.1 ne traitait qu’une requête à la fois par connexion, si bien que les navigateurs ouvraient environ six connexions parallèles par hôte et mettaient le reste en file d’attente. Chaque connexion payait son propre handshake TCP et TLS, et une réponse lente retenait tout ce qui attendait derrière elle sur cette connexion. Les contournements de l’époque — sprite sheets, domain sharding, inlining — n’étaient que des astuces pour faire passer plus de ressources dans trop peu de tuyaux.

Ce que HTTP/2 a corrigé

HTTP/2 (2015) a remplacé les tuyaux par un seul : une connexion unique transportant de nombreux flux parallèles. Un nombre quelconque de requêtes et de réponses s’entrelacent sans se faire attendre à la couche HTTP ; les en-têtes sont compressés au lieu d’être répétés intégralement à chaque requête ; le coût du handshake n’est payé qu’une fois.

Pour les sites réels, c’était le grand saut — le jonglage à six connexions a disparu, et les pages riches en petites ressources sont devenues nettement plus rapides. C’est le protocole que la majorité du web, et la plupart des CDN, servent aujourd’hui. Une note de bas de page honnête : HTTP/2 a déplacé le problème du head-of-line une couche plus bas au lieu de l’éliminer. Tous ces flux parallèles voyagent toujours sur une seule connexion TCP, et TCP exige de livrer les octets dans l’ordre — un seul paquet perdu met donc en pause *tous* les flux jusqu’à sa retransmission. Sur un réseau propre, c’est rare ; sur un signal mobile faible, c’est la taxe que vous payez.

Ce que HTTP/3 change en dessous

HTTP/3 (2022) s’attaque à cette taxe restante en remplaçant TCP par QUIC, un transport bâti sur UDP avec TLS 1.3 intégré. Trois choses changent réellement. Les handshakes deviennent moins chers : transport et chiffrement se négocient ensemble, si bien qu’une nouvelle connexion coûte un aller-retour au lieu de deux ou trois — et se reconnecter à un serveur déjà connu peut ne rien coûter du tout. La perte de paquets cesse d’être contagieuse : QUIC suit chaque flux indépendamment, donc un paquet perdu ne bloque que le flux auquel il appartenait, pas tout ce qui est en vol. Et les connexions survivent aux changements de réseau : passer du Wi-Fi aux données mobiles migre la connexion au lieu de la tuer.

Remarquez le motif — chacun de ces gains concerne les réseaux imparfaits. C’est exactement là que HTTP/3 brille : liaisons à forte latence, Wi-Fi avec pertes, utilisateurs mobiles en mouvement, longues distances jusqu’au serveur.

Le dimensionnement honnête : ce que vaut chaque étape

Sur une bonne connexion proche du serveur, HTTP/3 face à HTTP/2 apporte typiquement une amélioration de quelques pour cent — réelle, mesurable, et invisible pour un humain. Sur une liaison mobile avec pertes et à distance, la différence peut être grande et ressentie. Le saut de HTTP/1.1 à HTTP/2, lui, a été important pour presque tout le monde. Si votre trafic est très mobile ou géographiquement dispersé, HTTP/3 compte pour vos latences de queue ; s’il est surtout desktop sur des réseaux corrects, c’est un raffinement.

Pendant ce temps, ce qui domine le temps de chargement n’a pas bougé : la proximité du contenu (cache en périphérie), son poids (images, compression), et la part qui bloque le rendu. Une page en cache, compressée en Brotli et aux images optimisées servie en HTTP/2 bat une page non optimisée en HTTP/3 à chaque fois — les protocoles décident de millisecondes, la diffusion décide de secondes. Notre périphérie sert HTTP/2 aujourd’hui, là où vit le gain protocolaire décisif ; les leviers de diffusion posés dessus sont là où va le reste de votre budget vitesse.

Vérifiez ce que votre site parle réellement

Inutile de deviner. Dans le navigateur, ouvrez DevTools → Network, activez la colonne Protocol et lisez : h2 signifie HTTP/2, h3 signifie HTTP/3. Depuis un terminal, curl répond en une ligne. Pendant que vous y êtes, regardez aussi le statut de cache dans les en-têtes de réponse — une montée de protocole sur un aller-retour origine non mis en cache, c’est polir la mauvaise couche.

Inspecter le protocole négocié avec curl

# which protocol does the server negotiate?
curl -sI --http2 https://www.example.com -o /dev/null -w 'protocol: %{http_version}\n'

# full picture: protocol + timing + cache status
curl -sI https://www.example.com -w 'protocol: %{http_version}  ttfb: %{time_starttransfer}s\n' | grep -i -E 'HTTP/|cache|protocol|ttfb'

Un ordre des opérations raisonnable

Traitez le protocole comme un levier sur le tableau, pas comme le tableau. Prenez d’abord les gains décisifs : servez à travers un cache en périphérie pour rapprocher le contenu, compressez le texte en Brotli, passez les images en WebP/AVIF à des dimensions honnêtes — ces leviers déplacent des secondes et chaque visiteur en profite. Le multiplexage HTTP/2 est un acquis de base et transporte déjà vos requêtes en parallèle. Ensuite, si vos données de terrain montrent que les latences de queue sur mobile sont votre vrai point de douleur, les raffinements protocolaires méritent attention — mesurés contre vos propres chiffres, pas contre le benchmark d’un fournisseur.

La vérité inconfortable des débats de protocole, c’est qu’ils sont amusants et largement tranchés, tandis que le poids des images et le taux de hit du cache sont ennuyeux et décisifs. Optimisez dans cet ordre.