HTTP/3

HTTP/3 est la troisième version majeure du protocole HTTP, standardisée par l'IETF en juin 2022 dans la RFC 9114. Sa nouveauté n'est pas dans les requêtes et les réponses, qui gardent la même sémantique, mais dans le transport : HTTP/3 remplace TCP par QUIC, un protocole fondé sur UDP qui intègre le chiffrement TLS 1.3, établit les connexions plus vite et évite le blocage en tête de file dont souffre HTTP/2 sur les réseaux instables. Pour le SEO, l'intérêt est indirect : de meilleurs temps de chargement pour les visiteurs, donc de meilleurs Core Web Vitals, mais aucun effet sur le classement, et les robots de Google n'explorent pas en HTTP/3.

Définition détaillée de HTTP/3

HTTP/1.1 (1999) et HTTP/2 (2015) reposent tous deux sur TCP, le protocole de transport historique d'Internet, auquel s'ajoute TLS pour le chiffrement. HTTP/2 avait apporté le multiplexage : plusieurs requêtes en parallèle sur une seule connexion, au lieu d'une file par connexion. Mais TCP livre les données dans l'ordre strict où elles ont été envoyées : quand un paquet se perd, tout ce qui suit attend sa retransmission, même s'il appartient à une autre requête. C'est le blocage en tête de file (head-of-line blocking), particulièrement pénalisant sur les réseaux mobiles et les connexions à pertes.

HTTP/3 résout ce problème en changeant de transport. La RFC 9114, publiée en juin 2022 sous la direction de Mike Bishop (Akamai), décrit « une correspondance de la sémantique HTTP sur QUIC ». QUIC, défini par la RFC 9000 en mai 2021, est un protocole de transport sécurisé qui s'appuie sur UDP : les flux y sont indépendants, si bien qu'un paquet perdu ne bloque que le flux auquel il appartient. Les autres requêtes de la page continuent d'arriver. QUIC intègre en outre la négociation TLS 1.3 dans sa propre poignée de main, et chiffre l'essentiel de chaque paquet, y compris une partie des métadonnées que TCP laissait en clair.

Le résultat, du point de vue d'une page web : les mêmes méthodes, les mêmes en-têtes, les mêmes codes HTTP, mais une connexion qui s'ouvre plus vite, résiste mieux aux pertes et survit à un changement de réseau. HTTP/3 n'existe qu'en HTTPS : il n'y a pas de version en clair.

Ce que HTTP/3 change par rapport à HTTP/2

• Une connexion plus rapide à établir. Avec TCP puis TLS, ouvrir une connexion sécurisée demande plusieurs allers-retours. QUIC combine la négociation du transport et celle du chiffrement en une seule poignée de main, et la RFC 9000 prévoit un mode 0-RTT qui permet à un client déjà connu du serveur d'envoyer ses données dès le premier paquet. Sur une page, cela se traduit par un TTFB plus court, surtout pour les visiteurs éloignés du serveur.
• Plus de blocage en tête de file. Les flux QUIC sont indépendants : une image dont un paquet s'est perdu ne retarde plus la feuille de style qui suit. Le gain est d'autant plus net que le réseau est mauvais ; sur une fibre sans perte, la différence avec HTTP/2 est faible.
• La migration de connexion. Une connexion QUIC est identifiée par un identifiant et non par le couple adresse IP et port : un téléphone qui passe du wifi à la 4G conserve sa connexion au lieu d'en rouvrir une.
• Le chiffrement par défaut. Il n'y a pas de HTTP/3 sans TLS 1.3 ; le certificat et la configuration HTTPS du site sont un prérequis.
• Un coût côté serveur. QUIC s'exécute dans l'espace utilisateur, pas dans le noyau comme TCP, ce qui demande davantage de calcul pour un même volume. C'est une des raisons pour lesquelles beaucoup de sites l'activent sur leur CDN plutôt que sur leur serveur d'origine.

Histoire et adoption

QUIC est né chez Google, qui l'a annoncé en 2013 et déployé entre Chrome et ses propres services avant de le porter à l'IETF en 2015. Le 7 octobre 2020, le blog Chromium a annoncé le déploiement de la version IETF (alors le brouillon h3-29) auprès de 25 % des utilisateurs de Chrome stable, en indiquant que QUIC portait alors plus d'un tiers du trafic de Google, et que ses mesures internes montraient une latence de recherche réduite de plus de 2 % et un temps de mise en mémoire tampon de YouTube réduit de plus de 9 % par rapport à HTTP sur TLS 1.3 et TCP. Les RFC 9000 (mai 2021) et 9114 (juin 2022) ont ensuite figé le standard, et tous les navigateurs majeurs le prennent en charge.

