Présentation

Les événements de vue RUM recueillent un large éventail de métriques de performance pour chaque vue de page. Surveillez les vues de page de votre application et explorez les métriques de performance dans les dashboards et le RUM Explorer.

Les métriques de performance de vos vues sont accessibles via les ressources suivantes :

• 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 quelle métrique 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 signaux Web essentiels de Google désignent trois métriques visant à surveiller l’expérience utilisateur d’un site. Ces métriques sont conçues pour vous offrir une vue globale des performances de chargement, de l’interactivité et de la stabilité visuelle. Une plage de valeurs correspondant à une expérience utilisateur acceptable est fournie pour chaque métrique. Nous vous conseillons de surveiller le 75e centile de ces métriques.

• Les métriques First Input Delay et Largest Contentful Paint ne sont pas recueillies pour les pages ouvertes en arrière-plan (par exemple, dans une fenêtre ou un nouvel onglet non actif).
• Les métriques recueillies à partir des vues de page de vos utilisateurs réels peuvent différer de celles calculées à partir des chargements de page d’un environnement contrôlé et fixe, comme celui des tests Browser Synthetic. La surveillance Synthetic considère les métriques Largest Contentful Paint et Cumulative Layout Shift comme des métriques expérimentales, et non réelles.

Éléments cibles des signaux Web essentiels

L’identification de l’élément ayant déclenché une métrique de signaux Web essentiels élevée est la première étape dans la compréhension de son origine et l’amélioration des performances. RUM transmet l’élément associé à chaque instance des signaux Web essentiels :

• 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 métriques de performance

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 une métrique de performance unique, loading_time, qui calcule le temps nécessaire au chargement d’une page. Cette métrique fonctionne pour les navigations 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.

Ajouter vos propres durées de performance

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 :

<html>
  <body>
    <img onload="window.DD_RUM.addTiming('hero_image')" src="/chemin/vers/img.png" />
  </body>
</html>

Ou de mesurer la durée avant que l’utilisateur ne commence à faire défiler la page :

document.addEventListener("scroll", function handler() {
    // 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.

Par exemple :

document.addEventListener("scroll", function handler() {
    // Supprimer l'écouteur d'événements afin de le déclencher qu'une seule fois
    document.removeEventListener("scroll", handler);

    const timing = 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:

Atelier interactif : signaux Web essentielsCENTRE D'APPRENTISSAGE Real User MonitoringBLOG Surveiller les signaux Web essentiels avec la surveillance Synthetic et la solution RUM de DatadogBLOG Explorer vos vues dans DatadogDOCUMENTATION Appliquer des visualisations sur vos événementsDOCUMENTATION En savoir plus sur les dashboards RUMDOCUMENTATION