Langues

Comprendre HTTP/2 et HTTP/3 pour les performances Web et le SEO

Ce que changent HTTP/2 et HTTP/3, comment QUIC réduit sans supprimer le blocage en tête de ligne et leur incidence indirecte sur le SEO via les Core Web Vitals.

Première publication : 3 juil. 2026 · Dernière mise à jour : 21 août 2026 · Advanced
Langues
AIRédigé parAI v2

HTTP/2 combine multiplexage et compression d’en-têtes sur une connexion TCP ; HTTP/3 conserve ces principes sur QUIC/UDP, ce qui empêche la perte d’un paquet sur un flux de bloquer tous les autres. Les flux QUIC partagent toutefois contrôle de congestion et état QPACK : les fichiers ne sont pas totalement indépendants. Aucun protocole n’est un facteur de classement direct. Google n’accorde aucun avantage au crawl en HTTP/2 et sa documentation des robots ne répertorie pas HTTP/3. Googlebot emploie HTTP/1.1 par défaut et HTTP/2 lorsqu’un site HTTPS compatible h2 est éligible ; un état 421 permet le refus. Le bénéfice SEO est indirect, par la vitesse réelle et les Core Web Vitals. Pour la plupart des sites, l’activation passe par un CDN, mais le protocole négocié doit être vérifié : UDP peut être bloqué et la première visite commence souvent en HTTP/2. HTTP/2 Server Push est mort en pratique depuis sa désactivation par défaut dans Chrome 106 ; utilisez plutôt 103 Early Hints ou link rel=preload.

En bref — HTTP/2 = multiplexage + compression d’en-têtes HPACK + indications de priorité RFC 9218 sur une connexion TCP. HTTP/3 = la même sémantique sur QUIC/UDP plutôt que TCP, ce qui empêche la perte d’un paquet sur un flux de bloquer les autres flux. Les flux partagent toujours le contrôle de congestion de la connexion et l’état QPACK : c’est une vraie correction, pas une indépendance totale de chaque fichier. Aucun n’est un facteur de classement direct : Google affirme que le crawl en HTTP/2 n’apporte aucun avantage de classement, et la documentation des robots de Google ne répertorie pas HTTP/3 comme protocole pris en charge. Googlebot emploie HTTP/1.1 par défaut et HTTP/2 lorsqu’un site est éligible — HTTPS + prise en charge de h2 —, avec un état 421 comme mécanisme documenté de refus. Le bénéfice SEO est indirect : la vitesse réelle des utilisateurs alimente les Core Web Vitals, mais la négociation d’un protocole récent ne garantit à elle seule ni de meilleurs Core Web Vitals ni de meilleures performances dans la recherche. La majorité du Web utilise HTTP/2 ; HTTP/3 demeure minoritaire parmi les requêtes réelles et, même lorsqu’un CDN le « prend en charge », la découverte et le repli font qu’une visite donnée ne l’emploie pas toujours. Deux efforts sont inutiles : rechercher un avantage de classement et adopter Server Push, désactivé par défaut dans Chrome/Chromium depuis la version 106 — préférez 103 Early Hints ou rel=preload.

Evidence for this claim HTTP/2 adds binary framing and multiplexed streams while preserving HTTP semantics. Scope: Current official or standards documentation. Confidence: high · Verified: RFC 9113: HTTP/2 Evidence for this claim HTTP/3 maps HTTP semantics over QUIC rather than TCP. Scope: Current official or standards documentation. Confidence: high · Verified: RFC 9114: HTTP/3

Ce que chaque protocole change réellement

Distinguez clairement les deux évolutions et le reste devient évident.

