Quand on parle de la vitesse d’un site, on pense presque toujours à ce que fait le serveur pour générer la page et à ce que fait le navigateur pour l’afficher. Entre les deux se trouve le réseau, que l’on tient généralement pour acquis. Pourtant, sur un smartphone connecté à un réseau mobile, une part importante du temps de chargement ne dépend ni du serveur ni du navigateur, mais du nombre d’allers-retours que doivent faire les données et de ce qui se passe quand des paquets se perdent en chemin.
HTTP/3, fondé sur le protocole de transport QUIC, a été créé précisément pour réduire ces coûts. Il est pris en charge par tous les principaux navigateurs, par les plus grands CDN et par un nombre croissant de serveurs web, et une part substantielle du trafic web l’utilise déjà. Dans cet article, nous voyons ce qui change par rapport à HTTP/2, pourquoi les bénéfices se concentrent sur les réseaux mobiles, comment l’activer et ce qu’il faut raisonnablement en attendre pour les Core Web Vitals.
De HTTP/1.1 à HTTP/3, en bref
Avec HTTP/1.1, chaque connexion ne pouvait traiter qu’une requête à la fois : pour télécharger de nombreuses ressources en parallèle, les navigateurs ouvraient jusqu’à six connexions par domaine, chacune avec son propre coût d’ouverture. HTTP/2 a introduit le multiplexage : plusieurs requêtes simultanées sur la même connexion, réparties en flux indépendants. Ce fut un grand pas en avant, mais avec une limite structurelle : HTTP/2 passe par TCP, et TCP livre les données dans un ordre unique et strict.
HTTP/3 conserve le même modèle que HTTP/2, avec plusieurs requêtes sur une connexion, mais remplace TCP par QUIC, un protocole de transport construit sur UDP. QUIC intègre le chiffrement TLS 1.3 directement dans le transport, gère chaque flux de façon indépendante et identifie les connexions avec son propre identifiant plutôt que par l’adresse et le port. Ces trois choix produisent les trois principaux avantages : des connexions plus rapides à ouvrir, pas de blocage en chaîne en cas de perte d’un paquet, et des connexions qui survivent à un changement de réseau.
Premier avantage : moins d’allers-retours pour démarrer
Avant de pouvoir demander une page avec HTTP/2, le navigateur doit ouvrir une connexion TCP, ce qui prend un aller-retour vers le serveur, puis négocier le chiffrement TLS, ce qui avec TLS 1.3 prend un autre aller-retour. Ce n’est qu’au troisième aller-retour que part la requête proprement dite. Avec QUIC, l’ouverture de la connexion et la négociation du chiffrement se font ensemble, en un seul aller-retour. Quand le navigateur s’est connecté récemment au même serveur, QUIC permet aussi la reprise 0-RTT : la requête est envoyée avec le premier paquet, sans aucune attente préalable.
La valeur d’un aller-retour dépend de la latence. Sur la fibre avec un serveur proche, un aller-retour peut durer moins de 10 millisecondes, et en économiser un est presque sans importance. Sur un réseau mobile, où la latence se situe souvent entre 50 et 150 millisecondes et peut monter bien plus haut avec un signal faible, chaque aller-retour économisé se traduit directement par un TTFB plus bas sur la première requête. Et comme le LCP part du TTFB, le gain se propage à toute la page.
Il faut préciser que la reprise 0-RTT a une limite de sécurité : les données envoyées dans le premier paquet pourraient être rejouées par un attaquant qui les aurait interceptées. Pour cette raison, elle n’est utilisée que pour des requêtes sans effets de bord, comme le chargement d’une page, et les serveurs la refusent pour les opérations qui modifient des données. C’est un choix géré par les serveurs et les CDN, mais il est utile de le connaître pour comprendre pourquoi l’avantage du 0-RTT ne s’applique pas à tout.
Deuxième avantage : pas de blocage en chaîne
La limite la plus importante de HTTP/2 apparaît quand le réseau perd des paquets, ce qui est normal sur les réseaux mobiles et le Wi-Fi encombré. TCP garantit que les données parviennent à l’application exactement dans l’ordre où elles ont été envoyées : si un paquet est perdu, tous ceux arrivés après attendent que le paquet manquant soit retransmis. Avec HTTP/2, où le HTML, le CSS, les images et les scripts partagent la même connexion TCP, la perte d’un seul paquet de CSS bloque aussi le HTML et les images, bien qu’ils soient arrivés intacts. C’est le fameux head-of-line blocking.
QUIC résout le problème en gérant l’ordre flux par flux. Si un paquet de CSS est perdu, seul le CSS attend ; le HTML et les images continuent d’arriver et d’être traités. Sur un réseau stable, la différence est minime, mais avec un taux de perte de paquets ne serait-ce que d’un ou deux pour cent, courant sur mobile, l’écart des temps de chargement devient mesurable, surtout dans la partie haute de la distribution : les pires chargements s’améliorent plus que les chargements moyens. Et c’est précisément la partie haute de la distribution qui compte pour les Core Web Vitals, évalués au 75e percentile.
Troisième avantage : le changement de réseau
Une connexion TCP est identifiée par l’adresse et le port des deux parties. Quand un smartphone passe du Wi-Fi au réseau mobile, par exemple en quittant la maison ou un magasin, son adresse change et toutes les connexions TCP se rompent : il faut les rouvrir de zéro, avec tous les allers-retours que cela implique. QUIC identifie la connexion avec son propre identifiant, indépendant de l’adresse, et peut donc continuer sur le nouveau réseau sans repartir du début. Pour ceux qui naviguent en déplacement, c’est un avantage concret, même s’il est difficile à voir dans les tests de laboratoire.
Comment le navigateur découvre HTTP/3
Un navigateur ne sait pas à l’avance si un serveur prend en charge HTTP/3. Dans le cas le plus courant, la première connexion utilise HTTP/2, et le serveur annonce la prise en charge de HTTP/3 avec l’en-tête Alt-Svc :
alt-svc: h3=":443"; ma=86400Le navigateur mémorise l’information et, dès les requêtes suivantes ou à la visite suivante, utilise HTTP/3. Cela signifie que la toute première visite d’un utilisateur n’en profite souvent pas. Pour supprimer cette étape, il existe le type d’enregistrement DNS HTTPS, qui annonce les protocoles pris en charge dès la résolution du nom : le navigateur peut ainsi utiliser HTTP/3 dès la toute première connexion. Les principaux CDN le publient automatiquement quand HTTP/3 est activé.
Il existe aussi un mécanisme de sécurité : QUIC utilise UDP, et certains réseaux d’entreprise, d’hôtel ou publics bloquent ou limitent le trafic UDP sur le port 443. Dans ce cas, le navigateur bascule automatiquement sur HTTP/2 via TCP, sans erreur pour l’utilisateur. HTTP/3 est donc une amélioration qui s’ajoute, pas un remplacement susceptible de casser quelque chose.
Comment l’activer
Le plus simple est de passer par un CDN ou un proxy qui le prend en charge : Cloudflare, Fastly, Akamai, Amazon CloudFront et bien d’autres proposent HTTP/3 aux utilisateurs, souvent avec une option à activer dans le tableau de bord. Dans ce cas, la connexion HTTP/3 couvre le tronçon entre l’utilisateur et le nœud du CDN, qui est précisément celui qui a la latence et les pertes les plus élevées ; le tronçon entre le CDN et le serveur d’origine continue d’utiliser HTTP/1.1 ou HTTP/2, sur des réseaux de bien meilleure qualité. C’est aussi l’un des avantages concrets d’un CDN qu’il vaut la peine de distinguer des autres fonctionnalités, comme nous l’avons vu en parlant de Cloudflare.
Côté serveur, la prise en charge dépend du logiciel. LiteSpeed la gère en natif depuis des années, et c’est l’une des raisons pour lesquelles il apparaît souvent dans les comparatifs de performance, comme nous l’avons vu dans quand le benchmark voit un autre site. Nginx l’inclut dans les versions récentes, avec un module dédié à activer à la compilation et dans la configuration ; Caddy l’active par défaut ; Apache n’a pas de prise en charge native et nécessite un proxy en amont. Dans tous les cas, il faut ouvrir le port UDP 443 dans le pare-feu, un détail souvent oublié qui rend HTTP/3 annoncé mais inaccessible.
server {
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
http3 on;
# Annoncer HTTP/3 aux navigateurs
add_header Alt-Svc 'h3=":443"; ma=86400' always;
}Un aspect à considérer est la consommation de ressources. QUIC est implémenté dans l’espace utilisateur plutôt que dans le noyau du système d’exploitation, et chiffrer chaque paquet a un coût : à trafic égal, un serveur HTTP/3 utilise en général plus de CPU qu’un serveur HTTP/2. Pour les CDN, ce n’est pas un problème ; pour un petit serveur mutualisé, cela peut l’être. C’est l’une des raisons pour lesquelles, sur beaucoup d’infrastructures, laisser HTTP/3 à la couche CDN est le choix le plus judicieux.
Comment vérifier que ça fonctionne
Dans le panneau Réseau des DevTools de Chrome, on peut ajouter la colonne Protocole : les ressources servies en HTTP/3 affichent h3, celles en HTTP/2 affichent h2. À la première visite, il est normal de voir h2 sur le document et h3 sur les ressources suivantes, à cause du mécanisme de découverte. En ligne de commande, les versions récentes de curl compilées avec la prise en charge de HTTP/3 permettent de le forcer avec l’option --http3, utile pour distinguer un problème de configuration du serveur d’un blocage réseau.
Sur les utilisateurs réels, les API Navigation Timing et Resource Timing exposent la propriété nextHopProtocol, qui indique le protocole utilisé pour chaque requête. Collectée dans un système de monitoring avec les métriques, elle permet de savoir quelle part des visites utilise réellement HTTP/3 et de comparer le TTFB et le LCP entre les deux populations. Le Chrome UX Report ne ventile pas les données par protocole ; l’effet sur les données de terrain se voit donc surtout comme une amélioration générale du TTFB sur mobile après l’activation.
const nav = performance.getEntriesByType( 'navigation' )[ 0 ];
console.log( nav.nextHopProtocol ); // "h3", "h2" ou "http/1.1"Ce qu’il faut vraiment en attendre
HTTP/3 ne transforme pas un site lent en site rapide. Si le serveur met une seconde à générer la page parce qu’il n’y a pas de cache, économiser une centaine de millisecondes de connexion change peu de chose ; si la page télécharge trois mégaoctets de JavaScript, le protocole ne les rendra pas plus légers. Les bénéfices s’ajoutent à un site déjà bien optimisé et se concentrent là où le réseau est le goulot d’étranglement : utilisateurs mobiles, réseaux à forte latence, connexions instables, visiteurs éloignés du serveur.
Pour cette raison même, ce sont pourtant des bénéfices qui comptent pour les Core Web Vitals. Les données de terrain sont dominées par le mobile, et le 75e percentile est constitué des utilisateurs dans les pires conditions : ceux qui ont un signal faible, en déplacement, sur des réseaux encombrés. Ce sont exactement les utilisateurs pour lesquels HTTP/3 fait la plus grande différence, et c’est pourquoi, toutes choses égales par ailleurs, l’activer tend à améliorer la queue de la distribution plus que la moyenne.
C’est aussi pourquoi les bénéfices de HTTP/3 se voient peu dans les tests de laboratoire. Lighthouse et PageSpeed Insights simulent un réseau lent en appliquant un ralentissement calculé, mais ils ne reproduisent ni la perte de paquets ni les changements de réseau, et la première visite du test se fait souvent encore en HTTP/2. Des outils comme WebPageTest permettent de choisir des profils réseau plus réalistes, mais l’image fiable reste celle des données de terrain, comme nous l’avons vu en parlant de pourquoi il faut à la fois CrUX et les données de laboratoire.
En résumé
HTTP/3 déplace les requêtes web sur QUIC, un transport fondé sur UDP avec chiffrement intégré. Par rapport à HTTP/2 sur TCP, il réduit les allers-retours nécessaires pour ouvrir une connexion, élimine le blocage en chaîne en cas de perte de paquets et maintient les connexions en vie lors du passage d’un réseau à un autre. Ce sont des avantages modestes sur un réseau fixe rapide et significatifs sur les réseaux mobiles, où se mesurent les Core Web Vitals les plus critiques.
L’activer est simple avec un CDN, possible avec les serveurs web modernes à condition de penser à ouvrir le port UDP 443, et sûr grâce au repli automatique sur HTTP/2 là où UDP est bloqué. On le vérifie avec la colonne Protocole des DevTools et on le mesure sur les utilisateurs réels avec nextHopProtocol. Il ne remplace ni le cache, ni les images optimisées, ni un JavaScript léger, mais il complète le travail à l’endroit qu’aucune autre optimisation ne peut atteindre : le trajet des données entre le serveur et le téléphone de l’utilisateur.
