Découvrez comment attribuer vos données de performances à des informations de débogage pour vous aider à identifier et à résoudre les problèmes des utilisateurs réels à l'aide d'analyses.
Google propose deux catégories d'outils pour mesurer et déboguer les performances :
- Outils d'atelier:outils tels que Lighthouse, où votre page est chargée dans un environnement simulé pouvant imiter différentes conditions (par exemple, un réseau lent et un appareil mobile d'entrée de gamme).
- Outils pratiques:des outils tels que le rapport d'expérience utilisateur Chrome (CrUX), qui est basé sur des données utilisateur réelles et agrégées provenant de Chrome. (Notez que les données sur le terrain signalées par des outils tels que PageSpeed Insights et la Search Console proviennent des données CrUX.)
Bien que les outils sur le terrain offrent des données plus précises (qui représentent réellement l'expérience des utilisateurs réels), 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 connaître vos scores CrUX vous aidera à déterminer comment améliorer vos performances.
Lighthouse, en revanche, identifie les problèmes et propose des suggestions spécifiques pour les améliorer. Toutefois, Lighthouse ne fournit des suggestions que pour les problèmes de performances détectés au moment du chargement de la page. Il ne détecte pas les problèmes qui ne se manifestent qu'en raison 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 des informations de débogage pour les métriques Core Web Vitals ou d'autres métriques de performances auprès d'utilisateurs réels sur le terrain ?
Ce post explique en détail les API que vous pouvez utiliser afin de collecter des informations de débogage supplémentaires pour chacune des métriques Core Web Vitals actuelles. Il vous donnera également des idées pour capturer ces données dans votre outil d'analyse existant.
API pour l'attribution et le débogage
Cumulative Layout Shift (CLS)
De toutes les métriques Core Web Vitals, le CLS est peut-être celui pour lequel la collecte d'informations de débogage sur le terrain est la plus importante. 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 de défilement, les éléments sur lesquels il clique, etc.) peut avoir un impact significatif sur la présence de décalages de mise en page et sur les éléments qui sont décalés.
Prenons l'exemple du rapport suivant de PageSpeed Insights :
La valeur indiquée pour le CLS de l'atelier (Lighthouse) et la CLS du domaine (données CrUX) sont assez différentes. Cela est logique si vous considérez que la page peut comporter de nombreux contenus interactifs qui ne sont pas utilisés lors du test dans Lighthouse.
Mais même si vous comprenez que l'interaction utilisateur affecte les données de champ, vous devez toujours savoir quels éléments de la page vont entraîner un score de 0,28 au 75e centile. L'interface LayoutShiftAttribution rend cela possible.
Obtenir une attribution par décalage de mise en page
L'interface LayoutShiftAttribution est exposée sur chaque entrée layout-shift émise par l'API d'instabilité de mise en page.
Pour en savoir plus sur ces deux interfaces, consultez la section Déboguer les décalages de mise en page. Pour les besoins de cet article, la principale chose à savoir est qu'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éplacent.
Voici un exemple de code qui consigne chaque décalage de mise en page, ainsi que les éléments qui ont été décalé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 changement de mise en page qui se produit. Toutefois, en surveillant tous les changements, vous pouvez suivre les pires changements et générer simplement des rapports à leur sujet.
L'objectif n'est pas d'identifier et de corriger chaque décalage de mise en page qui se produit pour chaque utilisateur. L'objectif est d'identifier les changements qui affectent le plus grand nombre d'utilisateurs et contribuent ainsi le plus au CLS de votre page au 75e centile.
De plus, vous n'avez pas besoin de calculer le plus grand élément source à 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 qui ont contribué au CLS et renvoie le plus grand élément source à partir du plus grand décalage:
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 important contribuant au plus grand décalage, vous pouvez le signaler à votre outil d'analyse.
L'élément contribuant le plus au CLS pour une page donnée variera probablement d'un utilisateur à l'autre. Toutefois, si vous regroupez ces éléments pour tous les utilisateurs, vous pourrez générer une liste d'éléments changeants affectant le plus grand nombre d'utilisateurs.
Une fois que vous avez identifié et corrigé la cause des variations de ces éléments, votre code d'analyse commence à signaler les variations les plus faibles en tant que variations les plus "mauvaises" sur vos pages. À terme, tous les changements signalés seront suffisamment faibles pour que vos pages se situent bien en-dessous du seuil "satisfaisant" (0,1).
Voici d'autres métadonnées qui peuvent être utiles à capturer avec l'élément source de décalage le plus important :
- Date et heure du changement le plus important
- Chemin d'URL au moment du plus grand changement (pour les sites qui mettent à jour dynamiquement l'URL, comme les applications monopages).
Largest Contentful Paint (LCP)
Pour déboguer le LCP sur le terrain, la principale information dont vous avez besoin est l'élément particulier qui était le plus grand (l'élément candidat au LCP) pour ce chargement de page particulier.
Notez qu'il est tout à fait possible, et c'est assez courant, que l'élément LCP candidat soit différent d'un utilisateur à l'autre, même pour la 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 de 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 que l'on fait défiler jusqu'en haut. Les liens contiennent souvent des identifiants de fragment ou même des fragments de texte, ce qui 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. Par conséquent, l'élément candidat LCP peut 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 sera l'élément candidat LCP le plus courant pour une page donnée. Vous devez la mesurer en fonction du comportement réel des utilisateurs.
Identifier l'élément candidat au 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 des entrées largest-contentful-paint, vous pouvez déterminer l'élément candidat LCP actuel en consultant 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 du 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 sous-parties du LCP, ce qui peut être utile pour déterminer les étapes d'optimisation spécifiques qui sont pertinentes pour votre site.
Interaction to Next Paint (INP)
Les informations les plus importantes à saisir dans le champ pour l'INP sont les suivantes :
- Élément avec lequel l'utilisateur a interagi
- Pourquoi le type d'interaction
- Quand cette interaction s'est produite
Un thread principal bloqué est une cause majeure de lenteur des interactions, ce qui peut être courant lors du chargement de JavaScript. Le fait de savoir si la plupart des interactions lentes se produisent lors du chargement de la page est utile pour déterminer les mesures à prendre 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 les écouteurs d'événements enregistrés, ainsi que le temps nécessaire pour peindre le frame suivant une fois tous les écouteurs d'événements exécutés. Cela signifie que pour INP, il est vraiment utile de savoir quels éléments cibles tendent à entraîner des interactions lentes et de quels types d'interactions il s'agit.
Le code suivant consigne l'élément cible et l'heure 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 un build d'attribution qui affiche toutes ces informations, ainsi que quelques signaux supplémentaires.
L'exemple de code suivant montre comment définir un paramètre d'événement (ou une dimension personnalisée) supplémentaire contenant une chaîne de débogage utile pour identifier l'origine 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 son principe général doit également se transposer à d'autres outils d'analyse.
En outre, ce code montre uniquement comment générer un rapport sur un seul signal de débogage, mais il est utile de pouvoir collecter et créer 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, le loadState, les phases d'interaction et plus encore (par exemple, les données de frame d'animation longue).
Le build d'attribution web-vitals présente 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);
Consultez la documentation sur l'attribution web-Vitals pour obtenir la liste complète des signaux de débogage exposés.
Créer des rapports et visualiser les données
Une fois que vous avez commencé à collecter des informations de débogage ainsi que les valeurs des métriques, l'étape suivante consiste à agréger les données de tous vos utilisateurs pour commencer à rechercher des modèles et des tendances.
Comme indiqué précédemment, vous n'avez pas nécessairement besoin de résoudre tous les problèmes rencontrés par vos utilisateurs. Vous devez surtout résoudre les problèmes qui affectent le plus grand nombre d'utilisateurs, qui devraient également être ceux qui ont le plus d'impact négatif sur vos scores Core Web Vitals.
Pour GA4, consultez l'article dédié sur la façon d'interroger et de visualiser les données à l'aide de BigQuery.
Résumé
Nous espérons que cet article vous a permis de mettre en avant les façons spécifiques d'utiliser les API de performances existantes et la bibliothèque web-vitals pour obtenir des informations de débogage et ainsi diagnostiquer les performances en fonction des visites d'utilisateurs réels sur le terrain. Bien que ce guide soit axé sur les Core Web Vitals, les concepts s'appliquent également au débogage de toute métrique de performances mesurable en JavaScript.
Si vous commencez tout juste à mesurer les performances et que vous êtes déjà un utilisateur de Google Analytics, l'outil de rapport sur les Web Vitals peut être un bon point de départ, car il permet déjà de générer des informations de débogage pour les métriques Core Web Vitals.
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 certaines des techniques décrites ici, mais ne vous limitez pas uniquement aux idées présentées ici. Cet article est destiné à s'appliquer à tous les outils d'analyse. Toutefois, les outils d'analyse individuels peuvent (et doivent) probablement capturer et générer encore plus d'informations de débogage.
Enfin, si vous pensez que vous ne parvenez 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.