HTTP/2 (2015, RFC 7540) a conservé la sémantique HTTP tout en refondant le transport des octets :

  • Multiplexage. De nombreuses requêtes et réponses s’entrelacent sur une seule connexion, contrairement au modèle de HTTP/1.1 — une opération à la fois par connexion — qui obligeait les navigateurs à ouvrir plusieurs connexions parallèles.
  • Compression d’en-têtes HPACK. Les en-têtes répétitifs transmis avec chaque requête sont compressés, ce qui réduit la surcharge.
  • Priorisation des flux, mais plus selon le mécanisme d’origine. L’arbre de priorités de RFC 7540 a été déprécié par la mise à jour de HTTP/2, RFC 9113. Le signal actuel est le schéma de priorité extensible de RFC 9218 : de simples indications urgency/incremental, utilisables par HTTP/2 et HTTP/3. Elles restent consultatives ; un serveur peut les respecter entièrement, partiellement ou pas du tout.
  • À l’origine, Server Push aussi : il reste défini techniquement dans les spécifications HTTP/2 et HTTP/3, mais les navigateurs ont abandonné sa prise en charge en pratique — voir plus bas.
  • En pratique, HTTPS est nécessaire : aucun navigateur courant ne négocie HTTP/2 sans chiffrement.

HTTP/3 (2022, RFC 9114) conserve la sémantique de HTTP/2, mais remplace le transport :

  • Il fonctionne sur QUIC, un transport bâti sur UDP, plutôt que sur TCP.
  • Il réduit le blocage en tête de ligne au niveau du transport de HTTP/2, sans en supprimer toutes les formes. Avec HTTP/2, tous les flux multiplexés empruntent une connexion TCP ; la perte d’un seul paquet bloque donc tous les flux jusqu’à sa retransmission. QUIC attribue un flux à chaque requête HTTP : la perte d’un paquet sur un flux ne bloque plus les autres flux. Voilà la véritable correction. Les fichiers ne sont cependant pas totalement indépendants : les flux d’une même connexion QUIC partagent encore contrôle de congestion et contrôle de flux — un mauvais chemin réseau ralentit donc toujours l’ensemble, sans blocage transversal —, les octets d’un même flux arrivent toujours dans l’ordre — une ressource répartie sur plusieurs paquets attend son propre paquet perdu — et le décodage d’en-têtes QPACK passe par un flux de contrôle partagé dont d’autres flux peuvent dépendre. Retenez « la perte ne se propage plus entre les flux », et non « chaque fichier voyage dans un isolement total ».
  • QUIC intègre TLS 1.3 — chiffrement obligatoire — et accélère l’établissement de connexion par la reprise de session, notamment avec un mode 0-RTT facultatif pour les visites répétées. Le 0-RTT est conditionnel, pas une voie rapide universelle : les « données précoces » peuvent être rejouées par un attaquant. Navigateurs et serveurs limitent donc les requêtes sûres dans ce mode, et le serveur peut les refuser puis revenir à un handshake normal — voir 425 Too Early.
  • QUIC permet aussi la migration de connexion : un client peut conserver une connexion lors d’un changement de réseau — Wi-Fi → réseau mobile — après validation du nouveau chemin. Dans QUIC v1, cette migration est toutefois initiée uniquement par le client — le serveur ne peut pas déplacer seul la connexion —, et validation du chemin, changement d’adresse et réinitialisation de l’état de congestion rendent la continuité conditionnelle, non garantie.

La nuance honnête : HTTP/3 apporte surtout des gains sur les connexions lentes ou sujettes aux pertes. Les utilisateurs disposant déjà d’un réseau rapide et stable voient moins de différence ; la tranche la plus lente du trafic en profite le plus, comme l’explique bien Will Nye dans Search Engine Journal. Ne survendez pas HTTP/3 à un site dont toute l’audience utilise la fibre.

Est-ce que cela influence le classement ? Non — voici les termes exacts

C’est la question qui amène réellement les spécialistes SEO ici ; commençons donc par la documentation des robots de Google. Dans la présentation des robots d’exploration de Google, Google indique qu’ils prennent en charge HTTP/1.1 et HTTP/2, choisissent celui qui offre les meilleures performances de crawl, et précise :

“The default protocol version used by Google’s crawlers is HTTP/1.1; crawling over HTTP/2 may save computing resources (for example, CPU, RAM) for your site and Googlebot, but otherwise there’s no Google-product specific benefit to the site (for example, no ranking boost in Google Search).” (traduction) « La version de protocole utilisée par défaut par les robots de Google est HTTP/1.1 ; le crawl en HTTP/2 peut économiser des ressources informatiques — par exemple CPU et RAM — pour votre site et Googlebot, mais n’apporte par ailleurs aucun avantage propre aux produits Google — par exemple aucun gain de classement dans la recherche Google. »

