Le protocole HTTP est la langue que parlent les navigateurs et les serveurs web. Il définit comment une requête est formulée, comment une réponse est structurée, et surtout comment les données circulent entre les deux. Trois versions coexistent aujourd’hui sur le web : HTTP/1.1, publié en 1997, HTTP/2 en 2015, et HTTP/3 en 2022. Elles répondent toutes à la même question, mais avec des mécaniques de transport radicalement différentes.
Cette évolution n’a rien d’anecdotique pour la performance d’un site. Chaque génération a été conçue pour supprimer un goulot d’étranglement que la précédente laissait ouvert, et chacune rend caduques certaines optimisations qui étaient pourtant considérées comme des bonnes pratiques dix ans plus tôt. Concaténer tous ses fichiers JavaScript ou répartir ses images sur plusieurs sous-domaines sont deux exemples de techniques devenues au mieux inutiles, au pire contre-productives.
S’ajoute à cela une confusion très répandue, y compris dans les contenus techniques : QUIC et HTTP/3 sont régulièrement présentés comme deux noms d’une même chose. Ce sont deux protocoles distincts, à deux étages différents de la pile réseau, et cette distinction n’est pas un détail de vocabulaire. Alors que change réellement chaque version pour la vitesse d’un site, et faut-il activer HTTP/3 aujourd’hui ?
Qu’est-ce que le protocole HTTP et comment fonctionne-t-il ?
HTTP signifie HyperText Transfer Protocol, protocole de transfert hypertexte en français. C’est un protocole de couche applicative qui définit un échange requête-réponse : le client demande une ressource par une méthode et une URL, le serveur répond par un code de statut, des en-têtes et éventuellement un corps. HTTP est sans état par conception, ce qui signifie qu’il ne conserve aucune mémoire d’une requête à l’autre.
Le protocole ne transporte pas lui-même les octets sur le réseau. Il s’appuie pour cela sur un protocole de transport, historiquement TCP, qui garantit que les données arrivent complètes et dans l’ordre. C’est précisément à cette frontière entre l’applicatif et le transport que se joue toute l’histoire des trois versions, comme le détaille la chronologie du protocole publiée par MDN.
Quelle est la différence entre HTTP et HTTPS ?
HTTPS n’est pas une version du protocole HTTP, c’est HTTP transporté dans un canal chiffré par TLS. La sémantique reste identique : mêmes méthodes, mêmes codes de statut, mêmes en-têtes. Seule change la confidentialité du transport, et c’est aussi ce qui explique le passage du port 80 au port 443.
La question a perdu de sa pertinence avec les versions récentes, et c’est un point que beaucoup de contenus omettent. Aucun navigateur n’implémente HTTP/2 en clair : le chiffrement est imposé de fait. Avec HTTP/3, ce n’est même plus une question de politique des navigateurs, puisque TLS 1.3 est intégré au protocole de transport lui-même. Un HTTP/3 non chiffré n’existe pas.
Quels problèmes HTTP/1.1 laissait-il ouverts ?
HTTP/1.1, normalisé en 1997 et aujourd’hui décrit par la RFC 9112, a introduit les connexions persistantes : une même connexion TCP peut servir plusieurs requêtes successives, au lieu d’en rouvrir une à chaque fichier. Le gain fut considérable, mais le protocole a conservé une limite structurelle lourde de conséquences.
Sur une connexion HTTP/1.1, les requêtes sont traitées strictement les unes après les autres. Une ressource lente bloque toutes celles qui la suivent dans la file, quel que soit leur poids réel. Une feuille de style de 3 Ko peut attendre la fin du téléchargement d’une image de 2 Mo simplement parce qu’elle a été demandée après elle. C’est le blocage en tête de file, au niveau applicatif.
Les navigateurs ont contourné le problème en ouvrant plusieurs connexions en parallèle vers un même domaine, généralement six, comme le rappelle la documentation MDN sur la gestion des connexions. Six files au lieu d’une, donc, mais chaque connexion supplémentaire coûte une poignée de main TCP et TLS complète, et six reste un chiffre dérisoire face aux dizaines de ressources d’une page moderne.
Toute une génération de bonnes pratiques est née de cette contrainte, et c’est ce qui rend le sujet concret pour qui gère un site aujourd’hui.
Qu’apporte réellement HTTP/2 en performance ?
HTTP/2, publié en 2015 et redéfini depuis par la RFC 9113 en juin 2022, apporte le multiplexage : une seule connexion TCP transporte toutes les requêtes en parallèle, découpées en trames et réassemblées à l’arrivée. La file d’attente applicative disparaît, et avec elle la nécessité d’ouvrir six connexions par domaine.
Le protocole change aussi de nature dans sa représentation. Là où HTTP/1.1 transmettait du texte lisible, HTTP/2 est binaire, ce qui le rend plus compact à analyser et moins sujet aux ambiguïtés d’interprétation. Les en-têtes, qui se répètent massivement d’une requête à l’autre, sont compressés par l’algorithme HPACK défini par la RFC 7541.
Le mécanisme est efficace, et l’adoption le confirme. D’après le chapitre HTTP du Web Almanac 2024 de HTTP Archive, 71 % des pages d’accueil desktop étaient servies en HTTP/2 et 22 % seulement encore en HTTP/1.1, contre 34 % en 2022. À l’échelle de la requête, 85 % du trafic passait par HTTP/2 ou mieux.
Ce que HTTP/2 n’apporte pas
Une part du malentendu autour de HTTP/2 vient de ce qu’on lui prête. Le multiplexage résout un problème de file d’attente, pas un problème de lenteur, et cette nuance décide de ce qu’il faut optimiser ensuite. HTTP/2 ne réduit pas d’un octet le poids des ressources qu’il transporte.
Trois choses en particulier restent entièrement à votre charge après une migration.
- La compression de la charge utile, qui relève de gzip, Brotli ou Zstandard selon les cas, et n’a rien à voir avec la compression d’en-têtes HPACK ;
- Le cache navigateur et le cache serveur, qui restent le seul moyen de ne pas transférer une ressource du tout ;
- Le temps de réponse du serveur, qu’un protocole plus efficace ne compense jamais : si l’application met 800 ms à produire le document, HTTP/2 les attendra aussi patiemment que HTTP/1.1.
Le multiplexage supprime la file, il ne raccourcit pas ce qui se trouve dedans. Un site dont le TTFB est mauvais restera lent en HTTP/2, en HTTP/3, et dans toutes les versions à venir : c’est un problème de délai de première réponse, pas de protocole.
Le server push de HTTP/2 est-il encore utilisable ?
Non, le server push est mort et il ne faut plus le déployer. Google l’a désactivé par défaut à partir de Chrome 106, en septembre 2022, suivi par les autres navigateurs Chromium. L’équipe Chrome a justifié ce retrait par des résultats mitigés, sans gain net démontré et avec des régressions de performance fréquentes, pour une fonctionnalité utilisée par 1,25 % seulement des sites en HTTP/2.
Le principe était pourtant séduisant : envoyer au navigateur des ressources qu’il n’avait pas encore demandées, en anticipant ses besoins. Le défaut structurel est que le serveur ignore ce que le navigateur possède déjà en cache, et pousse donc régulièrement des fichiers déjà présents, consommant de la bande passante pour rien au moment précis où elle est la plus précieuse.
Son successeur fonctionne à l’inverse, en laissant la décision au navigateur. Le code 103 Early Hints envoie de simples suggestions de préchargement avant la réponse finale, et le client choisit s’il les suit. L’adoption reste toutefois marginale : le Web Almanac 2024 relève 2,9 % de pages desktop concernées, dont 90 % attribuables à un seul hébergeur de commerce en ligne.
Qu’est-ce que le blocage en tête de file et comment HTTP/3 le résout-il ?
Le blocage en tête de file désigne la situation où un élément bloqué en début de file immobilise tous ceux qui le suivent, même s’ils sont prêts. HTTP/2 l’a supprimé au niveau applicatif grâce au multiplexage, mais il l’a laissé intact au niveau transport, et c’est exactement le problème que HTTP/3 vient corriger.
La raison tient à la nature même de TCP. Ce protocole présente aux couches supérieures un flux d’octets unique et strictement ordonné : si un paquet se perd, TCP retient tous les paquets suivants jusqu’à ce que le manquant soit retransmis. Peu importe que ces paquets appartiennent à d’autres ressources, entièrement reçues et prêtes à être traitées.
Le résultat est contre-intuitif. En HTTP/2, une seule connexion transporte tout, donc un unique paquet perdu fige simultanément l’ensemble des flux : la feuille de style, le script, les images, tout attend. En HTTP/1.1, avec ses six connexions séparées, une perte n’aurait pénalisé qu’une file sur six. Sur un réseau très dégradé, HTTP/2 peut donc se révéler moins bon que son prédécesseur.
QUIC résout ce point en gérant lui-même le découpage en flux et la retransmission, flux par flux. Une perte affectant le script ne retarde que le script, pendant que la feuille de style et les images continuent d’être livrées. Le blocage devient local au lieu d’être global.
Qu’est-ce que le protocole QUIC ?
QUIC est un protocole de transport, normalisé par la RFC 9000 publiée en mai 2021. Il se substitue à TCP, pas à HTTP. HTTP/3, défini par la RFC 9114 en juin 2022, est le protocole applicatif qui s’appuie dessus. QUIC est le camion, HTTP/3 est ce qu’on met dedans, et confondre les deux revient à confondre TCP et HTTP/2.
Cette distinction n’est pas cosmétique. QUIC peut transporter autre chose que HTTP/3, et c’est déjà le cas dans plusieurs protocoles. Inversement, dire d’un site qu’il est en QUIC sans préciser HTTP/3 laisse la question de la couche applicative entièrement ouverte.
Pourquoi QUIC fonctionne-t-il sur UDP ?
QUIC s’appuie sur UDP parce que TCP est implémenté dans le noyau des systèmes d’exploitation et dans les équipements réseau intermédiaires. Modifier son comportement supposerait de mettre à jour des milliards de machines, box, pare-feu et routeurs compris, ce qui rend toute évolution profonde irréalisable en pratique.
UDP offre la porte de sortie. C’est un protocole minimal, qui se contente d’envoyer des datagrammes sans garantie d’ordre ni de livraison, et qui est déjà accepté partout. QUIC réimplémente au-dessus, en espace utilisateur, tout ce que TCP apportait : accusés de réception, retransmission, contrôle de congestion. La différence est qu’il le fait avec la notion de flux indépendants intégrée dès la conception.
Le choix a une conséquence pratique décisive : les évolutions de QUIC se déploient par simple mise à jour du navigateur et du serveur, sans toucher au système. Ce que TCP a mis vingt ans à ne pas faire, QUIC peut le faire en un cycle de version.
Combien d’allers-retours QUIC économise-t-il à l’ouverture ?
QUIC établit une connexion en un seul aller-retour, contre deux pour la combinaison TCP plus TLS 1.3, et trois avec les versions antérieures de TLS. Le gain vient de la fusion : là où TCP négocie d’abord le transport puis laisse TLS négocier le chiffrement par-dessus, QUIC traite les deux dans le même échange, puisque TLS 1.3 fait partie du protocole.
La reprise de session va plus loin encore avec le mode 0-RTT, qui permet d’envoyer la requête dès le tout premier paquet lorsque le client a déjà parlé au serveur récemment. L’établissement ne coûte alors plus aucun aller-retour du tout, ce qui est le maximum théorique atteignable.
Ce mode appelle toutefois une réserve que les contenus promotionnels passent volontiers sous silence : les données envoyées en 0-RTT sont vulnérables au rejeu, un attaquant pouvant les capturer et les renvoyer. La RFC 9000 impose donc de le réserver aux requêtes idempotentes, ce qui exclut les paiements, les envois de formulaire et toute opération qui modifie un état.
À quoi sert la migration de connexion de QUIC ?
La migration de connexion permet de changer de réseau sans rompre la session en cours. Une connexion TCP est identifiée par le quadruplet adresse IP source, port source, adresse IP destination, port destination : dès que l’adresse IP change, la connexion est morte et tout doit être rétabli de zéro.
QUIC identifie la connexion par un identifiant propre, indépendant de l’adresse IP. Passer du Wi-Fi à la 5G en sortant de chez soi, ou changer d’antenne dans un train, ne rompt donc rien : la session reprend sur la nouvelle adresse sans nouvelle poignée de main. Le glossaire MDN en fait l’un des apports structurants du protocole.
L’enjeu est directement mobile, et c’est un bon indicateur des situations où HTTP/3 apporte réellement quelque chose. Sur un poste fixe relié en fibre, cette fonctionnalité ne servira jamais.
HTTP/3 est-il vraiment plus rapide que HTTP/2 ?
Cela dépend du réseau, et répondre autrement serait malhonnête. Le gain de HTTP/3 est maximal sur réseau mobile dégradé, avec de la perte de paquets, de la latence élevée et des changements de point d’accès. Sur une connexion fibre stable en conditions de laboratoire, l’écart avec HTTP/2 est faible, parfois indétectable.
La raison est mécanique. Les deux principaux avantages de QUIC, la suppression du blocage transport et la migration de connexion, ne se manifestent que lorsque le réseau pose problème. Sans perte de paquets, le blocage en tête de file de TCP ne se déclenche jamais, et il n’y a donc rien à supprimer.
Reste l’aller-retour économisé à l’établissement, qui se paie sur toutes les connexions et se voit directement sur le premier octet. Sur une latence de 40 ms, cela représente 40 ms de moins avant le début de la réponse. Ce n’est pas énorme, mais c’est réel, mesurable, et cela ne coûte rien une fois le protocole activé.
La conclusion pratique tient en une phrase : plus l’audience d’un site est mobile et géographiquement dispersée, plus HTTP/3 lui rapporte. Un service consulté depuis des smartphones en déplacement en tirera un bénéfice net, une application interne consultée depuis des postes câblés n’y gagnera presque rien.
Quelle est la différence entre HTTP/1.1, HTTP/2 et HTTP/3 ?
Les trois versions se distinguent moins par ce qu’elles transportent que par la façon dont elles le transportent. La sémantique du protocole, méthodes, codes de statut et en-têtes, est restée identique depuis 1997 et vaut pour les trois : elle est décrite à part, dans la RFC 9110. Ce qui change, c’est la couche en dessous.
| Critère | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Année et norme | 1997, RFC 9112 | 2015, RFC 9113 | 2022, RFC 9114 |
| Transport | TCP | TCP | QUIC sur UDP |
| Format | Texte | Binaire | Binaire |
| Requêtes en parallèle | Non, une file par connexion | Oui, multiplexées sur une connexion | Oui, sur des flux réellement indépendants |
| Connexions par domaine | 6 en pratique | 1 | 1 |
| Blocage en tête de file | Applicatif et transport | Transport seulement | Aucun des deux |
| Compression des en-têtes | Aucune | HPACK | QPACK |
| Chiffrement | Optionnel | Imposé de fait par les navigateurs | Intégré au protocole, TLS 1.3 |
| Allers-retours à l’ouverture | 2 à 3 | 2 à 3 | 1, ou 0 en reprise |
| Changement de réseau | Connexion rompue | Connexion rompue | Migration transparente |
Deux lignes de ce tableau méritent une lecture attentive parce qu’elles sont la source de la plupart des malentendus. Le passage de six connexions à une seule est un progrès net en HTTP/2, mais c’est aussi ce qui concentre le risque : toutes les ressources dépendent désormais d’un seul canal TCP, dont la moindre perte de paquet fige l’ensemble.
La ligne du chiffrement, elle, résume le changement de philosophie. En HTTP/1.1, TLS était une couche que l’on ajoutait par-dessus le transport. En HTTP/3, il n’y a plus de couche à ajouter ni d’option à activer, la sécurité fait partie du transport lui-même. Ces distinctions figurent aussi, sous forme d’entrées courtes, dans notre glossaire des termes de la web performance.
Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Quelles optimisations HTTP/1.1 sont devenues inutiles ?
Une bonne partie des techniques enseignées avant 2015 visait à contourner la limite des six connexions par domaine. Ces contournements avaient un coût qu’on acceptait parce que le gain était supérieur. Le multiplexage a inversé ce rapport, et plusieurs d’entre eux sont désormais nuisibles.
Quatre pratiques méritent d’être réexaminées sur tout site qui traîne un héritage technique.
- La concaténation à outrance : regrouper tous les scripts dans un seul fichier réduisait le nombre de requêtes, donc l’attente en file. En HTTP/2, les requêtes ne s’attendent plus, et le gros fichier unique invalide tout le cache dès qu’une seule ligne change ;
- Les sprites CSS : agréger des dizaines d’icônes dans une image unique répondait au même besoin. Le procédé impose aujourd’hui de télécharger l’ensemble pour afficher une icône, et se remplace avantageusement par des fichiers SVG servis séparément ;
- Le sharding de domaines : répartir les ressources sur plusieurs sous-domaines multipliait le quota de six connexions. En HTTP/2, chaque domaine supplémentaire force une résolution DNS, une connexion et une négociation TLS de plus, et casse le multiplexage en fragmentant ce qui aurait tenu sur une seule connexion ;
- L’inlining systématique : intégrer le CSS et les images en base64 dans le HTML supprimait des requêtes, mais gonfle le document, le rend non cachable indépendamment, et pénalise chaque visite suivante.
Aucune de ces techniques n’est absurde dans l’absolu, et c’est ce qui rend leur réexamen délicat. Un regroupement raisonnable de petits fichiers reste pertinent, l’inlining d’un CSS critique très réduit garde du sens. Ce qui a changé, c’est que la version extrême de chacune de ces pratiques est passée du statut d’optimisation à celui de dette technique.
Le sharding est le cas le plus net, parce qu’il est le seul dont le retournement est complet : il aidait franchement en HTTP/1.1, il nuit franchement en HTTP/2 et HTTP/3. C’est l’un des motifs que nous cherchons systématiquement lors d’un audit de performance sur un site ancien.
Comment savoir si mon site utilise HTTP/2 ou HTTP/3 ?
La méthode la plus directe passe par l’onglet Réseau des outils de développement du navigateur, où une colonne Protocole affiche la version utilisée par chaque ressource. Elle n’est pas visible par défaut : il faut faire un clic droit sur la ligne d’en-têtes du tableau et la cocher. Les valeurs sont http/1.1, h2 et h3.
En ligne de commande, curl donne la réponse de façon non ambiguë, à condition de disposer d’une version compilée avec le support HTTP/3, ce qui n’est pas le cas de toutes les distributions.
# Version négociée par défaut
$ curl -sI https://exemple.fr/ -o /dev/null -w '%{http_version}\n'
2
# Forcer HTTP/3 pour vérifier qu'il répond
$ curl --http3 -sI https://exemple.fr/ -o /dev/null -w '%{http_version}\n'
3
# L'annonce Alt-Svc dans les en-têtes
$ curl -sI https://exemple.fr/ | grep -i alt-svc
alt-svc: h3=":443"; ma=86400Un piège attend toutefois quiconque conclut trop vite, et il explique la majorité des faux négatifs. Le navigateur ne tente pas HTTP/3 sur une première connexion vers un domaine inconnu : il doit d’abord apprendre que le serveur le supporte. Une absence de h3 dans l’onglet Réseau ne prouve donc rien à elle seule.
Comment le navigateur découvre-t-il le support de HTTP/3 ?
Deux mécanismes existent, et le plus répandu impose un détour. L’en-tête de réponse Alt-Svc permet au serveur d’annoncer, pendant une connexion en HTTP/2 ou HTTP/1.1, qu’il est également joignable en HTTP/3. Le navigateur mémorise l’information pour la durée indiquée par le paramètre ma, et bascule à la visite suivante.
Le second mécanisme, plus récent, contourne ce détour en plaçant l’information dans le DNS. L’enregistrement de type HTTPS, défini par la RFC 9460, publie la liste des protocoles supportés sous forme d’un attribut alpn. La résolution DNS ayant lieu avant toute connexion, le navigateur peut ouvrir directement en HTTP/3.
$ dig +short HTTPS exemple.fr
1 . alpn="h3,h2" ipv4hint=203.0.113.10
Cet écart entre support réel et usage constaté est massif, et il fausse toutes les statistiques d’adoption. Le Web Almanac 2024 mesure 7 % de pages desktop effectivement chargées en HTTP/3, alors que 26 % des pages desktop et 28 % des mobiles annoncent le supporter via Alt-Svc. La différence n’est pas une erreur de mesure, c’est le mécanisme de découverte lui-même.
Comment activer HTTP/2 et HTTP/3 sur son serveur ?
Le cas le plus fréquent ne demande aucune intervention sur le serveur d’origine. Quand un CDN ou un reverse proxy assure la terminaison TLS, HTTP/3 s’active d’un seul réglage dans son interface, et le serveur derrière n’a rien à savoir de tout cela. Le Web Almanac est explicite sur ce point : entre 85 % et 86 % des requêtes en HTTP/3 proviennent d’un CDN.
C’est à la fois bon et mauvais pour l’écosystème, selon moi. Bon, parce qu’ils éprouvent rapidement les nouvelles technologies et leur donnent d’emblée une part de marché considérable. Mauvais, parce que cela centralise toujours plus le web autour de quelques grandes entreprises, avec le risque de laisser de côté ceux qui ne les utilisent pas.
Robin Marx, auteur du chapitre HTTP du Web Almanac 2024 de HTTP Archive, à propos du rôle moteur des CDN dans l’adoption de HTTP/3, novembre 2024
Un point mérite d’être compris pour éviter les fausses attentes. Le protocole entre le visiteur et le CDN, et celui entre le CDN et le serveur d’origine, sont deux liens distincts. Activer HTTP/3 côté public n’implique pas que la liaison vers l’origine en bénéficie : elle reste très souvent en HTTP/1.1 ou HTTP/2, ce qui est acceptable puisque ce lien est généralement court, stable et sans perte de paquets. C’est l’un des arbitrages que nous détaillons dans notre analyse des avantages et limites d’un CDN.
Sur un serveur autogéré, la configuration reste simple. Nginx prend en charge HTTP/3 depuis la version 1.25.0, à condition que le binaire ait été compilé avec le module correspondant, ce qui n’est pas le cas par défaut. La directive listen reçoit alors le paramètre quic, et l’annonce Alt-Svc doit être ajoutée explicitement.
server {
# HTTP/2 sur TCP, port 443
listen 443 ssl;
http2 on;
# HTTP/3 sur QUIC, port 443 en UDP
listen 443 quic reuseport;
ssl_certificate /etc/ssl/exemple.fr.crt;
ssl_certificate_key /etc/ssl/exemple.fr.key;
ssl_protocols TLSv1.2 TLSv1.3;
# Sans cette annonce, aucun navigateur ne basculera en HTTP/3
add_header Alt-Svc 'h3=":443"; ma=86400' always;
}Deux vérifications s’imposent avant de considérer l’activation comme faite, et elles sont la cause de la plupart des activations qui ne produisent aucun effet. Le port 443 doit être ouvert en UDP autant qu’en TCP sur le pare-feu, faute de quoi le serveur écoute dans le vide. L’en-tête Alt-Svc doit être réellement émis, ce qu’un simple curl -sI confirme en une seconde.
Du côté d’Apache, le module mod_http2 couvre HTTP/2 depuis la version 2.4.17, et sa documentation officielle détaille l’activation. Le support de HTTP/3 y reste en revanche nettement moins avancé que chez Nginx, ce qui pousse en pratique vers la terminaison par un CDN ou un proxy en frontal.
HTTP/3 fonctionne-t-il derrière tous les pare-feu ?
Non, et c’est la principale limite pratique du protocole. HTTP/3 circule sur le port 443 en UDP, alors que la plupart des politiques de sécurité d’entreprise ont été écrites à une époque où seul le trafic TCP sur ce port avait une raison d’exister. Le blocage de l’UDP sortant, hors DNS, y reste une règle courante.
Le risque est heureusement contenu par la conception du protocole. Quand la tentative en QUIC échoue, le navigateur retombe sur HTTP/2 en TCP sans que l’utilisateur s’en aperçoive. Un site en HTTP/3 reste donc accessible partout : on perd le bénéfice, pas le service. Le Web Almanac note d’ailleurs que les sites annoncent un peu mieux HTTP/3 côté mobile que côté desktop, précisément parce que les environnements d’entreprise le bloquent.
Reste un inconvénient plus insidieux, du côté du diagnostic. Une partie de l’outillage réseau habituel connaît mal QUIC : le trafic étant chiffré de bout en bout, y compris les métadonnées de transport que TCP laissait en clair, les analyseurs de paquets classiques n’y voient plus grand-chose. C’est un progrès pour la confidentialité et une complication réelle pour le débogage.
Faut-il migrer vers HTTP/3 en 2026 ?
Oui si l’activation ne coûte qu’un réglage chez votre CDN, ce qui est le cas le plus courant : le gain est modeste mais réel, le risque est nul grâce au repli automatique, et l’audience mobile en profite immédiatement. Il n’existe aucun argument sérieux pour s’en priver dans cette configuration.
La réponse change dès que la migration suppose de recompiler Nginx, de modifier des règles de pare-feu et de revoir une chaîne de supervision. L’effort devient significatif pour un gain qui, sur une audience majoritairement desktop et bien connectée, se mesure difficilement. Dans ce cas, la question honnête est de savoir ce que le même temps rapporterait ailleurs.
Et la réponse est presque toujours : beaucoup plus. Un TTFB ramené de 900 à 200 ms, des images correctement dimensionnées, un cache correctement configuré ou du JavaScript tiers maîtrisé pèsent chacun bien davantage qu’un aller-retour de connexion économisé. Le protocole est une optimisation de dernier kilomètre, pas un levier de premier plan.
Le cas de HTTP/2 est en revanche tranché sans nuance. Un site encore servi en HTTP/1.1 en 2026 laisse un gain substantiel sur la table, et la migration est aujourd’hui triviale sur toutes les piles courantes. Les 22 % de pages relevées par le Web Almanac dans cette situation sont, pour l’essentiel, des configurations oubliées plutôt que des choix.
Ce que le protocole ne remplacera jamais
Il y a quelque chose de révélateur dans la façon dont chaque nouvelle version de HTTP suscite les mêmes attentes, puis les mêmes déceptions. Le protocole optimise le tuyau, jamais ce qu’on y fait passer. Il n’a aucune prise sur le poids des ressources, sur le temps que met une application à répondre, ni sur la quantité de scripts tiers chargés au premier affichage.
Les chiffres du Web Almanac disent d’ailleurs quelque chose d’intéressant sur qui décide réellement. Entre 85 et 86 % des requêtes HTTP/3 viennent d’un CDN, et moins de 4 % des requêtes servies par un CDN passent encore en HTTP/1.1, contre 29 % pour celles servies directement par une origine. L’adoption des protocoles récents n’est plus vraiment un choix d’éditeur de site : c’est une conséquence de son architecture de diffusion.
Ce qui laisse la question ouverte pour la suite. Si le transport devient un réglage que l’on hérite de son infrastructure plutôt qu’une décision technique, l’écart de performance entre deux sites se déplace entièrement vers ce que le protocole ne touche pas : la quantité de travail qu’un serveur doit fournir avant de répondre, et la discipline avec laquelle une équipe arbitre ce qu’elle charge. Deux terrains où aucune RFC ne viendra trancher à notre place.
