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 de laboratoire:outils tels que Lighthouse, dans lesquels 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 sur le terrain:outils tels que le rapport d'expérience utilisateur Chrome (CrUX), qui est basé sur des données globales provenant d'utilisateurs réels 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 connaître vos scores CrUX ne vous aidera probablement pas à 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 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'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 pouvez-vous capturer des informations de débogage pour les Core Web Vitals ou d'autres métriques de performances provenant d'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 Core Web Vitals actuelles et vous donne 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, la CLS est peut-être celle pour laquelle 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 la CLS du laboratoire (Lighthouse) par rapport à celle du terrain (données CrUX) est très différente. Cela est logique si vous considérez que la page peut contenir de nombreux contenus interactifs qui ne sont pas utilisés lors des tests dans Lighthouse.
Mais même si vous comprenez que l'interaction utilisateur affecte les données de champ, vous devez tout de même savoir quels éléments de la page sont en mouvement pour obtenir un score de 0,28 au 75e percentile. L'interface LayoutShiftAttribution rend cela possible.
Obtenir l'attribution de 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 la mise en page.
Pour obtenir une explication détaillée de ces deux interfaces, consultez la section Déboguer les décalages de mise en page. Pour les besoins de cet article, la principale chose que vous devez 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 plus mauvais et n'en générer que des rapports.
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 décalages qui affectent le plus grand nombre d'utilisateurs et qui contribuent donc le plus au CLS de votre page au 75e percentile.
De plus, vous n'avez pas besoin de calculer l'élément source le plus grand chaque fois qu'il y a un 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 le plus grand élément source 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 qui contribue le plus au CLS pour une page donnée varie probablement d'un utilisateur à l'autre, mais si vous agrégez ces éléments pour tous les utilisateurs, vous pourrez générer une liste des éléments en mouvement qui affectent le plus grand nombre d'utilisateurs.
Une fois que vous avez identifié et corrigé la cause du décalage pour ces éléments, votre code Analytics commencera à signaler les décalages plus petits comme les "pires" décalages pour vos pages. À terme, tous les décalages signalés seront suffisamment faibles pour que vos pages soient bien en dessous du seuil acceptable de 0,1.
Voici d'autres métadonnées qui peuvent être utiles à capturer avec l'élément source de décalage le plus important:
- Heure de la plus forte variation
- 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, voire courant, que l'élément candidat du LCP 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 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 le mesurer en fonction du comportement des utilisateurs réels.
Identifier l'élément candidat au LCP
Pour déterminer l'élément candidat pour le 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 du LCP.
Lorsque vous observez des 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 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 au LCP, il peut également être utile de mesurer les temps des sous-parties du LCP, ce qui peut vous aider à déterminer les étapes d'optimisation spécifiques 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 ce type d'interaction
- Quand cette interaction a eu lieu
Un thread principal bloqué est une cause majeure de lenteur des interactions, ce qui peut être courant lors du chargement de JavaScript. Savoir si la plupart des interactions lentes se produisent lors du chargement de la page est utile 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 les écouteurs d'événements enregistrés, ainsi que le temps nécessaire pour peindre le frame suivant 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 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 des 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 l'idée générale devrait également s'appliquer à d'autres outils d'analyse.
Ce code montre également comment créer 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).
La compilation d'attribution web-vitals expose des informations d'attribution supplémentaires, comme illustré dans l'exemple suivant pour l'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 tendances 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 résoudre, en particulier au début, 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 comment interroger et visualiser les données à l'aide de BigQuery.
Résumé
Nous espérons que cet article vous a permis de découvrir comment utiliser les API de performances existantes et la bibliothèque web-vitals pour obtenir des informations de débogage afin de 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 d'outils 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 enregistrer 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.