Google pourrait difficilement être plus clair. HTTP/2 améliore l’efficacité de la couche de transport pour les deux côtés de la connexion — il peut économiser du travail à votre serveur et à Googlebot —, mais ce n’est pas un signal de classement.

Le véritable enjeu SEO est indirect et mérite d’être formulé clairement : des chargements plus rapides pour les utilisateurs alimentent les Core Web Vitals, qui font partie des signaux d’expérience sur la page de Google. La valeur SEO de HTTP/2 et HTTP/3 est donc un investissement dans l’expérience utilisateur qui apparaît dans les métriques réellement mesurées par Google, pas un interrupteur qui améliore directement les positions.

Ce que fait réellement Googlebot aujourd’hui

C’est la partie que la plupart des articles concurrents omettent, alors qu’elle est la plus utile de cette page. La documentation des robots de Google est précise :

  • HTTP/1.1 est utilisé par défaut. D’après la présentation des robots, HTTP/1.1 est le protocole par défaut ; Googlebot peut passer à HTTP/2 entre deux sessions de crawl selon les statistiques antérieures.

  • Le crawl en HTTP/2 dépend de l’éligibilité, pas d’une demande. Googlebot a commencé à crawler certains sites en HTTP/2 à la mi-novembre 2020, comme annoncé dans Googlebot parlera bientôt HTTP/2. Un site devient éligible s’il est servi en HTTPS avec prise en charge de HTTP/2 et suffisamment crawlé pour que l’évolution soit rentable ; vous ne pouvez pas l’imposer.

  • Vous pouvez refuser avec un état 421. Google documente ce mécanisme dans la présentation des robots :

    “To opt out from crawling over HTTP/2, instruct the server that’s hosting your site to respond with a 421 HTTP status code when Google attempts to access your site over HTTP/2.” (traduction) « Pour refuser le crawl en HTTP/2, demandez au serveur qui héberge votre site de répondre avec un code d’état HTTP 421 lorsque Google tente d’accéder au site en HTTP/2. »

  • HTTP/3 ne figure pas dans la documentation des robots de Google. Au moment de la rédaction, la présentation actuelle cite HTTP/1.1 et HTTP/2 comme versions prises en charge, sans mentionner HTTP/3 : il n’est donc pas proposé comme protocole de crawl documenté. Cette affirmation porte sur ce que Google a publié ou non, et ne promet pas qu’aucune requête n’utilise jamais HTTP/3. Barry Schwartz a signalé la même absence dans Search Engine Roundtable, et le guide de Will Nye dans SEJ indique que Googlebot ne prend actuellement pas en charge HTTP/3.

Environ cinq ans ont séparé la publication de HTTP/2 en 2015 de sa prise en charge par Googlebot en 2020. HTTP/3 a été finalisé en 2022 ; suivant ce précédent, sa prise en charge par le robot pourrait encore tarder. Mon avis : n’attendez pas avec impatience le crawl en HTTP/3, mais ne l’attendez pas non plus pour améliorer votre site. Adoptez HTTP/3 pour vos utilisateurs, pas pour Googlebot.

Deux éléments méritent d’être signalés. Premièrement, autour de Google I/O en 2021, John Mueller indiquait que Google crawlait déjà plus de la moitié des URL en HTTP/2 et que multiplexage et compression des en-têtes avaient nettement réduit le nombre de connexions et la bande passante — un avantage pour l’infrastructure de crawl de Google comme pour la vôtre. Deuxièmement, côté Bing, je n’ai trouvé aucune déclaration de Microsoft comparable sur une politique de crawl HTTP/2 ou HTTP/3. Bing publie beaucoup sur l’efficacité du crawl en général — IndexNow, contrôle du crawl, traitement des sitemaps —, mais rien d’aussi explicite que Google sur les protocoles. Je n’en déduirai donc rien. Si une réponse propre à Bing vous importe, consultez directement le blog Bing Webmaster.

