Core Web Vitals sur des pages programmatiques : LCP, INP, CLS

Sur un site généré, la performance a une propriété que le contenu n'a pas : elle se corrige une fois, dans le gabarit, et le correctif s'applique instantanément à des milliers de pages. C'est le meilleur rapport effort-résultat de tout le projet.

Les trois métriques et leurs seuils

Ces seuils s'apprécient au 75^e centile des chargements, mesurés séparément sur mobile et sur ordinateur. Une page est considérée conforme lorsqu'elle atteint les trois seuils à ce centile — pas en moyenne, et pas sur une seule des deux plateformes.

LCP : ce qui le dégrade sur un gabarit

• Une image d'en-tête sans dimensions ni priorité. Sur un lot, c'est le même défaut répété sur toutes les pages.
• Des polices web chargées sans repli. Le texte reste invisible pendant le téléchargement.
• Un rendu côté client. Le plus grand élément n'apparaît qu'après l'exécution du JavaScript.
• Un temps de réponse serveur instable. Point traité dans la mise en cache CDN.

Les correctifs correspondants tiennent en quatre lignes dans le gabarit : dimensions explicites sur l'image principale, chargement prioritaire pour elle seule, font-display: swap, rendu côté serveur.

INP : le coût caché des scripts tiers

Sur une page de contenu, l'INP se dégrade rarement à cause du code propre au site. La cause dominante est l'accumulation de scripts tiers — mesure d'audience, bannière de consentement, widgets de partage, outils de heatmap — qui monopolisent le fil d'exécution principal.

Budget réaliste pour une page de blog :
  JavaScript propre au site   < 50 Ko compressé
  Scripts tiers               < 100 Ko compressé, chargés en différé
  Tâches longues (> 50 ms)    0 avant la première interaction

Un widget de suivi correctement écrit ne coûte presque rien : quelques kilo-octets, un envoi asynchrone, aucune manipulation du DOM au chargement. C'est un critère de sélection, pas un détail d'implémentation.

CLS : trois causes, trois correctifs définitifs

1. Images sans dimensions. Renseigner width et height dans le gabarit ; le navigateur réserve alors l'espace avant le chargement.
2. Contenu inséré au-dessus du contenu existant. Bandeaux, alertes, blocs de consentement : leur emplacement doit être réservé dès le rendu initial.
3. Polices provoquant un décalage. Choisir une police de repli dont les métriques sont proches de la police finale.

Sur un gabarit, ces trois correctifs sont appliqués une fois et le CLS de l'ensemble du lot passe généralement sous 0,05.

Mesurer sur un lot, pas sur une page

Tester une URL dans un outil de laboratoire donne une mesure synthétique, utile pour déboguer mais non représentative. Sur un lot programmatique, la mesure pertinente est celle des données de terrain agrégées par groupe de pages partageant le même gabarit.

La bonne pratique consiste à définir des groupes d'URL par motif — un groupe par famille de pages générées — et à suivre les trois métriques par groupe. Une dégradation apparaît alors comme une régression de gabarit, immédiatement attribuable au déploiement qui l'a introduite.

Garder la juste perspective

Les Core Web Vitals sont un critère de classement d'importance modérée : ils départagent des pages de pertinence comparable, ils ne compensent pas un contenu faible. Sur un projet programmatique, leur intérêt principal est ailleurs — un site rapide et stable est exploré plus profondément, ce qui agit sur le taux d'indexation, qui est le vrai facteur limitant.