« Performance monitoring helps you see everything from macro-level metrics to micro-level spans, and adds context to help you identify the root cause of a performance problem » : la promesse de la documentation Sentry Performance s’est retrouvée directement mise à l’épreuve sur un projet e-commerce headless après que plusieurs visiteurs, via le formulaire de contact, ont signalé un site « lent » sans donner davantage de précision exploitable.
Ce cas ne détaille pas l’architecture globale du projet, déjà en place depuis plusieurs mois : il retrace uniquement la manière dont la trace de performance Sentry a permis de départager ce qui relevait du rendu front de ce qui relevait réellement de l’API WordPress consommée.
Le point de départ : une plainte, aucune piste
« Le site rame » ne dit rien sur la cause : cela peut venir du rendu React côté client, d’un appel réseau vers l’API WordPress, d’un service tiers embarqué dans la page, ou simplement de la connexion du visiteur. Sans instrumentation de performance, chaque hypothèse demande une investigation manuelle longue, souvent infructueuse faute de reproduire le problème en environnement de test.
Activer le traçage distribué
Le SDK @sentry/nextjs, une fois le traçage de performance activé via tracesSampleRate, capture automatiquement une trace pour chaque page servie, découpée en spans correspondant aux étapes du rendu : récupération des données côté serveur, hydratation côté client, requêtes réseau sortantes. Côté WordPress, le SDK PHP de Sentry propose une capacité équivalente, à condition d’être configuré pour honorer le même identifiant de trace transmis par le front dans l’en-tête sentry-trace.
// sentry.server.config.js (Next.js)
Sentry.init({
dsn: process.env.SENTRY_DSN,
tracesSampleRate: 0.2,
integrations: [new Sentry.Integrations.Http({ tracing: true })],
});Avec cette configuration, chaque appel fetch sortant vers l’API WordPress porte automatiquement l’en-tête sentry-trace, à condition que WordPress sache le lire et poursuivre la trace de son côté plutôt que d’en démarrer une nouvelle indépendante.
Ce que la trace a révélé
Une fois plusieurs traces collectées sur les pages signalées comme lentes, le tableau de performance Sentry a fait apparaître un schéma net : le rendu React côté client restait sous les 200 millisecondes dans tous les cas, mais un span spécifique, correspondant à l’appel wp/v2/produits avec le paramètre _embed, affichait un temps de réponse moyen de 2,1 secondes — bien au-delà des autres appels de la même page.
En creusant ce span spécifique côté WordPress, la trace PHP associée montrait qu’une grande partie du temps était consommée par la sérialisation d’un champ ACF de type relation, qui chargeait individuellement chaque produit associé via une boucle plutôt qu’une requête groupée — un schéma classique de requêtes en cascade, invisible sans instrumentation détaillée.
Le correctif appliqué
Le champ ACF en question a été réécrit pour charger l’ensemble des produits associés en une seule requête via WP_Query avec post__in, plutôt que d’appeler get_field individuellement dans une boucle. Le span correspondant est repassé de 2,1 secondes à 640 millisecondes en moyenne, un résultat directement mesurable dans le même tableau de bord Sentry, sur les traces suivantes.
Ce que cette expérience a changé dans l’équipe
- Une plainte vague de lenteur ne déclenche plus une recherche manuelle, mais une consultation directe des traces de performance associées à la page concernée.
- Les champs ACF de type relation font désormais l’objet d’une revue systématique de leur méthode de chargement avant mise en production.
- Le seuil
tracesSampleRatea été ajusté à la hausse temporairement après ce signalement, pour capturer davantage de traces pendant la période d’investigation.
Une plainte de lenteur, sans instrumentation, se transforme en devinette. Avec une trace de performance distribuée, elle devient une simple lecture de tableau de bord.
En résumé
Ce cas ne portait pas sur l’architecture globale du projet, mais sur un outil précis mis au service d’un diagnostic concret : relier une trace de performance front à son prolongement côté API a permis d’isoler, en quelques heures, un goulot d’étranglement qui serait resté invisible sans cette instrumentation distribuée entre les deux applications.
