À quoi bon mesurer les performances de votre application si vous n’avez pas d’endroit centralisé pour consulter ces métriques ?

À rien, voilà la réponse.

Et c’est en même temps la raison pour laquelle OpenReplay a récemment ajouté la possibilité pour ses utilisateurs de créer des tableaux de bord personnalisés.

Grâce à ces tableaux de bord, les utilisateurs peuvent créer une visualisation unique où ils peuvent avoir un aperçu de l’état de toute leur application.

De plus, vous pouvez créer des tableaux de bord rien que pour vous ou pour toute votre équipe. Cela élimine ainsi le besoin de dupliquer les tableaux de bord si plus d’une personne en a besoin.

Voyons comment les utilisateurs peuvent faire cela.

Remarque : Si vous souhaitez un tutoriel rapide qui vous montre comment mettre en place un tableau de bord avec des métriques personnalisées, vous pouvez consulter cette vidéo YouTube.

Cliquez sur la section Dashboards du menu principal pour commencer.

Cliquez ensuite sur le bouton « Create Dashboard » qui vous fixe droit au milieu de l’écran :

Une fois que vous aurez cliqué dessus, toutes les métriques qu’OpenReplay capture à propos de votre application vous seront présentées.

Vous pouvez envisager ces métriques selon les catégories suivantes :

• Liées aux erreurs : ces métriques vous montreront les problèmes de votre application.
• Liées aux performances : avec ces métriques, vous pourrez évaluer dans quelle mesure votre application fonctionne bien pour vos utilisateurs.
• Liées aux ressources : les problèmes d’images qui ne se chargent pas, ou les ralentissements dus à des fichiers JavaScript trop volumineux sont le type de problèmes que vous repérerez avec ces métriques.
• Web Vitals : Ce sont les métriques utilisées par les moteurs de recherche comme Google pour déterminer la qualité d’une page/application web.
• Liées aux sessions : Ce sont des métriques sur les replays eux-mêmes, elles vous donnent une idée du trafic que reçoit votre application et du pourcentage que vous en capturez.

Voyons comment nos métriques peuvent être organisées au sein de ces groupes et ce que chacune signifie :

• Errors by Origin : nombre d’erreurs par jour réparties entre erreurs tierces et erreurs propres (les vôtres).
• Errors by Type : nombre d’erreurs classées par code de statut, JavaScript ou intégration avec d’autres services.
• Errors Per Domain : nombre d’erreurs (regroupées par domaine) pendant la période sélectionnée.
• Fetch Calls with Errors : Les appels/réponses fetch qui ont des codes 5xx-4xx.
• Sessions Affected by JS Errors : nombre de sessions par jour affectées par des erreurs JS.
• Top Domains with 4XX Fetch Errors : principaux domaines avec des erreurs de type Bad Request
• Top Domains with 5XX Fetch Errors : principaux domaines où les erreurs proviennent du côté serveur.
• Crashes : nombre de plantages par jour de votre application.

• CPU Load : la charge CPU moyenne par jour.
• DOM Build Time : le temps moyen nécessaire à la construction de tout le DOM de votre application, réparti dans le temps.
• Slowest Domains : Les domaines depuis lesquels les ressources les plus lentes (js, css, images) ont été téléchargées.
• Request Load Time : Le temps de réponse d’une requête http (fetch/xhr/axios).
• Response Time : le temps de réponse moyen aux requêtes envoyées par votre application.
• Memory Consumption : la consommation moyenne de mémoire sur tous les enregistrements de votre projet.
• Sessions impacted by Slow Pages : nombre de sessions où des pages lentes sont détectées chaque jour.
• Frame Rate : la réactivité moyenne de votre interface utilisateur.
• Page Load Time : le temps moyen qui s’écoule entre le moment où votre navigateur envoie la requête au backend et le moment où la page a fini de se charger.
• Pages Response Time : le temps moyen nécessaire à votre serveur pour renvoyer la réponse au navigateur.
• Pages Response Time Distribution : La distribution des temps de réponse (chargements) des pages afin que vous puissiez repérer

• Breakdown of Loaded Resources : nombre de ressources chargées par jour réparties entre CSS, images et scripts.
• Missing Resources : Images (principalement) ou polices ou icônes ou feuilles de style ou js qui n’ont pas pu être chargés et qui sont donc manquants. Cela signifie que les pages qui les affichent seront impactées.
• Resources Fetch Time : le temps moyen nécessaire au chargement des différentes ressources
• Slowest Resources : la liste des ressources les plus lentes avec leur temps de chargement associé.
• Image Load Time : le temps moyen nécessaire au chargement de vos images.
• Resources Loaded vs. Visually Complete : nombre de ressources chargées par rapport au temps nécessaire pour qu’elles soient chargées visuellement (comme les images, mais en tenant compte aussi des scripts et du CSS).
• Resources loaded vs. Response End : nombre de ressources chargées via XHR (et d’autres types de requêtes) par rapport au temps mis par le backend pour les livrer.

