Lorsque vous regardez un replay dans Session Replay, les détails de réseau vous permettent d'identifier les potentielles causes de friction dans l'expérience utilisateur (comme des requêtes lentes ou qui échouent par exemple).
Le graphique Waterfall des détails du réseau est une représentation chronologique du trafic réseau associé au chargement d'une page web, qui inclut toutes les requêtes HTTP envoyées par le navigateur, ainsi que toutes les requêtes supplémentaires effectuées pendant la vue de la page.
Principaux cas d'usage
Découvrez quelques-uns de nos cas d'usage les plus courants, ainsi que quelques suggestions sur comment les reproduire :
Découvrir l'origine d'une friction ou d'une frustration utilisateur
Lorsque vous regardez un replay, vous pouvez remarquer de la frustration utilisateur (tels que des clics de rage, des utilisateurs qui patientent trop longtemps ou des interfaces qui ne réagissent pas comme prévu).
La fonctionnalité des détails de réseau peut justement vous aider à identifier l'origine d'une frustration et à trouver quelles demandes connexes sont susceptibles d'avoir un impact à ce moment-là.
Comment reproduire le cas d'usage ?
Mettez simplement le lecteur de Session Replay en pause au moment où vous observez la frustration ou cliquez sur un évènement de friction spécifique (par exemple : un clic de rage) dans le flux d'évènements.
Ensuite, ouvrez les détails de réseau et regardez les requêtes qui sont survenues au même moment (la barre verticale est synchronisée en même temps pour les détails de réseau et le lecteur de Session Replay).
Les détails de réseau peuvent aussi vous aider à déterminer si une erreur s'est produite avant que notre tag ait pu charger. Si cela se produit, l'erreur n'est pas enregistrée par le tag. Avec les détails de réseau, vous pouvez voir tous les événements de ressources avant que le tag ne charge.
Voir comment les erreurs et les requêtes lentes impactent l'expérience utilisateur
En analysant les détails de réseau, vous pourrez identifier de potentiels impacts sur l'expérience de vos utilisateurs. Une erreur JS ou d'API peut avoir des conséquences : d'autres requêtes qui devraient normalement suivre peuvent disparaître, ou de nouvelles requêtes envoyées (pour collecter l'erreur, par exemple).
Avec les détails de réseau, vos équipes techniques seront en mesure de mieux évaluer l'impact d'une erreur.
Comment reproduire le cas d'usage ?
Si une erreur survient dans le script de chargement du carrousel, examiner les détails de réseau peut indiquer que les images du carrousel ne chargent pas.
Si une erreur 500 survient dans l'API de recommandations de produits tiers, les détails de réseau peuvent vous aider à voir qu'aucun appel ultérieur à l'API d'informations sur les produits de première partie n'a été envoyé pour récupérer les prix des produits recommandés.
Une fois les détails de réseau ouverts, vous pourrez voir lesquels ont échoué ou sont très longs. Vous pourrez ensuite voir le moment correspondant dans le lecteur de Session Replay pour comprendre comment ils ont affecté l'expérience utilisateur et décider d'analyser le phénomène plus avant avec votre équipe technique.
Comprendre quelles ressources affectent le chargement de la page de manière négative
Améliorer le temps de chargement de votre page (comme la métrique du Largest Contentful Paint (LCP)) peut s'avérer difficile si vous ne savez pas quoi améliorer.
La fonctionnalité des détails de réseau peut vous aider à facilement voir quelles ressources augmentent le temps de chargement de votre page.
Comment reproduire le cas d'usage ?
Vous pouvez créer un segment d'utilisateurs n'ayant jamais connu de LCP de moins de 2,5 secondes. Servez-vous ensuite de ce segment dans Session Replay pour visualiser des exemples de telles sessions.
Lorsque vous visionnez les vues de pages en question, ouvrez les détails de réseau et vérifiez les ressources en chargement au début de la vue de page. Vous comprendrez rapidement quelles ressources rallongent le temps de chargement.
Aperçu du Waterfall des détails de réseau
Accéder au Waterfall des détails de réseau
Lorsque vous visionnez un replay, cliquez sur le bouton "Ouvrir les détails de réseau" en bas du lecteur.
Pour redimensionner la vue du Waterfall, cliquez sur la barre de jonction bleue (encadrée en rouge dans l'image ci-dessous) et faîtes la glisser vers le haut/bas.
Timings
Cliquez sur "Timings" pour afficher/masquer les métriques de performance de la page. Cochez ou décochez les cases des métriques pour choisir lesquelles inclure dans le rapport du Waterfall sous forme de lignes verticales afin que vous puissiez les analyser avec les informations de trafic de réseau associées.
Notez que les timings des Core Web Vitals ne sont pas encore disponibles.
Personnaliser les colonnes
Cliquez sur "Personnaliser les colonnes" pour trier les colonnes que vous voulez voir apparaître. Vous pouvez choisir d'afficher les informations suivantes : URL, domaine, status, type, taille, protocole, schéma, heure et type d'initiateur.
Notez que la colonne du status (200, 301, 404, etc.) n'est disponible que pour les navigateurs Chrome et quand l'information n'est pas bloquée par les politiques de sécurité.
Filtres
Vous pouvez filtrer la colonne "URL" en saisissant des mots-clés dans le champ "Filtre d'URL" ou la colonne "Type" en sélectionnant le type de contenus que vous voulez afficher (par exemple : "Tous", "Document", "Feuille de style", etc).
Notez que "Websocket" est le seul filtre qui n'est pas disponible dans le Waterfall des détails de réseau de Session Replay.
Waterfall
Utilisez le Waterfall pour voir la liste séquentielle de toutes les requêtes HTTP.
Parmi les informations affichées par défaut, vous trouverez :
- l'URL : l'URL (nom de la ressource). Survolez le nom pour voir l'URL complète.
- le status : le status HTTP (200, 301, 404, etc.)
- le type : le type de contenu
- la taille : la taille de la réponse
- une barre de progression sur un axe de temps : cette dernière est synchornisée avec la timeline du replay, avec une décomposition des différentes étapes entre l'établissement de la connexion et la réception de la réponse.
Survolez une requête dans la colonne "Timings" pour voir la décomposition et le total des timings.
Requêtes commençant avant et après que le replay ne commence
Session Replay commence à enregistrer une session une fois le tag de tracking chargé. Les requêtes de détails de réseau sont collectées à partir du début de la vue de page. Ainsi, il est possible que certaines requêtes de données aient eu lieu avant le début du replay.
Dans le Waterfall des détails de réseau, vous pouvez voir la zone correspondant au replay grâce à un arrière plan hachuré sur la timeline et ainsi comprendre quelles requêtes se sont déroulées avant et après le replay.
FAQ
Pourquoi ne puis-je pas voir la taille du transfert pour mes requêtes ?
Il y a deux raisons à cela :
- La requête peut provenir d'un domaine cross-origine. Si c'est le cas, nous ne pourrons pas enregistrer sa taille.
- La requête peut déjà être dans le cache, ce qui implique que l'utilisateur n'a pas à charger la ressource.
Pourquoi ne puis-je pas voir la décomposition du timing des requêtes ?
Lorsqu'une requête vient d'un domaine cross-origine, les détails de timing ne sont pas accessibles. De plus, certaines informations, telles que la taille du transfert, ne peuvent pas être collectées.
Notez que la durée totale prend en compte le temps de blocage potentiel de la requête.
La fonctionnalité de détails de réseau dans Session Replay fonctionne-t-elle avec les applications à page unique (Single Page Applications ou SPA) ?
Avec les détails de réseau dans Session Replay, vous pouvez voir les ressources qui ont été chargées au cours des vues de pages de votre SPA.
Étant donné que les pages des SPA ne chargent pas comme des pages web "ordinaires", certaines requêtes ne pourront pas êtres vues (comme les requêtes de document par exemple).
Par ailleurs, les timings standards ne sont pas disponibles sur les vues de pages artificielles, car ils relèvent des timings de chargement de page naturelle.
Qu'est-ce-que le Blocking Time de ma requête que je vois dans la décomposition des timings ?
Lorsque vous chargez des ressources, les navigateurs n'ont qu'un nombre limité de connections ouvertes pour chaque origine. Ainsi, les ressources qui attendent d'être téléchargées sont bloquées jusqu'à ce qu'une connection soit disponible. C'est ce délai qu'on appelle le "Blocking Time".
Notez que temps total de la requête inclut le temps de blocage (ou Blocking Time).
Pourquoi les détails de réseau dans la timeline de Session Replay ne correspondent-ils pas à la timeline du replay de session ?
Vous avez peut être déjà remarqué que la barre verticale noire de la timeline des détails de réseau de Session Replay ne commence pas au même moment que la timeline de Session Replay, mais avant elle. Par exemple, si votre replay est à 5 secondes, vous avez peut-être remarqué que la barre verticale apparaît à 7 secondes sur la timeline des détails de réseau.
Cela s'explique par le fait que Session Replay commence à enregistrer à partir du moment où le tag est chargé sur la page.
En revanche, nous sommes en mesure de collecter les détails de réseau qui ont lieu avant que le tag ne soit complètement chargé.
C'est pour cela que le début de la timeline des détails de réseau commence avec les requêtes qui surviennent avant le début du replay.
Pourquoi certaines requêtes n'apparaissent-elles pas dans la timeline des détails de réseau ?
Si certaines requêtes n'apparaissent pas dans les détails de réseau, il peut y avoir plusieurs raisons :
- le tag peut commencer en retard et remplir la mémoire cache contenant les requêtes qui se sont produites auparavant (certaines requêtes seront donc manquantes)
- les limitations de l'API pour les redirections
- certaines ressources ne peuvent pas être collectées car elles viennent d'une iFrame.
- seules les requêtes de niveau réseau peuvent être enregistrées, ainsi une requête bloquée par une politique de sécurité de contenu (Content Security Policy ou CSP) ne sera pas visible.
- les redirections TBC
Puis-je accéder aux en-têtes ou à la charge utile ?
L'accès aux contenus des en-têtes ou de la charge utile est généralement impossible en raison de limitations de sécurité imposées par les navigateurs, site web ou API.
Je peux voir une erreur d'API dans le flux d'évènements mais elle n'apparaît pas comme une erreur dans la timeline des détails de réseau. Pourquoi ?
Cela peut se produire pour deux raisons :
- le navigateur web utilisé dans le replay n'est pas Google Chrome.
- il y a une restriction CORS (Access-Control-Allow-Origin) qui empèche la collecte des informations disponibles.