Ce que montrent — ou non — les outils de Chrome

Lighthouse dans Chrome possède un diagnostic Modern HTTP qui signale un site servi avec une ancienne version de HTTP ; il vérifie essentiellement si vos fichiers transitent en HTTP/2 ou HTTP/3. Utile, mais avec une réserve : ce diagnostic apparaît dans les traces de performances de Chrome DevTools, pas dans le rapport public standard PageSpeed Insights consulté par la plupart des spécialistes SEO. Lighthouse disposait auparavant d’un audit uses-http2, désactivé parce qu’il était difficile de distinguer fiablement h1, h2 et h3 sur toutes les requêtes. Ne cherchez donc pas un indicateur « uses HTTP/2 » fiable dans votre rapport PSI habituel. Pour confirmer le protocole, consultez la colonne Protocol du panneau Réseau du navigateur ou un outil comme WebPageTest.

Adoption réelle en 2026

Le meilleur jeu de données public est le chapitre HTTP du Web Almanac 2024, rédigé par Robin Marx d’Akamai. Voici la répartition du Web :

  • Pages d’accueil : HTTP/1.1 ~22 % · HTTP/2 ~71 % · HTTP/3 ~7 % sur ordinateur — résultats proches sur mobile : ~21 % / ~70 % / ~9 %.
  • Toutes requêtes confondues : environ 85 % utilisent HTTP/2 ou une version plus récente ; seulement ~15 % restent en HTTP/1.1.
  • Davantage de sites sont prêts pour HTTP/3 qu’ils ne l’utilisent réellement : environ 26 à 28 % des pages d’accueil annoncent HTTP/3 dans l’en-tête alt-svc, mais une proportion bien moindre des requêtes l’emprunte effectivement.
  • Les CDN font l’essentiel du travail. Dans les données de l’Almanac, environ 96 % des requêtes servies par CDN utilisent HTTP/2 ou une version plus récente, tandis qu’environ 29 % des requêtes sans CDN restent en HTTP/1.1. Cet écart résume en une statistique tout l’argument en faveur d’un CDN.

Précision sur une statistique souvent citée ailleurs : l’ancien chiffre selon lequel « 25 % des dix millions de principaux sites prennent en charge HTTP/3 » ne mesure pas la même chose que les « 7 à 9 % de requêtes réellement servies en HTTP/3 » de l’Almanac. La prise en charge au niveau des grands domaines et la part des requêtes réelles sont deux mesures différentes. Elles peuvent être vraies simultanément ; ne les présentez pas comme contradictoires.

Comment l’activer réellement

Pour l’immense majorité des sites, il ne s’agit pas d’une migration de serveur. Mais « activer le réglage » ne résume pas toute l’histoire : HTTP/3 doit être découvert et peut se replier silencieusement :

  • Utilisez un CDN. Activer HTTP/2 et HTTP/3 chez un CDN — Cloudflare, Fastly, Google Cloud CDN ou autre — se résume généralement à une case et constitue de loin la voie la plus simple. Vérifiez ensuite le protocole négocié dans le panneau Réseau du navigateur ou avec curl --http3, plutôt que de supposer que la case fonctionne de bout en bout. Configuration TLS/ALPN, prise en charge entre origine et edge, puis entre edge et client doivent toutes s’aligner.
  • Servez le site en HTTPS. C’est un prérequis pratique des deux protocoles ; aucun navigateur majeur ne négocie HTTP/2 ou HTTP/3 sans chiffrement.
  • Comprenez comment HTTP/3 est découvert et comment il se replie. La première connexion du navigateur au site se négocie généralement encore sur TCP — HTTP/2 ou HTTP/1.1. Le serveur ou CDN annonce HTTP/3 dans l’en-tête Alt-Svc ou un enregistrement DNS HTTPS/SVCB ; le navigateur le met en cache et tente QUIC lors d’une connexion ultérieure. Si un réseau bloque UDP ou si le handshake QUIC échoue, il revient automatiquement à HTTP/2 ou HTTP/1.1. Le système fonctionne alors comme prévu, mais la « prise en charge de HTTP/3 par l’origine » ne garantit pas que chaque visite — surtout la première — l’utilise. Mesurez la répartition réelle au lieu de supposer 100 %.
  • Vérifiez la prise en charge du serveur en cas d’auto-hébergement. La prise en charge spécifique de HTTP/3 par les serveurs Web a historiquement pris du retard — elle évolue vite, vérifiez donc l’état actuel de votre pile. C’est précisément pourquoi le CDN est le choix pragmatique par défaut.

