Déboguer les performances sur le terrain (attribution)
Attribuez vos données Core Web Vitals aux bons éléments grâce à la librairie web-vitals et identifiez les vraies causes côté utilisateurs.
Connaître ses scores Core Web Vitals ne suffit pas : encore faut-il savoir quoi corriger. Les outils de laboratoire comme Lighthouse identifient les problèmes visibles au chargement, mais ils ignorent tout ce qui dépend des interactions réelles : défilement, clics, contenus personnalisés. Or ces comportements influencent fortement le CLS et l’INP. La solution consiste à capter, sur le terrain, des informations de débogage en plus des valeurs de métriques. Elle suppose d’avoir d’abord mis en place une collecte fiable, comme expliqué dans notre guide pour mesurer les signaux Web sur le terrain.
Pour le SEO, cette attribution change tout : elle transforme un score abstrait en éléments concrets à corriger, ce qui accélère l’amélioration de l’expérience de page là où elle pèse vraiment sur vos utilisateurs.
Connaître son score ne dit rien sur ce qu’il faut corriger, et c’est précisément le mur sur lequel butent la plupart des projets. Lighthouse ne voit que le chargement, alors que le CLS et l’INP dépendent des interactions réelles, donc invisibles en laboratoire. Capturer des informations d’attribution sur le terrain, c’est ce qui transforme un score frustrant en plan d’action concret.
Quelles informations capturer par métrique
Chaque métrique demande des informations d’attribution spécifiques pour être déboguée efficacement. Le tableau ci-dessous récapitule l’API source et la donnée clé à collecter pour le CLS, le LCP et l’INP.
| Métrique | API d'attribution | Information clé à collecter |
|---|---|---|
CLS |
Layout Instability (LayoutShiftAttribution) |
L’élément le plus grand du décalage le plus important |
LCP |
Largest Contentful Paint |
L’élément candidat au LCP de ce chargement de page |
INP |
Event Timing |
L’élément ciblé, le type d’interaction et son horodatage |
Pourquoi l'élément varie d'un utilisateur à l'autre
Il est fréquent que l’élément responsable d’une métrique diffère selon les visiteurs, même sur une page identique. Pour le LCP, les résolutions d’écran changent la mise en page et donc l’élément visible, les liens peuvent pointer vers un fragment de la page, et le contenu peut être personnalisé. Pour le CLS, c’est la façon dont l’utilisateur fait défiler et interagit qui détermine les éléments décalés.
Vous ne pouvez donc pas deviner l’élément problématique : vous devez le mesurer auprès de vrais utilisateurs. L’objectif n’est pas de corriger chaque décalage individuel, mais d’identifier ceux qui affectent le plus grand nombre de visiteurs et pèsent le plus sur votre 75e percentile. En agrégeant ces éléments, vous obtenez une liste de priorités fiable, point de départ idéal pour optimiser le CLS là où il dégrade vraiment l’expérience.
La méthode simple : le build d'attribution de web-vitals
Observer manuellement chaque décalage ou chaque entrée de performance est possible, mais complexe et peu pratique. Depuis sa version 3, la librairie web-vitals propose un build d’attribution qui expose directement ces informations, ainsi que des signaux supplémentaires. L’exemple ci-dessous ajoute à chaque métrique un paramètre debug_target, une chaîne de sélecteur CSS qui pointe vers l’élément le plus pertinent.
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'CLS':
eventParams.debug_target = attribution.largestShiftTarget;
break;
case 'LCP':
eventParams.debug_target = attribution.element;
break;
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
break;
}
// Suppose que la fonction globale gtag() existe.
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);Agréger pour faire émerger les priorités
Une fois les informations de débogage collectées, agrégez-les sur l’ensemble de vos utilisateurs pour repérer les tendances. Vous n’avez pas à résoudre tous les problèmes : ciblez d’abord ceux qui touchent le plus de visiteurs, qui sont aussi ceux qui dégradent le plus vos scores. À mesure que vous corrigez les pires éléments, votre outil signalera des décalages de plus en plus faibles, jusqu’à passer durablement sous les seuils. Pour aller plus loin sur GA4, l’analyse via BigQuery permet d’interroger et de visualiser ces données.
L’élément le plus grand peut évoluer au fil du chargement de la page : identifier le candidat « final » demande de la rigueur. Le moyen le plus sûr est de s’appuyer sur la librairie web-vitals, qui détermine l’élément final correctement, plutôt que de réimplémenter cette logique à la main.
À faire
- collecter une cible de débogage par métrique
- utiliser le build d’attribution de web-vitals
- agréger les données pour prioriser
- corriger d’abord les éléments les plus fréquents
À éviter
- se fier au seul laboratoire pour déboguer le terrain
- supposer un élément LCP unique pour tous
- envoyer un rapport pour chaque décalage
- recalculer l’attribution manuellement
Points clés à retenir
- Les outils de laboratoire ne captent pas les problèmes liés aux interactions réelles.
- Collectez une cible de débogage pour le CLS, le LCP et l'INP.
- Utilisez le build d'attribution de la librairie web-vitals (version 3 et plus).
- Agrégez les données pour cibler les éléments qui touchent le plus d'utilisateurs.
- Laissez web-vitals déterminer l'élément candidat final au LCP.
Pour déboguer vos Core Web Vitals sur le terrain, gardez ces principes.
Quiz : testez vos connaissances
Quiz : testez vos connaissances
-
Pourquoi Lighthouse ne suffit-il pas pour déboguer les performances sur le terrain ?
- Il mesure trop d'interactions et noie les vrais problèmes
- Il ne fonctionne que sur mobile et fausse les mesures sur ordinateur
- Il ne détecte que les problèmes visibles au chargement et ignore les interactions réelles
Lighthouse n’observe que ce qui se passe au chargement. Il ignore les décalages et les interactions lentes provoqués par le comportement réel des visiteurs, comme le défilement ou les clics.
-
Pourquoi l'élément responsable du LCP peut-il différer d'un visiteur à l'autre sur une page identique ?
- Parce que les résolutions d'écran changent la mise en page et donc l'élément visible
- Parce que le navigateur choisit l'élément LCP de façon aléatoire
- Parce que l'élément LCP est toujours le même mais mesuré différemment
Les écrans n’ont pas la même taille, donc la mise en page et l’élément visible changent. Supposer un élément LCP unique pour tous les utilisateurs mène à de mauvaises priorités.
-
Quelle est la méthode simple recommandée pour collecter les informations d'attribution ?
- Recalculer l'attribution à la main après chaque déploiement
- Utiliser le build d'attribution de la librairie web-vitals, qui expose ces informations directement
- Observer manuellement chaque décalage et chaque entrée de performance
Depuis sa version 3, la librairie web-vitals propose un build d’attribution qui expose directement les informations de débogage, ce qui évite l’observation manuelle, complexe et peu pratique.
À propos de l'auteur
Besoin d'un accompagnement SEO ?
Vous voulez identifier les éléments qui plombent réellement vos Core Web Vitals ?