Découvrez comment attribuer vos données de performances à l'aide d'informations de débogage pour vous aider à identifier et à résoudre les problèmes réels des utilisateurs grâce à Analytics.
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 de champ signalées par des outils tels que PageSpeed Insights et la Search Console proviennent de données CrUX.
Bien que les outils de terrain offrent des données plus précises (qui représentent réellement l'expérience utilisateur réelle), 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, quant à lui, identifiera les problèmes et fera 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 que suite à une interaction de l'utilisateur, telle que le défilement ou un 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 celle-ci (à quelle distance il fait défiler la page, sur quoi il clique, etc.) peut avoir un impact significatif sur les décalages de mise en page et sur les éléments concernés.
Prenons l'exemple du rapport PageSpeed Insights suivant:
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. C'est possible grâce à l'interface LayoutShiftAttribution.
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 enregistre 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 changement le plus important, 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 qu'il peut être utile de capturer avec le plus grand élément source de changement:
- Date et heure du changement le plus important
- Chemin de l'URL au moment du changement le plus important (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 dans le champ, l'information principale dont vous avez besoin est de quel élément particulier était le plus grand (élément candidat 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 différentes résolutions d'écran, ce qui entraîne des mises en page différentes et, par conséquent, différents éléments visibles dans la fenêtre d'affichage.
- Les utilisateurs ne chargent pas toujours les pages que l'on fait défiler jusqu'en haut. Souvent, les liens contiennent des identifiants de fragment, voire des fragments de texte, ce qui signifie que vos pages peuvent être chargées et affichées à n'importe quelle position de défilement sur la page.
- 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 émettre d'hypothèses sur l'élément ou l'ensemble d'éléments qui constituera l'élément candidat LCP le plus courant pour une page particulière. 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 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, Interaction to Next Paint)
Les informations les plus importantes à capturer dans le champ pour INP sont:
- Avec quel élément a fait l'objet d'une interaction
- Pourquoi le type d'interaction
- Quand cette interaction s'est produite
Le blocage du thread principal est l'une des principales causes de lenteur des interactions, ce qui peut être courant pendant le 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 afficher le frame suivant après l'exécution de tous les écouteurs d'événements. 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 enregistre 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);
onFID(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 INP, vous pouvez collecter l'élément avec lequel l'interaction est en cours, le type d'interaction, l'heure, l'état de charge, les phases d'interaction et d'autres éléments (tels que 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);
onFID(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 mentionné précédemment, vous n'avez pas nécessairement besoin de traiter tous les problèmes rencontrés par vos utilisateurs. Vous devez vous concentrer, en particulier dans un premier temps, sur les problèmes qui affectent le plus grand nombre d'utilisateurs, ce qui devrait également être les problèmes ayant 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 se concentre sur les métriques 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 utilisez déjà Google Analytics, le rapport Core Web Vitals est un bon point de départ, car il accepte déjà les 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 de manière générale à tous les outils d'analyse. Toutefois, chaque outil d'analyse peut (et devrait) collecter et signaler encore plus d'informations de débogage.
Enfin, si vous estimez que le débogage de ces métriques présente des lacunes en raison de fonctionnalités ou d'informations manquantes dans les API elles-mêmes, envoyez vos commentaires à [email protected].