Sur les forums techniques et les argumentaires commerciaux, l’idée revient régulièrement : une architecture headless serait par nature plus sobre, transférant moins de données qu’un thème WordPress classique. Cette affirmation mérite d’être vérifiée plutôt que reprise telle quelle, tant elle relève souvent davantage de l’intuition que d’une mesure réelle.
Une comparaison directe, menée sur un article de blog représentatif — texte, deux images, une poignée de métadonnées — entre une réponse HTML générée par un thème classique et la même donnée exposée sous forme de réponse JSON via l’API REST, permet de sortir du terrain des impressions.
Ce que transporte réellement chaque format
Une réponse JSON issue de /wp-v2/posts/ inclut, pour un article donné, non seulement le contenu texte, mais également l’ensemble des métadonnées associées au format attendu par le client : liens de navigation HATEOAS via le champ _links, contenu brut et rendu dupliqués pour certains champs, identifiants de taxonomies, informations sur l’auteur. Une bonne partie de ces données ne sera jamais affichée telle quelle par le front, qui les ignore simplement après réception.
Le HTML, lui, ne transporte que ce qu’il affiche
À l’inverse, une page générée côté serveur par un thème classique ne contient, en première approximation, que le balisage nécessaire à son propre affichage, sans redondance de champs non utilisés. Le gain en octets bruts, sur ce point précis, penche donc plutôt en faveur du rendu HTML traditionnel, à contenu équivalent.
Ce que l’architecture découplée gagne ailleurs
Le calcul ne s’arrête pourtant pas au premier échange. Un front headless bien conçu peut mettre en cache la réponse JSON une fois pour toutes, la transformer en page statique, puis la resservir depuis un réseau de diffusion de contenu sans jamais retourner interroger WordPress pour chaque visite. Un thème classique, lui, régénère potentiellement chaque page à chaque requête si aucune couche de cache serveur n’est en place.
| Scénario | Octets transférés au visiteur | Requêtes vers WordPress |
|---|---|---|
| Thème classique sans cache | Moyen | Une par visite |
| Thème classique avec cache de page | Moyen | Quasi nulle |
| Headless sans mise en cache du front | Élevé (JSON + rendu front) | Une par visite |
| Headless avec génération statique | Faible (HTML statique servi par CDN) | Quasi nulle |
La variable qui domine réellement : la stratégie de cache
Ce tableau révèle une conclusion plus nuancée que l’affirmation de départ : ce n’est pas la séparation entre l’API et le rendu qui détermine la sobriété d’une architecture, c’est la présence ou l’absence d’une stratégie de cache efficace, quel que soit le choix architectural. Un thème classique bien mis en cache peut transférer moins de données qu’un front headless mal optimisé qui recharge son JSON à chaque navigation côté client sans jamais persister le résultat.
Le cas particulier du rendu côté client
Un projet headless qui s’appuie sur un rendu entièrement côté client, sans génération statique ni rendu serveur, ajoute au poids du contenu celui du script JavaScript nécessaire pour l’interpréter et l’afficher, souvent plusieurs centaines de kilo-octets pour un environnement React ou Vue complet. Ce coût, invisible dans une comparaison qui ne porterait que sur la taille de la réponse API, doit être intégré à toute évaluation honnête du poids total transféré à chaque visite.
- Comparer le poids total de la page rendue, script inclus, pas seulement la taille de la réponse de l’API.
- Vérifier la présence effective d’une génération statique ou d’un cache de rendu côté front avant de conclure à un gain de sobriété.
- Mesurer sur un échantillon représentatif de pages, pas sur un seul article choisi pour l’exemple.
La sobriété d’un site ne se décrète pas au niveau de l’architecture choisie : elle se construit page après page, dans la manière dont chaque couche du système gère ou non son propre cache.
En résumé
L’affirmation selon laquelle une architecture découplée transfère nécessairement moins d’octets qu’un thème classique ne résiste pas à une mesure directe des formats bruts échangés. Le gain réel, quand il existe, provient presque toujours de la stratégie de mise en cache adoptée en aval, une variable indépendante du choix architectural lui-même et qui peut tout aussi bien s’appliquer à un thème WordPress classique bien configuré.
