Un client s’est présenté un matin avec un rapport PageSpeed Insights affichant un TTFB de 1,8 seconde sur son site vitrine. Sa première question, légitime mais mal posée, était : « pourquoi WordPress est-il si lent ? ». Sauf que le site n’était pas un WordPress classique : c’était un front Next.js hébergé sur une plateforme d’edge, qui allait chercher son contenu via l’API REST d’un WordPress hébergé ailleurs. La question méritait d’être reformulée avant d’y répondre.
C’est l’un des pièges les plus fréquents quand on audite la performance d’un site découplé : le réflexe consistant à blâmer le CMS, alors que dans une architecture headless, WordPress n’est souvent qu’un maillon parmi plusieurs entre le clic du visiteur et l’affichage de la page. Comprendre cette chaîne est la condition pour ne pas optimiser le mauvais composant.
Ce que mesure vraiment le TTFB sur un site headless
Le Time To First Byte, tel que Chrome et Lighthouse le calculent, correspond au délai entre la requête HTTP du navigateur et la réception du premier octet de réponse. Sur un WordPress classique avec thème PHP, ce délai reflète directement le temps que met WordPress à générer le HTML : requêtes SQL, rendu des templates, plugins actifs. Sur un site headless, le navigateur ne parle jamais directement à WordPress. Il parle au serveur de rendu du front, qui lui-même va parfois interroger WordPress au moment de la requête, parfois sert une page déjà générée à l’avance, et parfois sert une page mise en cache par un réseau de diffusion de contenu.
Le TTFB mesuré par l’outil d’audit est donc celui du dernier maillon visible depuis le navigateur, pas celui de WordPress. Confondre les deux mène à des heures d’optimisation de plugins de cache WordPress qui n’ont, en réalité, aucun effet sur le chiffre affiché dans le rapport.
La méthode pour isoler le vrai goulot d’étranglement
Sur ce projet, la chaîne comptait quatre maillons : le CDN devant le front Next.js, le serveur de rendu Next.js lui-même (en mode SSR pour les pages dynamiques), l’API REST WordPress, et enfin la base de données MySQL. Pour savoir lequel ralentissait réellement le visiteur, la méthode a consisté à chronométrer chaque maillon indépendamment plutôt que de se fier au seul chiffre global.
- Chronométrage du CDN : en observant l’en-tête
x-vercel-cache(ou son équivalent chez d’autres hébergeurs), on distingue un HIT d’un MISS. Un MISS systématique sur une page censée être statique est le premier signal d’alerte. - Chronométrage du serveur de rendu : en ajoutant un en-tête personnalisé côté
getServerSidePropsmesurant le temps écoulé avant et après l’appel à l’API WordPress, on isole le temps de rendu pur du front. - Chronométrage de l’API REST : en interrogeant directement l’endpoint WordPress avec
curl -w "%{time_total}", sans passer par le front, on obtient le temps de réponse brut de WordPress. - Chronométrage de la base de données : via l’outil Query Monitor installé temporairement sur l’environnement de préproduction, pour repérer une requête SQL anormalement lente.
Le verdict sur ce projet
Le CDN renvoyait un MISS sur près de 40 % des requêtes, alors que la page en question était censée être statique et régénérée uniquement toutes les heures via l’ISR de Next.js. La cause : un paramètre de revalidation mal configuré combinait un revalidate: 0 hérité d’un composant copié-collé sur une autre route, qui désactivait involontairement le cache de la page. Le serveur de rendu recalculait donc la page à chaque visite, en interrogeant WordPress à chaque fois, alors que l’API elle-même répondait en 180 millisecondes en moyenne, un temps tout à fait correct.
Autrement dit, WordPress n’était responsable de rien. Le ralentissement venait d’une mauvaise configuration de revalidation côté Next.js, invisible sans ce découpage méthodique par maillon.
Un piège annexe : le cold start du serveur de rendu
Sur les plateformes serverless, un autre facteur peut fausser le diagnostic : le cold start. Si le serveur de rendu du front n’a pas reçu de requête depuis plusieurs minutes, la première requête qui arrive doit réinitialiser l’environnement d’exécution avant de répondre, ce qui ajoute parfois plusieurs centaines de millisecondes. Ce délai n’a rien à voir avec WordPress ni avec le code de l’application ; il dépend uniquement de la fréquence de trafic et de la politique de la plateforme d’hébergement.
Ce que cette méthode change dans la pratique
Depuis cet audit, sur les projets headless suivis, chaque page critique dispose désormais d’un en-tête de diagnostic exposant le temps de rendu front et le temps de réponse API séparément, visible uniquement en environnement de préproduction. Cela évite de rouvrir un débat stérile à chaque alerte de performance : la donnée est disponible immédiatement, sans reconstruire toute la chaîne d’hypothèses à chaque fois.
Un chiffre agrégé sans décomposition par maillon ne dit jamais où investir son temps d’optimisation ; il ne fait que confirmer qu’un problème existe quelque part dans la chaîne.
Pour aller plus loin
Sur un site headless, blâmer WordPress par défaut est un raccourci confortable mais souvent faux. La discipline à adopter consiste à cartographier sa propre chaîne de rendu avant tout audit de performance, puis à instrumenter chaque maillon séparément. Ce n’est qu’à cette condition que le TTFB affiché par un outil d’audit devient une donnée exploitable plutôt qu’un chiffre anxiogène sans action possible derrière.
