HTTP/3 n’est plus une curiosité de laboratoire depuis quelques années : les grands navigateurs le supportent nativement, les principaux CDN l’activent par défaut, et nginx l’intègre désormais directement dans ses versions mainline sans nécessiter de module tiers compilé à la main. Après l’avoir activé progressivement sur plusieurs sites WordPress de notre parc, ce bilan tente de séparer ce qui relève d’un vrai gain mesuré de ce qui reste, pour l’instant, une promesse marketing.
La différence fondamentale avec les versions précédentes du protocole HTTP tient au transport sous-jacent : HTTP/1.1 et HTTP/2 s’appuient sur TCP, tandis que HTTP/3 repose sur QUIC, un protocole construit sur UDP qui résout un problème précis de TCP, le blocage de tête de ligne (head-of-line blocking), particulièrement pénalisant sur des connexions mobiles instables.
Ce que QUIC résout concrètement
Sur une connexion TCP classique, si un seul paquet se perd en chemin, l’ensemble des données qui le suivent doit attendre sa retransmission avant d’être traité, même si elles concernent des ressources totalement indépendantes (une image et une feuille de style, par exemple). QUIC multiplexe les flux de façon plus fine, ce qui permet à une ressource de continuer à progresser même si une autre attend un paquet perdu. Sur un réseau fixe stable, ce gain reste marginal. Sur un réseau mobile en 4G dégradée ou en changement de cellule, l’écart devient nettement plus perceptible.
Activer HTTP/3 sous nginx
Depuis les versions mainline récentes, le support HTTP/3 est inclus par défaut, sans compilation personnalisée nécessaire sur la plupart des distributions à jour. La configuration ajoute une écoute QUIC en complément de l’écoute TLS classique :
server {
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
http3 on;
add_header Alt-Svc 'h3=":443"; ma=86400';
server_name exemple.fr;
ssl_certificate /etc/letsencrypt/live/exemple.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/exemple.fr/privkey.pem;
}
L’en-tête Alt-Svc est essentiel : c’est lui qui annonce aux navigateurs compatibles que le site propose HTTP/3, leur permettant de basculer sur les visites suivantes sans devoir le redécouvrir à chaque fois.
Ce que nos mesures montrent
Sur nos sites à trafic majoritairement mobile, le temps jusqu’au premier octet (Time To First Byte) a montré une amélioration mesurable mais modeste, de l’ordre de quelques dizaines de millisecondes en moyenne, plus marquée sur les connexions les plus dégradées que sur les connexions fixes déjà rapides. Sur des sites à trafic majoritairement desktop et fixe, l’écart observé est resté proche du bruit de mesure, sans gain clairement attribuable.
| Profil de trafic | Gain observé |
|---|---|
| Mobile, réseau instable | Perceptible et mesurable |
| Mobile, bonne couverture | Léger |
| Desktop, connexion fixe | Négligeable |
Les précautions avant activation
- Vérifier que le pare-feu du serveur autorise le trafic UDP sur le port 443, souvent négligé car historiquement réservé au TCP.
- Confirmer que les extensions de cache ou de sécurité en périphérie (WAF, CDN) supportent correctement HTTP/3, sous peine d’incohérence de comportement.
- Garder HTTP/2 actif en parallèle : tous les visiteurs ne disposent pas d’un navigateur ou d’un réseau compatible avec HTTP/3.
HTTP/3 n’est pas une baguette magique de performance : c’est une optimisation ciblée pour un profil de trafic précis. L’activer sans mesurer son propre trafic revient à optimiser pour un visiteur théorique plutôt que pour ses visiteurs réels.
Notre verdict
Activer HTTP/3 sous nginx pour un site WordPress ne présente aucun risque une fois les prérequis réseau vérifiés, et le coût de mise en place est désormais faible grâce à son intégration native dans les versions récentes de nginx. Le gain réel dépend directement du profil de trafic du site : significatif pour une audience majoritairement mobile sur réseau instable, marginal pour une audience desktop déjà bien servie par HTTP/2.
