4,1 secondes de LCP sur certaines pages d’un site média headless, contre 1,3 seconde sur le reste du site consommant pourtant la même API WordPress et le même composant de mise en page : cet écart, repéré dans le tableau de bord Core Web Vitals, ne pouvait pas s’expliquer par un problème global d’infrastructure, puisque la majorité des pages se comportait normalement.
L’enquête a porté sur la différence entre les pages concernées et les autres, plutôt que sur une recherche générale de lenteur. Sentry, déjà configuré pour capturer les métriques Core Web Vitals côté navigateur réel, a permis d’identifier précisément quelle ressource était désignée comme élément de Largest Contentful Paint sur les pages en question.
Symptôme : un LCP dégradé sur un sous-ensemble de pages
Le tableau de bord de performance ne montrait pas une dégradation uniforme, ce qui aurait pointé vers un problème d’infrastructure globale (CDN, serveur d’origine). La dégradation touchait spécifiquement les articles publiés via un ancien format d’import, migré depuis une plateforme précédente avant le lancement du site headless actuel.
Diagnostic : Sentry identifie la ressource fautive
La configuration Sentry côté client capturait déjà l’attribut element associé à chaque mesure de Largest Contentful Paint, révélant l’URL exacte de l’image désignée comme élément principal du rendu :
Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
integrations: [Sentry.browserTracingIntegration()],
tracesSampleRate: 0.3,
});
// Capture manuelle des Web Vitals avec contexte enrichi
import { onLCP } from 'web-vitals';
onLCP((metric) => {
Sentry.captureMessage(`LCP: ${metric.value}ms`, {
level: metric.value > 2500 ? 'warning' : 'info',
extra: {
element: metric.entries[0]?.element?.tagName,
url: metric.entries[0]?.url,
},
});
});
Les événements remontés pour les pages problématiques pointaient systématiquement vers des URL d’images hébergées directement sur le domaine WordPress d’origine, plutôt que vers le domaine du service d’optimisation d’images normalement utilisé par le reste du site.
Cause racine : un champ image resté hors du composant d’optimisation
Les articles migrés depuis l’ancienne plateforme stockaient leur image principale dans un champ personnalisé distinct du champ d’image mise en avant standard de WordPress, pour des raisons historiques liées au script de migration. Le composant next/image, utilisé partout ailleurs sur le site pour bénéficier du redimensionnement et de la conversion automatique au format WebP, n’était appliqué qu’au champ standard, laissant ce champ personnalisé rendu via une simple balise <img> classique, sans optimisation ni dimensionnement responsive.
| Type de rendu | Poids de l’image | Format servi |
|---|---|---|
| Champ standard via next/image | 48 Ko | WebP redimensionné |
| Champ personnalisé, balise brute | 1,4 Mo | JPEG original non redimensionné |
Correctif
Le composant de rendu d’article a été modifié pour toujours résoudre l’image principale à partir d’une fonction unique, quelle que soit son origine (champ standard ou champ hérité de la migration), garantissant qu’elle transite systématiquement par next/image :
function resoudreImagePrincipale(article) {
return article.imageMiseEnAvant?.url
?? article.acf?.image_migree_legacy?.url
?? null;
}
// Dans le composant :
<Image src={resoudreImagePrincipale(article)} width={1200} height={630} alt={article.titre} />
Prévention : un contrôle automatisé sur le champ d’origine
- Un script exécuté périodiquement recense les articles utilisant encore le champ hérité de la migration
- Chaque nouvel article passe par un contrôle de publication vérifiant la présence du champ image standard
- Un budget de poids maximal par image est vérifié en CI sur les nouvelles pages ajoutées
En résumé
Un LCP dégradé sur une partie seulement d’un site headless est rarement un problème d’infrastructure globale : c’est le signe d’un chemin de rendu différent entre deux catégories de contenu qui se ressemblent en apparence. La configuration précise des attributs additionnels dans Sentry a permis de localiser la ressource fautive en quelques minutes, là où une investigation manuelle page par page aurait pris des heures.
