Qu'est-ce que HTTP/2 et HTTP/3 ? Guide pratique pour les sites WordPress

HTTP/2 et HTTP/3 sont les deux versions actuelles du Hypertext Transfer Protocol, le langage que les navigateurs utilisent pour demander des pages aux serveurs web. HTTP/2 a été standardisé en 2015 et est supporté par 100% des navigateurs modernes. HTTP/3, finalisé en RFC 9114 en 2022, est supporté par tous les principaux navigateurs depuis 2024. Les deux sont des mises à niveau transparentes par rapport à HTTP/1.1 : mêmes URLs, même HTML, mais chargement de page significativement plus rapide, notamment sur les réseaux mobiles et les connexions à forte latence.

Réponse rapide : quelle version mon site WordPress devrait-il utiliser ?

En 2026, la bonne réponse est "HTTP/3 avec fallback HTTP/2". Chaque navigateur négocie la version la plus élevée que les deux côtés supportent, vous n'avez donc pas à choisir. Si votre serveur parle HTTP/3, les navigateurs modernes l'utilisent ; les anciens navigateurs retombent sur HTTP/2 ; les clients vraiment anciens retombent sur HTTP/1.1. Il n'y a aucun scénario où HTTP/2 ou HTTP/3 est plus lent que HTTP/1.1 pour une page WordPress réelle, la seule question est donc de savoir si votre stack d'hébergement le supporte.

Quel problème HTTP/2 résout-il par rapport à HTTP/1.1 ?

HTTP/1.1, le protocole qui a fait tourner le web de 1997 à 2015, a un défaut fatal sur un site moderne : il ouvre une connexion TCP par ressource, et seulement six en parallèle par domaine. Une page WordPress typique charge 50 à 150 ressources (CSS, JS, images, polices, scripts de tracking). Sous HTTP/1.1, ces 100+ requêtes se sérialisent dans une file d'attente de six connexions, chacune attendant que la précédente termine. Le navigateur reste littéralement inactif en attendant que des emplacements se libèrent.

HTTP/2 résout cela avec trois changements :

Multiplexage. Une seule connexion TCP transporte un nombre illimité de paires requête/réponse parallèles (appelées streams). Les 150 ressources voyagent toutes sur une connexion, entrelacées.
Compression d'en-têtes (HPACK). Les en-têtes HTTP (cookies, User-Agent, referer) totalisent souvent plusieurs Ko par requête. HPACK les compresse et mémorise les en-têtes répétés, faisant tomber l'overhead par requête de kilo-octets à octets.
Framing binaire. HTTP/1.1 est basé sur du texte et ambigu à parser. HTTP/2 utilise un format de frame binaire plus rapide à traiter pour les serveurs et proxies, et élimine toute une classe d'attaques de smuggling et de parsing.

Effet net : une page WordPress qui se charge en 4 secondes sur HTTP/1.1 se charge typiquement en 1,5 à 2,5 secondes sur HTTP/2, sur le même serveur. L'amélioration est plus grande sur les réseaux mobiles parce que l'overhead d'établissement de connexion est amorti sur toutes les requêtes.

Qu'est-ce que HTTP/3 ajoute par-dessus HTTP/2 ?

