Découvrez comment attribuer vos données de performances à l'aide des informations de débogage. pour vous aider à identifier et à résoudre les problèmes réels des utilisateurs grâce aux données analytiques
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, une lenteur et un appareil mobile bas de gamme).
- Outils pratiques:outils tels que l'expérience utilisateur Chrome Rapport (CrUX), qui est basé sur des données utilisateur réelles et agrégées provenant de Chrome. (Notez que les données réelles rapportées par des outils tels que PageSpeed Tendances et Réseau de Recherche de la console. données CrUX).
Alors que les outils de terrain offrent des données plus précises, qui représentent réellement ce que l'expérience utilisateur réelle. Les outils de laboratoire sont souvent plus efficaces pour vous aider à identifier et à résoudre les problèmes de sécurité.
Les données CrUX sont plus représentatives des performances réelles de votre page, Il est peu probable que vos scores CrUX vous aident à déterminer comment améliorer votre des performances.
Lighthouse, quant à lui, identifie les problèmes des suggestions d'amélioration. Toutefois, Lighthouse ne fournit que des suggestions pour les problèmes de performances qu'il détecte lors du chargement de la page. Il ne détecte aucun problème. qui ne se manifestent que suite à une interaction de l'utilisateur, telle qu'un défilement ou un clic sur la page.
Cela soulève une question importante: comment capturer les informations de débogage Core Web Vitals ou d'autres métriques de performances provenant d'utilisateurs réels sur le terrain ?
Cet article explique en détail quelles API vous pouvez utiliser pour collecter des données des informations de débogage pour chacune des métriques Core Web Vitals actuelles, des idées sur la façon de capturer ces données dans votre outil d'analyse 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 celui 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, de sorte que la façon dont un utilisateur interagit avec (jusqu'à quel point ils font défiler l'écran, sur quoi ils cliquent, etc.) peuvent sur l'existence ou non de décalages de mise en page et sur les éléments qui le sont.
Prenons l'exemple du rapport PageSpeed Insights suivant:
Valeur du CLS du laboratoire (Lighthouse) comparée à celle du CLS du le domaine (données CrUX) sont très différentes, ce qui est logique si vous considérez que la page peut comporter beaucoup de contenu interactif qui n'est pas utilisé lors des tests dans Lighthouse.
Mais même si vous comprenez que l'interaction utilisateur affecte les données de terrain, vous besoin de savoir quels éléments de la page vont se déplacer pour obtenir un score de 0,28 au 75e centile. La méthode LayoutShiftAttribution rend tout cela possible.
Obtenir une attribution par décalage de mise en page
La méthode LayoutShiftAttribution
est exposée sur chaque entrée layout-shift qui présente une instabilité de mise en page.
de l'API Monitoring.
Pour une explication détaillée de ces deux interfaces, consultez Déboguer la mise en page. d'ajustements. Aux fins de ce post, la principale chose que vous devez savoir est qu'en tant que développeur, vous êtes capable pour observer chaque décalage de mise en page qui se produit sur la page, ainsi que les éléments sont en train de changer.
Voici un exemple de code qui enregistre chaque décalage de mise en page ainsi que les éléments qui a changé:
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 toutes les variations, peut suivre les pires changements et se contenter de communiquer 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 changements qui affectent le plus grand nombre d'utilisateurs et contribuent donc 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 vous ne devez le faire que lorsque vous êtes prêt à envoyer la valeur CLS à votre un outil d'analyse.
Le code suivant utilise 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 sera probablement différent de d'utilisateur à utilisateur, mais si vous regroupez ces éléments pour l'ensemble des utilisateurs, capable 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 votre code d'analyse commence à signaler les variations les plus faibles pour vos pages. À terme, tous les changements signalés seront que vos pages s'affichent bien dans le niveau de qualité seuil de 0,1.
Autres métadonnées qu'il peut être utile de capturer, en plus des variations les plus importantes l'élément source est:
- Date et heure du changement le plus important
- Chemin de l'URL au moment du changement le plus important (pour les sites qui l'URL, 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 était l'élément le plus important (élément candidat LCP) pour cet élément lors du chargement d'une page.
Notez qu'il est tout à fait possible, et c'est assez courant, que le LCP élément candidat varient d'un utilisateur à l'autre, même pour .
Plusieurs raisons sont possibles :
- Les appareils des utilisateurs ont différentes résolutions d'écran, ce qui entraîne des différences mises en page, et donc les 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 qui contiennent des identifiants de fragment ou même fragments de texte, ce qui signifie pour que vos pages soient chargées et affichées à n'importe quelle position de défilement sur la page.
- Le contenu peut être personnalisé en fonction de l'utilisateur actuel, c'est pourquoi l'élément candidat LCP peuvent varier considérablement d'un utilisateur à l'autre.
Cela signifie que vous ne pouvez pas faire d'hypothèses sur quel élément ou ensemble d'éléments sera l'élément candidat LCP le plus courant pour une page spécifique. Vous devez les 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 la fonction LCP l'API 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é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 au LCP, vous pouvez l'envoyer à votre outil d'analyse. ainsi que la valeur de la métrique. Comme pour le CLS, cela vous aidera à identifier sont les plus importants à optimiser en premier.
En plus de l'élément candidat LCP, il peut être utile de mesurer Les durées de sous-partie LCP, qui peuvent être utiles pour déterminer les étapes d'optimisation 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 lors du chargement de JavaScript. Déterminer si la plupart des interactions lentes survenant pendant le chargement de la page est utile pour déterminer les mesures à prendre le problème.
La métrique INP tient compte de la latence totale d'une interaction, y compris le temps nécessaire pour exécuter les écouteurs d'événements enregistrés en tant que et le temps nécessaire pour afficher l'image suivante après tous les écouteurs d'événements ont été exécutées. Cela signifie que pour INP, il est vraiment utile de savoir quelle cible ont tendance à ralentir les interactions et quels types d'interactions que ce soit.
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'INP
car cette logique est plus complexe. Toutefois, la section suivante explique
comment obtenir ces informations à l'aide du
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 à capturer des informations de débogage à inclure dans les données que vous envoyez à votre outil d'analyse.
Depuis la version 3, les fonctions web-Vitals La bibliothèque JavaScript inclut une attribution créer qui présente toutes ces informations, ainsi que quelques de données.
L'exemple de code suivant montre comment définir un événement supplémentaire paramètre (ou personnalisé ) contenant un chaîne de débogage utile pour identifier l'origine des problèmes de performances les problèmes de sécurité.
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 l'idée générale doit se traduire à d'autres outils d'analyse.
Ce code montre simplement comment générer un rapport sur un signal de débogage unique, Il est utile de pouvoir collecter plusieurs signaux différents et générer des rapports la métrique.
Par exemple, pour déboguer INP, vous pouvez collecter l'élément en cours interagi avec, le type d'interaction, l'heure, l'état de chargement, l'interaction et d'autres phases (comme les données de frame d'animation long).
Le build de l'attribution web-vitals présente des informations supplémentaires sur l'attribution,
comme indiqué 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);
Pour plus d'informations, reportez-vous à la section Attribution la documentation 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 les informations de débogage et les valeurs de 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, il n'est pas nécessairement nécessaire de traiter tous les problèmes que vos utilisateurs rencontrent, vous devez résoudre, en particulier dans un premier temps, les problèmes qui affectent le plus grand nombre d'utilisateurs, ce qui devrait aussi poser problème 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 dans BigQuery.
Résumé
Nous espérons que ce message vous a permis de découvrir comment utiliser les
les API Performance existantes et la bibliothèque web-vitals pour obtenir les informations de débogage
pour vous aider à diagnostiquer les performances en fonction des visites d'utilisateurs réels sur le terrain. Bien que cette
se concentre sur les métriques Core Web Vitals, les concepts s'appliquent aussi au débogage
les métriques de performances
mesurables en JavaScript.
Si vous commencez tout juste à évaluer les performances et que vous connaissez déjà Utilisateur de Google Analytics : l'outil de rapport "Signaux Web" peut être un bon point de départ car il accepte déjà la création de rapports d'informations de débogage pour Core Web Statistiques Android Vitals.
Si vous êtes un fournisseur de solutions d'analyse et que vous cherchez à améliorer vos produits à fournir davantage d'informations de débogage à vos utilisateurs, techniques décrites ici, mais ne vous limitez pas uniquement aux idées présentées ici. Ce message 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 générer des rapports encore plus d'informations de débogage.
Enfin, si vous pensez que votre capacité à déboguer ces métriques présente des lacunes fonctionnalités ou informations manquantes dans les API elles-mêmes, envoyez vos commentaires à web-vitals-feedback@googlegroups.com.