• Time to Interactive : le temps moyen nécessaire pour que votre interface utilisateur devienne complètement interactive (réactive aux entrées de l’utilisateur).
• Speed Index by Location : le temps moyen (par pays) nécessaire pour que le contenu visible de votre page se remplisse.
• First Paint : le temps moyen nécessaire au navigateur pour afficher le premier pixel de votre interface utilisateur.
• DOM Content Loaded : le temps moyen nécessaire pour que le document HTML initial se charge complètement et soit analysé par le navigateur (sans tenir compte des feuilles de style, des images et des sous-cadres).
• Time to Render : Le temps nécessaire au navigateur pour afficher le DOM chargé. Il serait bien de montrer la différence avec DOM Content Loaded.
• Time Till First Byte : le temps moyen nécessaire au navigateur de votre utilisateur pour recevoir le premier octet après avoir demandé une page.

• Captured Requests : le nombre de requêtes effectuées sur chaque session enregistrée.
• Captured Sessions : le nombre de sessions capturées pour un projet au fil du temps.
• No. of Visited Pages : le nombre moyen de pages visitées au cours d’une session.
• Sessions Per Browser : Combien de sessions ont été capturées pour un navigateur particulier (par ex. Chrome).
• Session Duration : la durée moyenne de session par jour pour votre projet.

Vous avez 40 métriques au choix, ce qui signifie que vous pouvez créer le type de tableau de bord dont vous avez besoin, quel que soit ce que vous recherchez.

Une fois la liste des métriques présentée, il vous suffit de cliquer sur celles que vous voulez, et une fois que vous les avez toutes, de cliquer sur le bouton « Create » situé dans le coin inférieur gauche de l’écran.

En plus des métriques prédéfinies présentées par la plateforme, vous pouvez créer les vôtres pour personnaliser entièrement le niveau de détail dont vous disposez à l’intérieur de vos tableaux de bord. Dans la même section Dashboards, au lieu de créer un nouveau tableau de bord, cliquez sur l’option Metrics sur le côté gauche de l’écran et choisissez « Create Metric ».

Donnez-lui un nom, dans mon cas je l’appellerai « Sessions from Spain » (vous verrez pourquoi dans une minute). Choisissez ensuite le type de métrique, vous avez :

• Timeseries : cela tracera le nombre de sessions qui correspondent aux critères de filtrage ci-dessous.
• Table of [option] : cela listera ce que vous sélectionnez pour « option » (cela peut être Users, Sessions, JS Errors, Issues, Browsers, Devices, Countries et URLs). Chaque élément de cette liste sera cliquable et vous pourrez en obtenir plus de détails.
• Funnels : cela créera un entonnoir basé sur les filtres que vous sélectionnez (consultez ce tutoriel pour comprendre comment tirer parti des entonnoirs).

Si vous souhaitez savoir comment travailler avec la liste JSErrors, consultez cet autre tutoriel.

Pour cet exemple, je vais créer une métrique qui liste toutes les sessions de la page du produit qui proviennent d’Espagne. Cela me permettra de voir rapidement combien de sessions j’obtiens dans la fenêtre temporelle choisie et, en même temps, je pourrai les reproduire d’un simple clic.

Vous pouvez dupliquer cette métrique et la filtrer par d’autres pays, de cette manière vous pouvez avoir un aperçu de qui accède à une section spécifique de votre site depuis différents pays et de la façon dont ils interagissent avec elle.

Par exemple, supposons que vous essayez de créer un tableau de bord simple qui affiche les indicateurs de lenteur pour comprendre d’où proviennent les problèmes liés à la lenteur. Et en plus de cela, vous voudrez ajouter la liste des personnes d’Espagne qui ont atteint la page produit de votre site de commerce électronique.

Vous opterez donc pour :

• Slowest resources
• Sessions impacted by Slow Pages
• Framerate
• Response time
• Time to Interactive
• Votre métrique personnalisée « Sessions from spain »

Selon votre cas d’usage, vous pourriez envisager d’en ajouter d’autres, mais pour cet exemple, ces métriques nous donneront une vue d’ensemble complète de ce que nous essayons de comprendre : si nos pages sont lentes et ce qui en est la cause. Le résultat devrait ressembler à ceci :

Les widgets que vous avez ajoutés peuvent être déplacés pour vous assurer de voir d’abord ceux qui vous intéressent le plus.

Vous pouvez également changer la fenêtre temporelle utilisée pour tracer ces métriques. Par défaut, comme vous pouvez le voir dans le coin supérieur droit du tableau de bord, ces widgets vous montrent les données des 7 derniers jours. Vous pouvez changer la plage temporelle pour :

• Today, qui ne vous montre que les données collectées jusqu’à présent aujourd’hui.
• Yesterday, qui vous montre un résumé de la veille.
• Past seven days, qui est l’option sélectionnée par défaut.
• Past 30 days, qui vous montre une plage temporelle plus large.
• Custom range, qui vous permet de sélectionner la plage temporelle que vous souhaitez.

Vous pouvez également continuer à ajouter des métriques au nouveau tableau de bord à l’aide du bouton « Add Metric » dans le coin supérieur gauche à côté du titre.

Vous pouvez créer autant de tableaux de bord que vous le souhaitez ; ils peuvent agir comme différentes vues de votre système et vous montrer un résumé intégré de ce qui se passe. Vous pouvez ensuite les utiliser pour filtrer les replays et comprendre ce qui se passe dans votre application.

Si vous rencontrez des problèmes pour configurer un tableau de bord personnalisé dans votre projet, contactez-nous sur notre communauté Slack et posez vos questions directement à nos développeurs !