Côté serveurs, l'adoption est passée en grande partie par les CDN. Cloudflare, dont la documentation indique que HTTP/3 est disponible sur toutes ses offres, gratuite comprise, l'active entre le visiteur et son réseau ; la connexion entre Cloudflare et le serveur d'origine, elle, reste en HTTP/1.1 ou HTTP/2. Dans son bilan de l'année 2025, publié le 15 décembre 2025, Cloudflare indique que 21 % des requêtes reçues sur son réseau ont été faites en HTTP/3, contre 50 % en HTTP/2 et 29 % en HTTP/1.x, des parts presque inchangées par rapport à 2024. Une lecture s'impose : les robots n'utilisent pas HTTP/3, et le même bilan attribue les taux de HTTP/3 les plus faibles, sous 10 % dans sept pays ou régions, à un fort trafic HTTP/1.x d'origine automatisée. La part de HTTP/3 chez les visiteurs humains est donc supérieure à ce chiffre global.

Ce que HTTP/3 change pour le SEO

Rien pour le classement, et la position de Google est explicite. Sa documentation sur les robots d'exploration indique que ses robots prennent en charge HTTP/1.1 et HTTP/2, HTTP/1.1 étant le protocole par défaut, et qu'explorer en HTTP/2 « peut économiser des ressources de calcul » pour le site et pour Googlebot, « mais n'apporte par ailleurs aucun avantage propre aux produits Google (par exemple, pas de gain de classement dans la recherche Google) ». HTTP/3 n'y figure pas : Googlebot n'explore pas en HTTP/3, et il l'a confirmé dès l'annonce de l'exploration en HTTP/2, le 17 septembre 2020, en répondant « Non » à la question d'un avantage de classement lié au protocole.

L'effet passe par les visiteurs. Les Core Web Vitals sont mesurés sur les utilisateurs réels de Chrome, qui, eux, parlent HTTP/3 : une connexion plus rapide et plus robuste raccourcit le TTFB, donc le LCP, en particulier sur mobile et sur les réseaux à pertes. Le guide d'optimisation du TTFB de web.dev cite d'ailleurs, parmi les apports d'un CDN, le fait de servir en HTTP/2 ou HTTP/3, ce dernier « résolvant le problème de blocage en tête de file présent dans TCP ». Le gain est réel mais borné : il ne corrige ni un serveur lent, ni une page trop lourde, ni un rendu qui dépend de trois secondes de JavaScript. HTTP/3 est un levier de performance parmi d'autres, à activer parce qu'il est peu coûteux, pas un chantier SEO en soi.

Comment activer et vérifier HTTP/3

L'activation

Le chemin le plus court est le CDN : chez Cloudflare, un interrupteur dans les réglages de vitesse (« Protocol Optimization ») ou un appel d'API suffisent, à condition qu'un certificat soit en place sur le réseau de bord. Les autres grands CDN et de nombreux hébergeurs proposent l'équivalent. Sur un serveur d'origine, la prise en charge dépend du logiciel : les serveurs web récents l'intègrent, en général derrière une directive à activer explicitement, et il faut que le port 443 soit ouvert en UDP dans le pare-feu, en plus du TCP habituel.

La découverte par le navigateur

Le navigateur ne devine pas qu'un serveur parle HTTP/3 : il commence en HTTP/1.1 ou HTTP/2 sur TCP, et le serveur lui signale l'alternative par un en-tête de réponse Alt-Svc, par exemple Alt-Svc: h3=":443"; ma=86400, où h3 est l'identifiant du protocole négocié en ALPN (Application-Layer Protocol Negotiation) et ma la durée pendant laquelle le navigateur peut retenir l'information. Aux visites suivantes, le navigateur tente directement QUIC. La RFC 9114 prévoit aussi le repli : si la connexion QUIC échoue, par exemple parce qu'un réseau d'entreprise bloque UDP, le client doit revenir aux versions de HTTP sur TCP. Un site en HTTP/3 reste donc accessible partout ; il est simplement plus rapide là où QUIC passe.

La vérification

• Dans Chrome DevTools, la colonne « Protocol » du panneau Réseau affiche h3 pour les ressources chargées en HTTP/3, h2 pour HTTP/2 et http/1.1 sinon. La première visite peut encore montrer h2 ; recharger la page une fois l'en-tête Alt-Svc reçu.
• En ligne de commande, une version de curl compilée avec la prise en charge de HTTP/3 accepte l'option --http3 ; à défaut, curl -I permet au moins de lire l'en-tête Alt-Svc dans la réponse.
• Dans les données de terrain, la comparaison du TTFB et du LCP dans le CrUX avant et après activation dit si le gain est visible pour les visiteurs, ce qui est la seule mesure qui compte.