HTTP/3 garde tout ce que HTTP/2 a introduit (multiplexage, compression d'en-têtes, framing binaire) mais remplace le transport sous-jacent. Au lieu de TCP, HTTP/3 tourne sur QUIC, un protocole de transport construit sur UDP. Cela semble être un détail d'implémentation mais résout trois vrais problèmes de performance :

Head-of-line blocking au niveau TCP. HTTP/2 multiplexe les streams sur une connexion TCP, mais TCP lui-même livre les paquets dans l'ordre. Si un paquet est perdu, tous les streams sur cette connexion stagnent jusqu'à l'arrivée de la retransmission. QUIC gère la perte de paquets par stream, donc un seul paquet perdu n'affecte que le stream auquel il appartient.
Établissement de connexion plus rapide. Établir une connexion HTTPS sur TCP nécessite trois aller-retours (handshake TCP, puis handshake TLS). QUIC les combine en un seul aller-retour pour les premières connexions, et zéro aller-retour pour les connexions répétées en quelques minutes (appelé 0-RTT). Sur une connexion mobile avec 100ms de latence, cela économise 200-300ms avant même que le premier octet de contenu ne commence à se charger.
Migration de connexion. Les connexions QUIC sont identifiées par un ID de connexion, pas par IP + port. Lorsqu'un téléphone passe du Wi-Fi à la cellulaire, la connexion QUIC survit. Les connexions TCP devraient se reconnecter.

Gain réel par-dessus HTTP/2 : typiquement 5-15% plus rapide pour les premiers chargements de page, plus sur les réseaux mobiles avec pertes, moins sur une connexion filaire stable.

Comment vérifier quelle version HTTP mon site WordPress utilise actuellement ?

Quatre méthodes fiables, du plus rapide au plus autoritatif :

Rapport InspectWP. La section Performance de tout rapport InspectWP liste la version HTTP négociée pour le document principal. Une ligne, pas de configuration.
DevTools Chrome. Ouvrez les DevTools (F12), onglet Network, rechargez la page, clic droit sur n'importe quel en-tête de colonne et activez "Protocol". La colonne montre h2 pour HTTP/2 et h3 pour HTTP/3 (aussi appelé http/3 dans certaines versions de Chrome).
Ligne de commande avec curl. Exécutez curl -I --http2 https://votresite.com pour HTTP/2 ou curl -I --http3 https://votresite.com pour HTTP/3 (curl 7.66+ requis). La ligne de réponse montre HTTP/2 200 ou HTTP/3 200.
Outils de test publics. https://http3check.net teste spécifiquement le support HTTP/3. https://tools.keycdn.com/http2-test teste le support HTTP/2. Les deux retournent la version négociée et l'en-tête Alt-Svc (qui annonce le support HTTP/3).

Un piège : un site peut annoncer HTTP/3 dans son en-tête Alt-Svc sans que HTTP/3 ne fonctionne réellement. L'en-tête dit au navigateur "la prochaine fois, essaie HTTP/3 sur le port UDP 443", mais si UDP est bloqué quelque part sur le chemin, le navigateur retombe silencieusement sur HTTP/2. Vérifiez toujours avec une vraie requête, pas juste avec l'en-tête Alt-Svc.

Comment activer HTTP/2 ou HTTP/3 sur un site WordPress ?

Les versions HTTP sont négociées au niveau du serveur web. WordPress lui-même n'a rien à voir avec cela ; le choix se fait entre votre stack d'hébergement et le navigateur. Trois scénarios couvrent presque tous les sites :

Scénario 1 : hébergement WordPress managé

Presque tous les hébergeurs WordPress managés (Kinsta, WP Engine, Raidboxes, SiteGround, Pressable, Cloudways) livrent HTTP/2 par défaut depuis 2018. Le support HTTP/3 est désormais répandu mais pas universel en 2026. Kinsta, Cloudways, SiteGround, Raidboxes et Pressable ont HTTP/3 activé par défaut. WP Engine le propose en bascule. Si votre hébergeur n'est pas dans cette liste, demandez au support ; c'est généralement un changement en un clic.

Scénario 2 : hébergement mutualisé avec cPanel ou Plesk

Les hébergeurs cPanel (IONOS, Hostinger, beaucoup de revendeurs) livrent typiquement HTTP/2 par défaut et HTTP/3 sur les comptes plus récents. Vérifiez en activant EasyApache 4 avec le module mod_http2 si pas déjà présent. HTTP/3 dans Apache nécessite le module mod_http3 qui est encore considéré comme expérimental. La voie pragmatique en mutualisé est de mettre Cloudflare devant (l'offre gratuite suffit) et de laisser Cloudflare gérer la terminaison HTTP/3, ce qui est leur défaut depuis 2019.

Scénario 3 : VPS ou serveur dédié auto-géré

La configuration dépend de votre serveur web :

nginx. HTTP/2 nécessite nginx 1.9.5+ et la directive http2 sur votre ligne listen : listen 443 ssl http2;. HTTP/3 nécessite nginx 1.25+ compilé avec le support QUIC : listen 443 quic reuseport; listen 443 ssl; plus add_header Alt-Svc 'h3=":443"; ma=86400';. Le flag reuseport est critique ou HTTP/3 échoue silencieusement à démarrer.
Apache. HTTP/2 nécessite mod_http2 activé et la directive Protocols h2 h2c http/1.1 dans votre virtual host. HTTP/3 dans Apache est toujours expérimental ; la plupart des installations Apache en production restent à HTTP/2 et mettent nginx, Caddy ou Cloudflare devant pour HTTP/3.
Caddy. HTTP/3 est activé par défaut depuis Caddy 2.6. Rien à configurer ; si HTTPS fonctionne, HTTP/3 fonctionne.
LiteSpeed et OpenLiteSpeed. Les deux livrent HTTP/3 par défaut. Une raison pour laquelle LiteSpeed a gagné des parts sur le marché de l'hébergement WordPress.

Une exigence souvent manquée sur les installations auto-gérées : HTTP/3 nécessite que le port UDP 443 soit ouvert dans votre firewall. Beaucoup de configurations de serveur par défaut n'ouvrent que TCP 443. Sur Ubuntu, sudo ufw allow 443/udp, ou l'équivalent dans votre stack de firewall.

Quel est le rôle de Cloudflare et des autres CDN ?

Un CDN placé devant votre serveur d'origine termine typiquement le protocole moderne en bordure, puis parle à votre origine via HTTP/1.1 ou HTTP/2. Du point de vue du visiteur, la connexion au nœud edge du CDN (souvent à 20-50ms de distance) est en HTTP/3, rapide et moderne. Le lien du CDN vers l'origine se fait serveur à serveur dans les réseaux de datacenter où le protocole compte beaucoup moins. C'est pourquoi mettre Cloudflare devant un hébergeur mutualisé qui ne tourne qu'en HTTP/1.1 donne quand même la majeure partie du bénéfice de vitesse. Le visiteur ne touche jamais directement votre origine.

Le hic : si votre origine retourne un en-tête cache-busting (no-cache, no-store) ou si votre contenu n'est pas cacheable (pages WordPress connectées, panier WooCommerce), le CDN doit aller chercher à l'origine à chaque requête, et le saut lent origine-vers-CDN devient le goulot. Pour ces cas, le protocole à l'origine compte toujours.

Erreurs courantes et comment les éviter

Traiter HTTP/2 comme une solution magique pour les sites lents. HTTP/2 résout l'overhead de connexion. Il ne résout pas le PHP lent, les requêtes non optimisées, les images hero de 5 Mo, ni le JavaScript bloquant le rendu. Si votre TTFB (time to first byte) est de 2 secondes, passer à HTTP/3 vous économise 200ms. Les 1800ms restants restent du PHP et de la base de données.
Oublier de garder HTTP/1.1 activé. Les crawlers de moteurs de recherche, les outils de monitoring et les vieilles bibliothèques clientes ne parlent parfois que HTTP/1.1. Désactiver HTTP/1.1 entièrement les casse. Les serveurs web modernes négocient automatiquement la version la plus élevée supportée mutuellement ; gardez les trois (h3, h2, http/1.1) activées.
Concaténer et inliner les assets par habitude HTTP/1.1. Sous HTTP/1.1, combiner 30 fichiers CSS en 1 était un gain majeur à cause de la limite de connexions. Sous HTTP/2 et HTTP/3, cette optimisation cesse d'importer et peut même nuire (un seul gros bundle invalide le cache pour tout changement ; 30 petits fichiers n'invalident que ceux qui ont changé). La plupart des plugins de performance WordPress mettent encore "tout combiner" par défaut parce que les utilisateurs s'y attendent, mais ce n'est plus le bon défaut en 2026.
Supposer qu'Alt-Svc signifie que HTTP/3 fonctionne. L'en-tête annonce le support HTTP/3 ; il ne garantit pas que la connexion s'établisse réellement. Vérifiez toujours avec curl ou DevTools.
Bloquer UDP au firewall. Une cause fréquente de HTTP/3 qui ne fonctionne pas silencieusement. Vérifiez à la fois le firewall serveur et le firewall réseau (security group du fournisseur cloud, filtrage au niveau FAI sur les connexions grand public).

HTTP/2, HTTP/3 et Core Web Vitals

Les Core Web Vitals de Google mesurent Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS). Des trois, LCP est le plus affecté par la version HTTP. L'élément LCP (généralement l'image hero ou le plus gros bloc au-dessus du pli) doit se télécharger entièrement avant que LCP puisse être reporté, et la vitesse de téléchargement est exactement ce que HTTP/2 et HTTP/3 améliorent. Les sites qui passent de HTTP/1.1 à HTTP/2 voient LCP chuter de 300-800ms en moyenne. Le saut de HTTP/2 à HTTP/3 est plus petit, typiquement 50-200ms, mais sur les réseaux mobiles avec perte de paquets il peut être plus grand.

Ce que vérifie InspectWP

La section Performance de chaque rapport InspectWP montre quelle version HTTP a été négociée pour le document principal, plus l'encodage de contenu (gzip, Brotli) et la taille totale du HTML. Si votre site est encore sur HTTP/1.1 en 2026, le rapport le signale en avertissement, parce que c'est l'un des gains de performance à plus fort impact et plus faible effort disponibles, généralement un seul interrupteur dans le panneau d'hébergement. Si vous êtes sur HTTP/2 mais pas HTTP/3, cela apparaît comme informatif ; HTTP/3 est le défaut moderne mais HTTP/2 reste entièrement acceptable. La version que voit votre navigateur est la version que reçoivent vos visiteurs, donc le rapport reflète la performance réelle, pas la configuration théorique.