Un front qui multiplie les petites requêtes vers l’API REST d’un WordPress découplé n’a pas le même profil de trafic qu’un site classique qui charge une poignée de ressources par page. Une fiche produit peut déclencher, en cascade, un appel vers /wp/v2/produit/42, un autre vers /wp/v2/media/17 pour l’image principale, et deux ou trois appels supplémentaires pour les articles liés ou les avis clients. Comparer HTTP/2 et HTTP/3 sur ce profil de trafic donne des résultats plus nuancés que sur un site classique.
Ce que change réellement chaque protocole
HTTP/2, généralisé depuis plusieurs années sur la quasi-totalité des hébergements modernes, introduit le multiplexage : plusieurs requêtes voyagent en parallèle sur une seule connexion TCP, sans attendre la réponse de la précédente. C’est déjà un gain majeur par rapport à HTTP/1.1, qui limitait le navigateur à un petit nombre de connexions simultanées par domaine.
HTTP/3, basé sur le protocole de transport QUIC plutôt que sur TCP, va plus loin : il élimine le head-of-line blocking au niveau du transport lui-même. Avec HTTP/2, si un seul paquet TCP se perd sur le réseau, toutes les requêtes multiplexées sur cette connexion attendent sa retransmission avant de progresser, même celles qui n’ont rien à voir avec le paquet perdu. QUIC traite chaque flux de façon plus indépendante, ce qui limite l’effet d’un paquet perdu aux seules requêtes concernées.
Le protocole que reçoit réellement un appel REST
Encore faut-il que la chaîne complète du serveur au navigateur supporte le protocole visé. Un hébergement WordPress classique derrière Apache ou Nginx sans configuration spécifique sert le plus souvent en HTTP/2 ; HTTP/3 nécessite un serveur ou un CDN qui l’expose explicitement (Cloudflare, par exemple, l’active par défaut sur les domaines qu’il proxifie). Vérifier le protocole réellement utilisé se fait simplement depuis les outils de développement du navigateur, dans l’onglet réseau, colonne Protocol.
Comparatif mesuré sur un catalogue de fiches produit
Sur un projet de catalogue e-commerce découplé, cinq appels REST successifs ont été mesurés depuis un réseau mobile 4G avec une perte de paquets simulée de 2 %, une condition réaliste en zone de couverture moyenne :
| Scénario | Temps total (5 appels) | Effet d’une perte de paquet |
|---|---|---|
| HTTP/1.1 (référence) | 1 380 ms | Bloque toute la file de requêtes |
| HTTP/2 | 640 ms | Bloque les requêtes de la même connexion |
| HTTP/3 (QUIC) | 510 ms | N’affecte que le flux concerné |
L’écart entre HTTP/2 et HTTP/3 reste modeste sur un réseau fixe stable, mais se creuse nettement sur un réseau mobile sujet aux pertes de paquets, ce qui correspond justement au contexte d’un visiteur qui consulte un catalogue depuis son téléphone en mobilité.
Ce que le protocole ne compense pas
Aucun des deux protocoles ne remplace une bonne stratégie applicative. Regrouper cinq appels REST en un seul, via une route personnalisée qui agrège les données nécessaires à une fiche produit, réduit davantage la latence que le simple passage d’un protocole à l’autre. Le protocole de transport agit sur la façon dont les requêtes voyagent ; il ne réduit jamais leur nombre.
- Une route REST personnalisée qui combine produit, image et avis en une seule réponse reste plus efficace qu’un gain de protocole seul.
- Le cache HTTP (en-têtes
Cache-Control) et un CDN devant l’API restent les leviers les plus déterminants sur les visites répétées. - HTTP/3 profite surtout aux visiteurs sur réseau instable ; sur fibre ou Wi-Fi stable, la différence avec HTTP/2 devient difficile à percevoir.
Verdict argumenté
Pour un front headless dont l’audience se connecte majoritairement en fixe, activer HTTP/3 apporte un gain réel mais rarement décisif : HTTP/2, déjà largement déployé, couvre l’essentiel du besoin de multiplexage. Pour un projet dont une part significative du trafic provient de réseaux mobiles ou de zones mal couvertes, notamment un catalogue consulté en boutique ou un service consulté en extérieur, HTTP/3 justifie clairement l’effort de configuration, souvent limité à l’activation d’une option chez l’hébergeur ou le CDN plutôt qu’à un changement de code applicatif.
En résumé
Le choix entre HTTP/2 et HTTP/3 pour un front très découplé ne se tranche pas dans l’absolu : il dépend du profil réseau de l’audience visée. Dans les deux cas, réduire le nombre d’appels REST par une agrégation applicative reste le levier le plus rentable, le protocole de transport ne faisant que limiter les dégâts d’un réseau imparfait plutôt que supprimer le besoin de requêtes bien conçues.
