Découvrez comment attribuer des informations de débogage aux données sur les performances afin d'identifier et de résoudre les problèmes d'utilisateurs réels grâce à Analytics.
Google propose deux catégories d'outils pour mesurer et déboguer les performances:
- Outils de l'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 bas de gamme).
- Outils pratiques:outils tels que le rapport d'expérience utilisateur Chrome (CrUX), basé sur des données utilisateur réelles et agrégées provenant de Chrome. Notez que les données réelles fournies par des outils tels que PageSpeed Insights et Search Console proviennent des données CrUX.
Bien que les outils de terrain fournissent des données plus précises (qui représentent en fait ce que les utilisateurs réels expérimentent), 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. Toutefois, connaître vos scores CrUX ne vous aidera pas à déterminer comment améliorer vos performances.
En revanche, Lighthouse identifie les problèmes et formule des suggestions d'amélioration spécifiques. Toutefois, Lighthouse ne fait des suggestions que pour les problèmes de performances qu'il détecte au moment du chargement de la page. Elle ne détecte pas les problèmes qui se manifestent uniquement à la suite d'une interaction de l'utilisateur, comme le défilement ou un clic sur les boutons de la page.
Cela soulève une question importante: comment collecter des informations de débogage pour les Signaux Web essentiels ou d'autres métriques de performances auprès 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 actuelles des Signaux Web essentiels. Il vous indique également comment capturer ces données dans votre outil d'analyse existant.
API pour l'attribution et le débogage
CLS
De toutes les métriques des Signaux Web essentiels, le CLS est peut-être celle pour laquelle la collecte des 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 (par exemple, quelle distance il la fait défiler, sur quoi il clique, etc.) peut avoir un impact significatif sur l'existence ou non de décalages de mise en page et sur les éléments qui se décalent.
Voici un rapport de PageSpeed Insights:
La valeur rapportée pour le CLS de l'atelier (Lighthouse) et le CLS du champ (données CrUX) sont assez différentes, ce qui est logique si vous considérez que la page comporte peut-être beaucoup de contenu interactif qui n'est pas utilisé lors des tests dans Lighthouse.
Toutefois, même si vous comprenez que l'interaction de l'utilisateur affecte les données réelles, vous devez tout de même savoir quels éléments de la page sont décalés, entraînant un score de 0,3 au 75e centile.
C'est possible grâce à l'interface LayoutShiftAttribution.
Obtenir l'attribution du décalage 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 la section Déboguer les décalages de mise en page. Pour les besoins de cet article, sachez 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 changements d'éléments.
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 décalage de mise en page qui se produit. Toutefois, en surveillant tous les décalages, vous pouvez suivre les pires changements et vous contenter de fournir des informations à 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 décalages qui affectent le plus grand nombre d'utilisateurs et qui contribuent donc le plus au CLS de votre page au 75e centile.
En outre, vous n'avez pas besoin de calculer le plus grand élément source à chaque changement. 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 l'élément source le plus grand après le 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 ayant contribué 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, mais si vous regroupez ces éléments pour tous les utilisateurs, vous serez en mesure de 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 des variations mineures, car elles correspondent aux "pires" variations pour vos pages. À terme, toutes les variations enregistrées seront suffisamment faibles pour que vos pages soient bien en deçà du "bon" seuil de 0,1.
Voici d'autres métadonnées qu'il peut être utile de capturer avec l'élément source de décalage le plus important:
- La période du plus grand ajustement
- Chemin de l'URL au moment du décalage le plus important (pour les sites qui mettent à jour l'URL de manière dynamique, tels que les applications monopages).
LCP
Pour déboguer le LCP sur le terrain, les principales informations dont vous avez besoin sont l'élément le plus grand (l'élément candidat au LCP) pour ce chargement de page particulier.
Notez qu'il est tout à fait possible (en fait, il est assez courant) que l'élément candidat au LCP diffère 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 donc différents éléments visibles dans la fenêtre d'affichage.
- Les utilisateurs ne chargent pas toujours les pages déroulantes jusqu'en haut. Souvent, les liens contiennent 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 sur la page.
- Le contenu peut être personnalisé pour l'utilisateur actuel. L'élément candidat au LCP peut donc varier considérablement d'un utilisateur à l'autre.
Cela signifie que vous ne pouvez pas supposer quel élément ou ensemble d'éléments sera l'élément candidat au LCP le plus courant pour une page spécifique. Vous devez la mesurer en vous basant sur le comportement d'utilisateurs réels.
.Identifier l'élément candidat au LCP
Pour déterminer l'élément candidat au LCP en JavaScript, vous pouvez utiliser l'API Largest Contentful Paint, qui est la même API que celle utilisée pour déterminer la valeur de temps LCP.
Lorsque vous observez des entrées largest-contentful-paint, vous pouvez déterminer l'élément 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 au 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 la durée des sous-parties LCP, ce qui peut être utile pour déterminer les étapes d'optimisation spécifiques pertinentes pour votre site.
FID
Pour déboguer le FID sur le terrain, il est important de garder à l'esprit qu'il ne mesure que la partie retard de la latence globale du premier événement d'entrée. Cela signifie que ce avec quoi l'utilisateur a interagi n'est pas vraiment aussi important que ce qui se passait sur le thread principal au moment de l'interaction.
Par exemple, de nombreuses applications JavaScript compatibles avec l'affichage côté serveur fournissent du code HTML statique qui peut être affiché à l'écran avant qu'il ne soit interactif avec les entrées utilisateur, c'est-à-dire avant la fin du chargement du code JavaScript requis pour rendre le contenu interactif.
Pour ces types d'applications, il peut être très important de savoir si la première entrée s'est produite avant ou après l'hydratation. S'il s'avère que de nombreuses personnes tentent d'interagir avec la page avant la fin de l'hydratation, envisagez d'afficher vos pages dans un état désactivé ou en cours de chargement plutôt que dans un état qui semble interactif.
Si le framework d'application expose le code temporel d'hydratation, vous pouvez le comparer à celui de l'entrée first-input pour déterminer si la première entrée s'est produite avant ou après l'hydratation. Si votre framework n'expose pas cet horodatage, ou n'utilise pas du tout l'hydratation, un autre signal utile peut être si une entrée s'est produite avant ou après la fin du chargement de JavaScript.
L'événement DOMContentLoaded se déclenche une fois que le code HTML de la page est entièrement chargé et analysé, ce qui implique l'attente du chargement des scripts synchrones, différés ou de module (y compris tous les modules importés de manière statique). Vous pouvez donc utiliser la chronologie de cet événement et la comparer au moment où le FID s'est produit.
Le code suivant observe les entrées first-input et consigne si la première entrée s'est produite avant la fin de l'événement DOMContentLoaded:
new PerformanceObserver((list) => {
const fidEntry = list.getEntries()[0];
const navEntry = performance.getEntriesByType('navigation')[0];
const wasFIDBeforeDCL =
fidEntry.startTime < navEntry.domContentLoadedEventStart;
console.log('FID occurred before DOMContentLoaded:', wasFIDBeforeDCL);
}).observe({type: 'first-input', buffered: true});
Identifier l'élément cible et le type d'événement du FID
Les autres signaux de débogage potentiellement utiles sont l'élément avec lequel l'utilisateur a interagi ainsi que le type d'interaction (par exemple, mousedown, keydown ou pointerdown). Bien que l'interaction avec l'élément lui-même ne contribue pas au FID (n'oubliez pas que le FID n'est que la partie de la latence totale de l'événement), il peut être utile de connaître les éléments avec lesquels vos utilisateurs interagissent pour déterminer la meilleure façon d'améliorer le FID.
Par exemple, si la grande majorité des premières interactions de l'utilisateur concernent un élément particulier, envisagez d'intégrer le code JavaScript nécessaire à cet élément dans le code HTML et de charger le reste de manière différée.
Pour obtenir le type d'interaction et l'élément associés au premier événement d'entrée, vous pouvez référencer les propriétés target et name de l'entrée first-input:
new PerformanceObserver((list) => {
const fidEntry = list.getEntries()[0];
console.log('FID target element:', fidEntry.target);
console.log('FID interaction type:', fidEntry.name);
}).observe({type: 'first-input', buffered: true});
INP
L'INP est très semblable au FID dans la mesure où les informations les plus utiles à capturer sont les suivantes:
- Avec quel élément a fait l'objet d'une interaction
- Pourquoi ce type d'interaction
- le moment où cette interaction a eu lieu ;
Comme le FID, l'une des principales causes de lenteur est le blocage du thread principal, ce qui peut être courant pendant le chargement de JavaScript. 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.
Contrairement au FID, la métrique INP prend en compte la latence totale 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 la trame suivante une fois que tous les écouteurs d'événements ont été exécutés. Cela signifie que pour INP, il est encore plus utile de savoir quels éléments cibles ont tendance à entraîner des interactions lentes, et quels sont les types d'interactions.
Étant donné que l'INP et le FID sont tous deux basés sur l'API Event Timing, la façon dont vous déterminez ces informations en JavaScript est très semblable à l'exemple précédent. Le code suivant consigne l'élément cible et l'heure (par rapport à DOMContentLoaded) de l'entrée INP.
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
const navEntry = performance.getEntriesByType('navigation')[0];
const wasINPBeforeDCL =
inpEntry.startTime < navEntry.domContentLoadedEventStart;
console.log('INP occurred before DCL:', wasINPBeforeDCL);
}
Notez que ce code ne montre pas comment déterminer quelle entrée event correspond à l'entrée INP, car cette logique est plus complexe. Cependant, 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 ci-dessus 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 supplémentaire (ou une dimension personnalisée) contenant une chaîne de débogage utile pour identifier l'origine des problèmes de performances.
import {onCLS, onFID, 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 'FID':
case 'INP':
eventParams.debug_target = attribution.eventTarget;
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);
Bien que ce code soit spécifique à Google Analytics, l'idée générale devrait également se traduire par d'autres outils d'analyse.
Ce code montre également comment générer des rapports sur un seul signal de débogage. Toutefois, il peut être utile de pouvoir collecter plusieurs signaux différents par métrique et de générer des rapports les concernant. Par exemple, pour déboguer l'INP, vous pouvez collecter le type d'interaction, l'heure, ainsi que l'élément avec lequel vous interagissez. Le build d'attribution web-vitals expose toutes ces informations, comme illustré dans l'exemple suivant:
import {onCLS, onFID, 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.eventTarget;
eventParams.debug_type = attribution.eventType;
eventParams.debug_time = attribution.eventTime;
eventParams.debug_load_state = attribution.loadState;
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 avec 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é ci-dessus, vous n'avez pas nécessairement besoin de résoudre tous les problèmes rencontrés par vos utilisateurs. Vous devez aborder, en particulier au début, ceux qui affectent le plus grand nombre d'utilisateurs, c'est-à-dire ceux qui ont le plus d'impact négatif sur vos scores Signaux Web essentiels.
Pour GA4, consultez l'article dédié sur l'interrogation et la visualisation des données à l'aide de BigQuery.
Résumé
Nous espérons que cet article vous a permis de comprendre comment utiliser les API Performance 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 dans le domaine. Bien que ce guide soit axé sur les Signaux Web essentiels, les concepts s'appliquent également au débogage des métriques de performances mesurables en JavaScript.
Si vous commencez tout juste à mesurer les performances et que vous utilisez déjà Google Analytics, le rapport "Signaux Web" peut constituer un bon point de départ, car il permet déjà de créer des rapports d'informations de débogage pour les métriques Signaux Web essentiels.
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é à être généralement applicable à tous les outils d'analyse. Toutefois, les outils d'analyse individuels peuvent (et doivent) capturer et rapporter encore plus d'informations de débogage.
Enfin, si vous pensez qu'il vous est impossible de déboguer ces métriques en raison de fonctionnalités ou d'informations manquantes dans les API elles-mêmes, envoyez vos commentaires à web-vitals-feedback@googlegroups.com.