Ce qu’il ne faut pas faire : Server Push

Si quelqu’un propose d’implémenter HTTP/2 Server Push, refusez : la fonction est morte dans les navigateurs qui comptent, même si elle reste techniquement définie dans les spécifications HTTP/2 et HTTP/3. L’équipe de Chrome a documenté son retrait dans Suppression de HTTP/2 Server Push, par Barry Pollard. Points essentiels :

“support of HTTP/2 Server Push will be disabled by default in Chrome 106 and other Chromium-based browsers.” (traduction) « La prise en charge de HTTP/2 Server Push sera désactivée par défaut dans Chrome 106 et les autres navigateurs fondés sur Chromium. »

L’adoption s’était déjà effondrée : Pollard note que son usage parmi les sites HTTP/2 “dropped to 0.7%” (traduction) « est tombé à 0,7 % ». Surtout, l’intérêt pour les performances ne s’est jamais confirmé : l’article décrit des résultats “without a clear net performance gain and in many cases performance regressions.” (traduction) « sans gain net de performances évident et, dans de nombreux cas, avec des régressions ». Il s’agit d’un retrait documenté pour Chrome/Chromium ; les autres moteurs ont suivi la même direction en pratique, mais considérez « Push a disparu partout » comme la réalité pratique autour de laquelle concevoir, pas comme une affirmation sur le code source de chaque moteur.

Les solutions de remplacement documentées :

“103 Early Hints is a much less error-prone alternative with many of the same upsides as Push, and a lot less of the downsides” (traduction) « 103 Early Hints est une solution de remplacement bien moins sujette aux erreurs, qui offre de nombreux avantages de Push avec beaucoup moins d’inconvénients. »

Ajoutez une balise <link rel=preload> standard pour les ressources dont vous savez qu’elles seront nécessaires. Ces mécanismes sont également abordés dans les indications de ressources. Conclusion : ne concevez rien autour de Server Push en 2026.

La réserve de sécurité — un paragraphe honnête

La grande force de HTTP/2 a aussi brièvement constitué une faiblesse. En 2023, le multiplexage qui accélère HTTP/2 est devenu le mécanisme d’une technique DDoS record, HTTP/2 Rapid Reset — CVE-2023-44487. Comme l’ont expliqué les ingénieurs de Cloudflare, la capacité d’ouvrir et d’annuler rapidement de nombreux flux représentait “an obvious vector for denial-of-service,” (traduction) « un vecteur évident de déni de service », et les grands fournisseurs ont dû atténuer des attaques atteignant des centaines de millions de requêtes par seconde. Ce n’est pas une raison d’éviter HTTP/2 — serveurs et CDN modernes sont corrigés —, mais cette phrase empêche de présenter le protocole comme un avantage sans contrepartie. En cas d’auto-hébergement, maintenez votre logiciel serveur à jour.

La place de ces protocoles dans les performances Web

HTTP/2 et HTTP/3 agissent sur la couche de transport et influencent les mêmes métriques en aval que le reste du domaine des performances Web. Une livraison plus rapide améliore TTFB et LCP, d’où le lien avec les Core Web Vitals. Un CDN est le moyen habituel d’activer ces protocoles et le principal moteur de leur adoption réelle. La mise en cache et les indications de ressources — dont Early Hints et preload, qui remplacent Server Push — complètent l’accélération de l’arrivée des ressources dans le navigateur. Considérez HTTP/2 et HTTP/3 comme une composante de cette couche de livraison : utile aux utilisateurs, mais pas un bouton de classement.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.