Limites et idées reçues

• « HTTP/3 améliore le référencement. » Non. Google ne l'utilise ni pour explorer ni pour classer. Il améliore l'expérience des visiteurs, et donc, indirectement, les mesures de terrain que Google prend en compte.
• « Le CDN suffit. » Pour la connexion visiteur, oui ; mais le trajet entre le CDN et le serveur d'origine reste en TCP, et un serveur lent le reste. HTTP/3 ne remplace pas le cache ni l'hébergement.
• « Tous les visiteurs en profitent. » Les réseaux qui filtrent UDP, certains proxys d'entreprise et les clients anciens reviennent à HTTP/2 ou HTTP/1.1. Le repli est automatique et sans erreur, mais le gain n'est pas universel.
• « Les robots en profitent aussi. » Les robots des moteurs, comme la plupart des outils de crawl, restent en HTTP/1.1 ou HTTP/2. Les logs serveur continueront de montrer ces protocoles pour Googlebot après l'activation.
• « C'est plus sûr, donc obligatoire. » Le chiffrement de QUIC est un progrès, mais un site en HTTPS avec TLS 1.3 sur HTTP/2 est déjà correctement protégé. HTTP/3 est une optimisation, pas une mise en conformité.

FAQ

HTTP/3 est-il un critère de classement Google ?

Non. Google indique que ses robots explorent en HTTP/1.1 et HTTP/2 uniquement, et qu'aucun protocole n'apporte de gain de classement. HTTP/3 agit sur l'expérience des visiteurs, donc sur les Core Web Vitals mesurés sur le terrain, mais pas sur le classement lui-même.

Googlebot explore-t-il en HTTP/3 ?

Non. La documentation Google Search Central sur les robots d'exploration ne cite que HTTP/1.1, protocole par défaut, et HTTP/2, utilisé quand il permet d'économiser des ressources. Activer HTTP/3 ne change rien à l'exploration ; les logs continueront d'afficher HTTP/1.1 ou HTTP/2 pour Googlebot.

Quelle différence entre HTTP/2 et HTTP/3 ?

Les deux multiplexent plusieurs requêtes sur une connexion, mais HTTP/2 repose sur TCP, qui bloque tous les flux quand un paquet se perd, alors que HTTP/3 repose sur QUIC, fondé sur UDP, où chaque flux est indépendant. QUIC intègre aussi TLS 1.3 dans sa poignée de main, ce qui ouvre la connexion plus vite, et survit à un changement de réseau.

Comment savoir si mon site utilise HTTP/3 ?

Dans Chrome DevTools, la colonne « Protocol » du panneau Réseau affiche h3 pour les ressources servies en HTTP/3. En ligne de commande, curl -I permet de lire l'en-tête Alt-Svc, par lequel le serveur annonce la disponibilité de h3. Un premier chargement peut encore passer en h2 : recharger la page.

Faut-il activer HTTP/3 sur son serveur ou sur son CDN ?

Le plus simple est le CDN, qui l'active entre le visiteur et son réseau de bord en un réglage, à condition qu'un certificat soit en place. La connexion entre le CDN et le serveur d'origine reste en HTTP/1.1 ou HTTP/2. L'activer sur le serveur d'origine n'a d'intérêt que sans CDN, et suppose un logiciel serveur compatible et le port 443 ouvert en UDP.

En résumé

• HTTP/3 : troisième version majeure de HTTP, RFC 9114 (juin 2022) ; même sémantique que HTTP/1.1 et HTTP/2, mais transportée par QUIC (RFC 9000, mai 2021) sur UDP, avec TLS 1.3 intégré.
• Apports : connexion plus rapide à établir (0-RTT possible), fin du blocage en tête de file de TCP, migration de connexion au changement de réseau, chiffrement obligatoire.
• Adoption : Chrome depuis octobre 2020, tous les navigateurs majeurs depuis ; 21 % des requêtes reçues par Cloudflare en 2025, contre 50 % en HTTP/2 et 29 % en HTTP/1.x, les robots restant en HTTP/1.x.
• SEO : aucun effet sur le classement ; Googlebot explore en HTTP/1.1 et HTTP/2 seulement ; le gain passe par le TTFB et le LCP des visiteurs réels.
• Activation : un réglage sur le CDN (Cloudflare l'offre sur toutes ses offres), ou une directive sur un serveur récent avec le port 443 ouvert en UDP ; découverte par l'en-tête Alt-Svc, repli automatique sur TCP.
• Vérification : colonne « Protocol » de Chrome DevTools (h3), en-tête Alt-Svc avec curl, TTFB et LCP dans le CrUX.

Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !