Les événements de vue RUM collectent des données de télémétrie détaillées sur les performances pour chaque page vue. Surveillez les pages vues de votre application et explorez les données de télémétrie de performance dans les dashboards et le RUM Explorer.
Vous pouvez accéder aux données de télémétrie de performance de vos vues dans :
Les dashboards RUM prêts à l’emploi, qui offrent une vue d’ensemble des performances de votre application. Par exemple, dans le dahsboard Performance Overview, vous pouvez appliquer un filtre basé sur des attributs par défaut recueillis par la fonctionnalité RUM afin d’afficher les problèmes qui concernent un sous-ensemble d’utilisateurs. Vous pouvez également dupliquer ce dashboard, l’adapter à vos besoins et utiliser n’importe quelles données de télémétrie de performance RUM dans la requête du dashboard.
Un graphique en cascade, disponible pour chaque événement de vue RUM du RUM Explorer. Il vous permet d’analyser les performances associées à une vue de page en particulier. Vous pouvez ainsi visualiser l’impact des ressources de votre site Web, des tâches longues et des erreurs frontend sur les performances de vos utilisateurs finaux, et ce pour chaque page.
Durées des événements et signaux Web essentiels
Les données de télémétrie Core Web Vitals de Datadog sont disponibles à partir du package @datadog/browser-rum v2.2.0+.
Les Core Web Vitals de Google sont un ensemble de trois indicateurs clés (KPI) conçus pour surveiller l’expérience utilisateur d’un site. Ces KPI permettent d’avoir une vue sur les performances de chargement, l’interactivité et la stabilité visuelle. Chaque KPI est accompagné de recommandations sur les plages de valeurs correspondant à une bonne expérience utilisateur. Datadog recommande de surveiller le 75e percentile pour ces KPI.
Les KPI « Interaction to Next Paint » et « Largest Contentful Paint » ne sont pas collectés pour les pages ouvertes en arrière-plan (par exemple dans un nouvel onglet ou une fenêtre sans focus).
Les données de télémétrie collectées à partir des pages vues par vos utilisateurs réels peuvent différer de celles calculées pour des pages chargées dans un environnement fixe et contrôlé, comme un test de navigateur Synthetic. Synthetic Monitoring affiche Largest Contentful Paint et Cumulative Layout Shift comme des données de télémétrie de lab, et non comme des données réelles.
Nombre de mouvements de page inattendus causés par le chargement de contenu dynamique (par exemple, des publicités tierces). Lorsqu’aucun décalage ne se produit, cette métrique a pour valeur 0.
< 0,1
Éléments cibles des signaux Web essentiels
La première étape pour comprendre la cause d’un KPI Core Web Vitals élevé et améliorer les performances consiste à identifier l’élément qui l’a déclenché.
RUM indique l’élément lié à chaque instance de Core Web Vital :
Pour la métrique Largest Contentful Paint, RUM transmet le sélecteur CSS de l’élément correspondant au rendu du contenu principal.
Pour la métrique Interaction to Next Paint, RUM transmet le sélecteur CSS de l’élément associé à l’interaction la plus longue avant le rendu suivant.
Pour la métrique First Input Delay, RUM transmet le sélecteur CSS du premier élément avec lequel l’utilisateur a interagi.
Pour Cumulative Layout Shift, le service RUM transmet le sélecteur CSS de lʼélément le plus modifié contribuant au CLS.
Toutes les données télémétriques sur les performances
Attribut
Type
Rôle
view.time_spent
nombre (ns)
Temps passé sur la vue actuelle.
view.first_byte
nombre (ns)
Temps écoulé avant la réception du premier octet de la vue.
view.largest_contentful_paint
nombre (ns)
Moment dans la chronologie de chargement de page où l’objet DOM le plus volumineux est représenté dans la fenêtre d’affichage et est visible à l’écran.
view.largest_contentful_paint_target_selector
chaîne (sélecteur CSS)
Sélecteur CSS de lʼélément correspondant au rendu du contenu principal.
view.first_input_delay
nombre (ns)
Délai entre le moment où l’utilisateur interagit pour la première fois avec la page et le moment où le navigateur répond à cette interaction.
view.first_input_delay_target_selector
chaîne (sélecteur CSS)
Sélecteur CSS du premier élément avec lequel l’utilisateur a interagi.
view.interaction_to_next_paint
nombre (ns)
Durée la plus longue entre l’interaction d’un utilisateur avec la page et le rendu suivant.
view.interaction_to_next_paint_target_selector
chaîne (sélecteur CSS)
Sélecteur CSS de l’élément associé à l’interaction la plus longue avant le rendu suivant.
view.cumulative_layout_shift
nombre
Nombre de mouvements de page inattendus causés par le chargement dynamique de contenu (par exemple, des publicités tierces). Lorsqu’aucun décalage ne se produit, cette métrique a pour valeur 0.
view.cumulative_layout_shift_target_selector
chaîne (sélecteur CSS)
Sélecteur CSS de lʼélément le plus modifié contribuant au CLS de la page.
view.loading_time
nombre (ns)
Temps écoulé avant que la page ne soit prête et que toutes les requêtes réseau ou mutations DOM soient terminées. Pour en savoir plus, consultez la rubrique relative à la surveillance des performances des pages.
view.first_contentful_paint
nombre (ns)
Temps écoulé avant le premier affichage de texte, d’image (images d’arrière-plan incluses), de canvas non blanc ou de SVG. Pour en savoir plus sur l’affichage par le navigateur, consultez la définition du w3c (en anglais).
view.dom_interactive
nombre (ns)
Moment auquel le parser termine de travailler sur le document principal. Pour en savoir plus, consultez la documentation MDN.
view.dom_content_loaded
nombre (ns)
Cet événement se déclenche lorsque le document HTML initial a été entièrement chargé et parsé, même si les feuilles de style, les images et les sous-cadres qui ne bloquent pas l’affichage n’ont pas fini de charger. Pour en savoir plus, consultez la documentation MDN.
view.dom_complete
nombre (ns)
La page et toutes les sous-ressources sont prêtes. Pour l’utilisateur, l’indicateur de chargement à proximité du curseur a disparu. Pour en savoir plus, consultez la documentation MDN.
view.load_event
nombre (ns)
Cet événement se déclenche lorsque la page est entièrement chargée. Il entraîne généralement le déclenchement de logique d’application supplémentaire. Pour en savoir plus, consultez la documentation MDN.
view.error.count
nombre
Nombre total d’erreurs recueillies pour cette vue.
view.long_task.count
nombre
Nombre total de tâches longues recueillies pour cette vue.
view.resource.count
nombre
Nombre total de ressources recueillies pour cette vue.
view.action.count
nombre
Nombre total d’actions recueillies pour cette vue.
Surveillance d’applications monopages
Pour les applications monopages, le SDK Browser RUM différencie les navigations initial_load et route_change avec l’attribut loading_type. Si une interaction sur votre page Web redirige vers une nouvelle URL sans actualisation complète de la page, le SDK RUM initie un nouvel événement de vue avec loading_type:route_change. La solution RUM détecte les changements d’URL à l’aide de l’API History.
Datadog fournit un KPI unique, loading_time, qui mesure le temps nécessaire au chargement d’une page. Ce KPI s’applique à la fois à la navigation initial_load et route_change.
Méthode de calcul du temps de chargement
Pour assurer la compatibilité avec les applications Web modernes, le temps de chargement est calculé à partir des requêtes réseau et des mutations DOM.
Chargement initial : le temps de chargement est égal à la mesure la plus longue entre :
La différence entre navigationStart et loadEventEnd ; ou
La différence entre navigationStart et le premier moment sans activité sur la page. Lisez la rubrique Méthode de calcul de l’activité des pages pour en savoir plus.
Changement de route d’une application monopage : le temps de chargement correspond à la différence entre le moment où l’URL a changé et le premier moment sans activité sur la page. Lisez la rubrique Méthode de calcul de l’activité des pages pour en savoir plus.
Méthode de calcul de l’activité des pages
Le SDK Browser RUM suit l’activité des pages afin d’estimer la durée écoulée avant que l’interface ne soit à nouveau stable. À cette fin, on considère qu’une activité a lieu sur une page lorsque :
des requêtes xhr ou fetch sont en cours ;
le navigateur génère des entrées de durée de ressource de performance (fin de chargement de JS, CSS, etc.) ;
le navigateur génère des mutations DOM.
On estime qu’il n’y a plus aucune activité sur une page lorsqu’aucune activité n’a eu lieu pendant 100 ms.
Remarque : seules les activités qui ont lieu après l’initialisation du SDK sont prises en compte.
Avertissements :
Il est possible que, dans les scénarios suivants, la durée de 100 ms depuis la dernière requête ou mutation DOM ne permette pas de déterminer avec précision si des activités ont toujours lieu :
L’application recueille des données d’analyse en envoyant des requêtes à une API sur une base régulière ou après chaque clic.
L’application utilise des techniques de type « comet » (à savoir de diffusion ou d’interrogation longue) et la requête demeure en attente pendant une durée indéfinie.
Pour déterminer avec plus de précision si des activités sont en cours dans ces scénarios, définissez le paramètre excludedActivityUrls sur la liste des ressources que le SDK Browser RUM ne doit pas prendre en compte lors du calcul de l’activité des pages :
window.DD_RUM.init({...excludedActivityUrls:[// Exclure des URL précises
'https://third-party-analytics-provider.com/endpoint',// Exclure les URL se terminant par /comet
/\/comet$/,// Exclure les URL pour laquelle la fonction renvoie true
(url)=>url==='https://third-party-analytics-provider.com/endpoint',]})
Navigation par hash dans une application monopage
Le SDK RUM surveille automatiquement les frameworks qui reposent sur une navigation par hash (#). Il détecte les HashChangeEvent et génère une nouvelle vue. Les événements issus d’une ancre HTML n’affectent pas le contexte de la vue actuelle et sont ignorés.
Créer des données de télémétrie de performance personnalisées
Mesurer les performances au niveau des composants avec des indicateurs personnalisés
Utilisez l’API customVital pour mesurer les performances de votre application au niveau des composants. Par exemple, vous pouvez mesurer le temps nécessaire au rendu d’une partie de votre page ou à la réaction d’un composant à une interaction utilisateur. Remarque : les noms d’indicateurs personnalisés ne doivent pas contenir d’espaces ni de caractères spéciaux.
Démarrer et arrêter les mesures de durée
Démarrez une mesure de durée en appelant startDurationVital et arrêtez-la avec stopDurationVital :
Une fois la méthode stopDurationVital appelée, la durée de l’indicateur personnalisé est envoyée à Datadog et peut être interrogée avec @vital.name:dropdownRendering. Vous pouvez également filtrer par durée, par exemple avec @vital.duration:>10.
Utiliser des références et des descriptions
Utilisez la référence renvoyée par startDurationVital et indiquez une chaîne description pour différencier les instances d’un même indicateur personnalisé sur plusieurs pages. Par exemple, pour suivre la durée de dropdownRendering sur la page login :
Signaler un indicateur personnalisé avec addDurationVital
Plutôt que de définir les variables d’un indicateur personnalisé individuellement, vous pouvez le signaler en une seule opération avec addDurationVital :
Outre les durées de performance proposées par défaut par la solution RUM, il est possible de mesurer de façon flexible combien de temps votre application consacre à chaque tâche. Grâce à l’API addTiming, vous pouvez facilement ajouter des durées de performance supplémentaires.
Par exemple, il est possible d’ajouter le temps écoulé avant l’affichage de votre bannière :
Ou de mesurer la durée avant que l’utilisateur ne commence à faire défiler la page :
document.addEventListener("scroll",functionhandler(){// Supprimer l'écouteur d'événements afin de ne le déclencher qu'une seule fois
document.removeEventListener("scroll",handler);window.DD_RUM.addTiming('first_scroll');});
Une fois la durée envoyée, elle est accessible en nanosecondes via @view.custom_timings.<nom_durée> (p. ex., @view.custom_timings.first_scroll). Vous devez créer une mesure avant de pouvoir générer une visualisation dans le RUM Explorer ou dans vos dashboards.
Pour les applications monopages, l’API addTiming envoie une durée relative au début de la vue RUM actuelle. Par exemple, si un utilisateur accède à votre application (chargement initial), visite une autre page après 5 secondes (changement de route), puis déclenche enfin addTiming après 8 secondes, la durée est égale à 8-5 = 3 secondes.
Si votre configuration est basée sur une approche asynchrone, vous pouvez définir votre propre durée (sous forme de timestamp epoch UNIX) comme paramètre secondaire.
Exemple :
document.addEventListener("scroll",functionhandler(){// Supprimer l'écouteur d'événements afin de le déclencher qu'une seule fois
document.removeEventListener("scroll",handler);consttiming=Date.now()window.DD_RUM.onReady(function(){window.DD_RUM.addTiming('first_scroll',timing);});});
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles: