Découvrez comment attribuer vos données sur les performances avec des informations de débogage pour vous aider à identifier et à résoudre les problèmes rencontrés par les utilisateurs réels grâce aux données analytiques.
Google propose deux catégories d'outils pour mesurer et déboguer les performances :
- Outils de laboratoire : outils tels que Lighthouse, où votre page est chargée dans un environnement simulé pouvant imiter diverses conditions (par exemple, un réseau lent et un appareil mobile bas de gamme).
- Outils de champ : outils tels que le rapport sur l'expérience utilisateur Chrome (CrUX), qui est basé sur des données agrégées d'utilisateurs réels de Chrome. (Notez que les données de champ signalées par des outils tels que PageSpeed Insights et la Search Console proviennent des données CrUX.)
Bien que les outils de terrain offrent des données plus précises (qui représentent réellement l'expérience des utilisateurs), les outils de laboratoire sont souvent plus efficaces pour vous aider à identifier et à résoudre les problèmes.
Les données CrUX sont plus représentatives des performances réelles de votre page, mais il est peu probable que la connaissance de vos scores CrUX vous aide à déterminer comment améliorer vos performances.
Lighthouse, en revanche, identifiera les problèmes et vous proposera des suggestions spécifiques pour les résoudre. Toutefois, Lighthouse ne fera des suggestions que pour les problèmes de performances qu'il détecte au moment du chargement de la page. Il ne détecte pas les problèmes qui ne se manifestent qu'à la suite d'une interaction de l'utilisateur, comme le défilement ou le clic sur des boutons de la page.
Cela soulève une question importante : comment capturer les informations de débogage pour les Core Web Vitals ou d'autres métriques de performances auprès des utilisateurs réels sur le terrain ?
Cet article explique en détail les API que vous pouvez utiliser pour collecter des informations de débogage supplémentaires pour chacune des métriques actuelles des Core Web Vitals. Il vous donne également des idées sur la façon de capturer ces données dans votre outil d'analyse de données existant.
API pour l'attribution et le débogage
Cumulative Layout Shift (CLS)
Parmi toutes les métriques Core Web Vitals, le CLS est peut-être celle pour laquelle il est le plus important de collecter des informations de débogage sur le terrain. Le CLS est mesuré tout au long de la durée de vie de la page. Par conséquent, la façon dont un utilisateur interagit avec la page (la distance qu'il fait défiler, les éléments sur lesquels il clique, etc.) peut avoir un impact important sur la présence de décalages de mise en page et sur les éléments qui se décalent.
Prenons l'exemple du rapport suivant de PageSpeed Insights :
La valeur de la CLS indiquée par le laboratoire (Lighthouse) est très différente de celle indiquée sur le terrain (données CrUX). Cela est logique si l'on considère que la page peut contenir beaucoup de contenu interactif qui n'est pas utilisé lors des tests dans Lighthouse.
Mais même si vous comprenez que l'interaction de l'utilisateur affecte les données de champ, vous devez toujours savoir quels éléments de la page se déplacent pour obtenir un score de 0,28 au 75e centile. L'interface LayoutShiftAttribution permet d'y parvenir.
Obtenir l'attribution des décalages de mise en page
L'interface LayoutShiftAttribution est exposée sur chaque entrée layout-shift émise par l'API Layout Instability.
Pour obtenir une explication détaillée de ces deux interfaces, consultez Déboguer les changements de mise en page. Pour les besoins de cet article, la principale chose à savoir est que, en tant que développeur, vous pouvez observer chaque décalage de mise en page qui se produit sur la page, ainsi que les éléments qui se décalent.
Voici un exemple de code qui enregistre chaque décalage de mise en page ainsi que les éléments qui ont été déplacés :
new PerformanceObserver((list) => {
for (const {value, startTime, sources} of list.getEntries()) {
// Log the shift amount and other entry info.
console.log('Layout shift:', {value, startTime});
if (sources) {
for (const {node, curRect, prevRect} of sources) {
// Log the elements that shifted.
console.log(' Shift source:', node, {curRect, prevRect});
}
}
}
}).observe({type: 'layout-shift', buffered: true});
Il n'est probablement pas pratique de mesurer et d'envoyer des données à votre outil d'analyse pour chaque décalage de mise en page qui se produit. Toutefois, en surveillant tous les décalages, vous pouvez suivre les pires et ne signaler que les informations les concernant.
L'objectif n'est pas d'identifier et de corriger chaque décalage de mise en page qui se produit pour chaque utilisateur, mais plutôt d'identifier les décalages qui affectent le plus grand nombre d'utilisateurs et qui contribuent donc le plus au CLS de votre page au 75e centile.
De plus, vous n'avez pas besoin de calculer l'élément source le plus grand à chaque décalage. Vous ne devez le faire que lorsque vous êtes prêt à envoyer la valeur CLS à votre outil d'analyse.
Le code suivant prend une liste d'entrées layout-shift ayant contribué au CLS et renvoie l'élément source le plus grand du décalage le plus important :
function getCLSDebugTarget(entries) {
const largestEntry = entries.reduce((a, b) => {
return a && a.value > b.value ? a : b;
});
if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
const largestSource = largestEntry.sources.reduce((a, b) => {
return a.node && a.previousRect.width * a.previousRect.height >
b.previousRect.width * b.previousRect.height ? a : b;
});
if (largestSource) {
return largestSource.node;
}
}
}
Une fois que vous avez identifié l'élément le plus grand contribuant au décalage le plus important, vous pouvez le signaler à votre outil d'analyse.
L'élément qui contribue le plus au CLS d'une page donnée varie probablement d'un utilisateur à l'autre. Toutefois, si vous regroupez ces éléments pour tous les utilisateurs, vous pourrez générer une liste des éléments changeants qui affectent le plus grand nombre d'utilisateurs.
Une fois que vous aurez identifié et corrigé la cause première des décalages pour ces éléments, votre code Analytics commencera à signaler les décalages les plus petits comme étant les "pires" décalages pour vos pages. À terme, tous les changements signalés seront suffisamment petits pour que vos pages se situent bien en dessous du seuil de "bon" de 0,1.
Voici d'autres métadonnées qu'il peut être utile de capturer avec l'élément source du plus grand décalage :
- Heure du plus grand décalage
- Chemin de l'URL au moment du plus grand changement (pour les sites qui mettent à jour l'URL de manière dynamique, comme les applications monopages).
Largest Contentful Paint (LCP)
Pour déboguer le LCP sur le terrain, vous devez avant tout identifier l'élément le plus grand (l'élément candidat LCP) pour le chargement de page en question.
Notez qu'il est tout à fait possible, et même assez courant, que l'élément candidat au LCP soit différent d'un utilisateur à l'autre, même pour une même page.
Plusieurs raisons sont possibles :
- Les appareils des utilisateurs ont des résolutions d'écran différentes, ce qui entraîne des mises en page différentes et donc des éléments différents visibles dans la fenêtre d'affichage.
- Les utilisateurs ne chargent pas toujours les pages en les faisant défiler tout en haut. Les liens contiennent souvent des identificateurs de fragment ou même des fragments de texte. Cela signifie que vos pages peuvent être chargées et affichées à n'importe quelle position de défilement.
- Le contenu peut être personnalisé pour l'utilisateur actuel. L'élément candidat LCP peut donc varier considérablement d'un utilisateur à l'autre.
Cela signifie que vous ne pouvez pas faire d'hypothèses sur l'élément ou l'ensemble d'éléments qui seront les candidats LCP les plus courants pour une page donnée. Vous devez la mesurer en fonction du comportement réel des utilisateurs.
Identifier l'élément candidat LCP
Pour déterminer l'élément candidat LCP en JavaScript, vous pouvez utiliser l'API Largest Contentful Paint, la même API que celle que vous utilisez pour déterminer la valeur temporelle LCP.
Lorsque vous observez les entrées largest-contentful-paint, vous pouvez déterminer l'élément candidat LCP actuel en examinant la propriété element de la dernière entrée :
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});
Une fois que vous connaissez l'élément candidat LCP, vous pouvez l'envoyer à votre outil d'analyse avec la valeur de la métrique. Comme pour le CLS, cela vous aidera à identifier les éléments les plus importants à optimiser en premier.
En plus de l'élément candidat LCP, il peut également être utile de mesurer les temps des sous-parties LCP, qui peuvent être utiles pour déterminer les étapes d'optimisation spécifiques à votre site.
Interaction to Next Paint (INP)
Voici les informations les plus importantes à saisir dans le champ pour l'INP :
- L'élément avec lequel l'utilisateur a interagi
- le type d'interaction ;
- Quand cette interaction a eu lieu
Le blocage du thread principal est une cause majeure de lenteur des interactions, ce qui peut être fréquent pendant le chargement de JavaScript. Il est utile de savoir si la plupart des interactions lentes se produisent lors du chargement de page pour déterminer ce qui doit être fait pour résoudre le problème.
La métrique INP prend en compte la latence complète d'une interaction, y compris le temps nécessaire pour exécuter tous les écouteurs d'événements enregistrés, ainsi que le temps nécessaire pour peindre le prochain frame une fois que tous les écouteurs d'événements ont été exécutés. Cela signifie que pour l'INP, il est très utile de savoir quels éléments cibles ont tendance à entraîner des interactions lentes et de connaître les types d'interactions concernés.
Le code suivant enregistre l'élément cible et le temps de l'entrée INP.
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
Notez que ce code ne montre pas comment déterminer quelle entrée event est l'entrée INP, car cette logique est plus complexe. Toutefois, la section suivante explique comment obtenir ces informations à l'aide de la bibliothèque JavaScript web-vitals.
Utilisation avec la bibliothèque JavaScript web-vitals
Les sections précédentes proposent des suggestions générales et des exemples de code pour capturer les informations de débogage à inclure dans les données que vous envoyez à votre outil d'analyse.
Depuis la version 3, la bibliothèque JavaScript web-vitals inclut une compilation d'attribution qui fournit toutes ces informations, ainsi que quelques signaux supplémentaires.
L'exemple de code suivant montre comment définir un paramètre d'événement supplémentaire (ou une dimension personnalisée) contenant une chaîne de débogage utile pour identifier la cause première des problèmes de performances.
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;
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Ce code est spécifique à Google Analytics, mais l'idée générale devrait également s'appliquer à d'autres outils d'analyse.
Ce code montre également comment générer des rapports sur un seul signal de débogage, mais il est utile de pouvoir collecter et générer des rapports sur plusieurs signaux différents par métrique.
Par exemple, pour déboguer l'INP, vous pouvez collecter l'élément avec lequel l'utilisateur interagit, le type d'interaction, l'heure, l'état de chargement, les phases d'interaction et plus encore (comme les données sur les longs frames d'animation).
La version d'attribution web-vitals expose des informations d'attribution supplémentaires, comme illustré dans l'exemple suivant pour INP :
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 'INP':
eventParams.debug_target = attribution.interactionTarget;
eventParams.debug_type = attribution.interactionType;
eventParams.debug_time = attribution.interactionTime;
eventParams.debug_load_state = attribution.loadState;
eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
eventParams.debug_presentation_delay = Math.round(attribution.presentationDelay);
break;
// Additional metric logic...
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Pour obtenir la liste complète des signaux de débogage exposés, consultez la documentation sur l'attribution des Web Vitals.
Créer des rapports et visualiser les données
Une fois que vous avez commencé à collecter des informations de débogage en même temps que les valeurs des métriques, l'étape suivante consiste à agréger les données de tous vos utilisateurs pour commencer à rechercher des tendances et des schémas.
Comme mentionné précédemment, vous n'avez pas forcément besoin de résoudre tous les problèmes rencontrés par vos utilisateurs. Vous devez vous concentrer, surtout au début, sur ceux qui affectent le plus grand nombre d'utilisateurs et qui ont le plus d'impact négatif sur vos scores Core Web Vitals.
Pour GA4, consultez l'article dédié sur la manière d'interroger et de visualiser les données à l'aide de BigQuery.
Résumé
Nous espérons que cet article vous a aidé à comprendre comment utiliser les API de performances existantes et la bibliothèque web-vitals pour obtenir des informations de débogage qui vous aideront à diagnostiquer les performances en fonction des visites réelles des utilisateurs. Bien que ce guide se concentre sur les Core Web Vitals, les concepts s'appliquent également au débogage de toute métrique de performances mesurable en JavaScript.
Si vous êtes un fournisseur de solutions d'analyse et que vous souhaitez améliorer vos produits et fournir plus d'informations de débogage à vos utilisateurs, envisagez d'utiliser certaines des techniques décrites ici, mais ne vous limitez pas aux idées présentées ici. Cet article est destiné à s'appliquer de manière générale à tous les outils d'analyse. Toutefois, il est probable que les outils d'analyse individuels puissent (et doivent) capturer et signaler encore plus d'informations de débogage.
Enfin, si vous pensez que vous ne pouvez pas déboguer ces métriques en raison de fonctionnalités ou d'informations manquantes dans les API elles-mêmes, envoyez vos commentaires à l'adresse web-vitals-feedback@googlegroups.com.