# « Le headless est toujours plus rapide » : ce que dément un audit de projets

> Un examen de plusieurs projets headless en production révèle des cas où le temps de chargement dépassait celui d'un thème WordPress classique bien optimisé.

- Auteur : WordPress Développement
- Publié le : 2024-03-04
- Mis à jour le : 2024-03-04
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/headless-toujours-plus-rapide-audit-projets/

## L’essentiel

- Un rendu entièrement côté client sans mise en cache peut être plus lent qu'un thème classique
- Les appels API séquentiels multiplient la latence perçue par le visiteur
- Un thème bien optimisé reste une référence de comparaison exigeante

« Le headless est toujours plus rapide qu'un thème classique. » Cette phrase, entendue régulièrement dans des présentations commerciales, mérite d'être confrontée à des mesures réelles plutôt qu'acceptée comme un principe général. Un examen de plusieurs projets headless en production, comparés chacun à un thème WordPress classique équivalent et correctement optimisé, révèle une réalité plus contrastée que l'affirmation de départ.

Sur l'échantillon observé, une majorité de projets headless affichait effectivement un temps de chargement perçu inférieur à leur équivalent en thème classique non optimisé. Mais la comparaison change de sens dès que le thème classique de référence bénéficie lui aussi d'un cache de page correctement configuré et d'images optimisées : dans ce cas, plusieurs projets headless se sont révélés plus lents, pas plus rapides.

## Premier cas observé : le rendu entièrement côté client sans mise en cache

Un projet construit avec un rendu entièrement exécuté dans le navigateur, sans génération statique ni cache de réponse API, oblige chaque visiteur à attendre le chargement du script JavaScript, puis l'exécution de ce script, puis l'appel réseau vers l'API WordPress, avant de voir apparaître le moindre contenu. Cette séquence, répétée à chaque visite sans qu'aucune étape ne soit mise en cache, peut aisément dépasser le temps d'affichage d'une page HTML générée côté serveur et servie depuis un cache de page classique.

## Deuxième cas observé : les appels API en cascade

Un composant front qui charge d'abord la liste des articles, puis déclenche un second appel pour récupérer l'auteur de chacun, puis un troisième pour les catégories associées, accumule une latence réseau à chaque étape séquentielle. Sur une connexion représentative, chaque aller-retour supplémentaire ajoute plusieurs dizaines à plusieurs centaines de millisecondes, un coût invisible dans un environnement de développement local mais très perceptible en conditions réelles.

> L'essentiel à retenir : Un rendu entièrement côté client sans mise en cache peut être plus lent qu'un thème classique ; Les appels API séquentiels multiplient la latence perçue par le visiteur ; Un thème bien optimisé reste une référence de comparaison exigeante

## Ce que ces cas ont en commun

Aucun de ces deux scénarios n'est une conséquence inévitable de l'architecture headless elle-même : les deux relèvent de choix d'implémentation évitables. Un front qui regroupe ses appels, met en cache ses réponses et privilégie un rendu préconstruit là où c'est possible n'a aucune raison structurelle d'être plus lent qu'un thème classique équivalent. Le problème observé dans l'audit ne se situe donc pas dans le principe du découplage, mais dans son exécution.

### Le thème classique bien optimisé, une référence exigeante

L'audit rappelle un point souvent minimisé dans les argumentaires commerciaux : un thème WordPress classique correctement mis en cache, avec des images compressées et un minimum de scripts bloquants, reste une référence de performance difficile à dépasser. Comparer un projet headless naissant, encore non optimisé, à ce standard établi conduit fréquemment à des conclusions défavorables au découplage, sans que cela ne remette en cause sa pertinence dans l'absolu.

- Vérifier systématiquement si le front regroupe ses appels API plutôt que de les enchaîner séquentiellement.
- Comparer un projet headless à un thème classique réellement optimisé, pas à une version non entretenue prise comme repoussoir.
- Mesurer le temps de premier affichage utile, pas seulement le temps de réponse brut de l'API sollicitée.

> Une architecture ne garantit jamais un résultat de performance à elle seule : elle définit seulement l'espace des optimisations possibles, que chaque projet doit ensuite exploiter ou négliger selon le soin apporté à son implémentation.

## Notre verdict

L'affirmation selon laquelle le headless serait systématiquement plus rapide qu'un thème classique ne résiste pas à un audit rigoureux mené sur des projets réels. La performance dépend presque exclusivement de la qualité d'implémentation de chaque couche du système, pas du choix architectural en lui-même. Présenter le découplage comme une garantie de rapidité, sans nuance, expose à une déconvenue mesurable dès la première comparaison sérieuse.