Le responsable technique coche « Enable HTTP/3 » dans le CDN. Lighthouse gagne trois points. Le TTFB serveur, lui, n''a pas bougé : 890 ms sur la page panier. La direction conclut que « l''hébergement est lent ». En réalité, HTTP/3 optimise surtout le transport — pas la génération PHP ni une base surchargée.
HTTP/3 repose sur QUIC (UDP) plutôt que TCP. Il réduit les allers-retours de handshake, mieux résiste à la perte de paquets sur mobile et change de réseau (Wi‑Fi → 4G). C''est une évolution utile — pas une baguette magique pour un WordPress non mis en cache.
Ce que HTTP/3 améliore — et ce qu''il ignore
| Couche | HTTP/3 agit ? | Exemple |
|---|---|---|
| Handshake TLS + transport | Oui | Connexion plus rapide sur 4G instable |
| Multiplexage requêtes | Oui (comme h2) | Beaucoup de petits assets |
| TTFB PHP / SQL | Non | Page dynamique lente |
| Poids images / JS | Non | LCP élevé |
| DNS lent | Non | Résolution avant même QUIC |
Sur un site statique servi depuis un CDN proche, avec beaucoup de connexions courtes, HTTP/3 peut gratter 50–150 ms de latence perçue. Sur une API avec gros POST ou un admin WordPress en origine lente, l''effet est invisible.
Quand l''activer a du sens
Oui, activez si :
- TTFB origine déjà acceptable (< 400 ms dynamique ou cache efficace).
- Trafic mobile significatif, audience internationale.
- CDN gère QUIC sans config serveur complexe.
- Vous mesurez avec RUM avant/après.
Reportez si :
- OPcache off, pas de cache page, requêtes SQL lentes.
- Vous n''avez pas encore corrigé Core Web Vitals côté LCP/CLS.
- L''hébergeur annonce HTTP/3 mais force un proxy mal configuré (boucles, headers incohérents).
Déploiement typique : CDN vs origine
La majorité des sites actifs en HTTP/3 passent par un CDN :
- Visiteur ↔ edge QUIC (HTTP/3)
- Edge ↔ origine souvent encore HTTP/1.1 ou HTTP/2
L''hébergeur « supporte HTTP/3 » via son partenaire CDN, pas forcément sur le VPS nu. Vérifiez le contrat : terminaison TLS où, certificats, cache rules.
Test minimal :
curl --http3-only -sI https://example.com | head -5
Comparez --http2 et --http1.1 sur la même ressource statique.
Le sommet : optimiser le protocole avant l''application
Le marketing CDN adore la mention « HTTP/3 ready ». Elle ne remplace ni OPcache, ni index SQL, ni compression d''images.
Décider et avancer sans angle mort
- Mesurez TTFB origine et LCP actuels.
- Corrigez PHP, cache, assets si TTFB > 600 ms ou LCP rouge.
- Activez HTTP/3 via CDN ; comparez RUM mobile 7 jours.
- Documentez protocole edge vs origine pour le support.
Comparez les hébergeurs et CDN compatibles via l''annuaire et le comparateur.
Questions fréquentes
HTTP/3 est-il obligatoire en 2026 ?
Non — priorisez TTFB et contenu avant QUIC si le serveur est le goulot.
Mon mutualisé propose HTTP/3 : dois-je l''activer ?
Oui en toggle sans risque avec mesure ; non si cela évite un vrai diagnostic origine.
HTTP/3 sans CDN ?
Possible en origine (Nginx/Caddy), mais rare en pratique — la plupart passent par edge CDN.
Comment tester HTTP/3 ?
DevTools Protocol h3 ou curl --http3-only ; comparez à h2.
Avant de célébrer HTTP/3, une question : le TTFB origine est-il déjà vert ? Sinon, vous accélérez surtout une file d''attente PHP — pas le réseau.