• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

Collecte de données SPA

Ce document explique comment le navigateur collecte et stocke les données de votre application monopage asynchrone (SPA). Cela vous donnera une meilleure compréhension des données SPA que vous voyez dans l'UIdu navigateur. Cela vous aidera également à ajouter plus facilement un monitoring personnalisé avec l' API SPA.

Interaction Browser

Au cœur de monitoring des SPA se trouve le concept de browser interaction. New Relic définit une interaction avec le navigateur, autrement appelée navigation douce, comme la séquence d'événements suivante, s'inspirant de l'heuristique de Google:

  1. Une interaction utilisateur se produit. Nous recherchons spécifiquement click, keydown ou submit événement. L'événement popstate de l'API Historique lancera également une interaction.
  2. L'URL change de quelque manière que ce soit, que ce soit le chemin ou le hacher.
  3. Toutes les modifications, y compris celles apportées à l’attribut ou au texte du nœud, se produisent n’importe où dans l’arborescence DOM du document.

En suivant ces étapes, l'interaction avec le navigateur est considérée comme terminée lors de la prochaine image de repeinture. Ils associeront également requests XHR et de récupération démarrées dans leur intervalle. La v2.1 a introduit une autre étape :

  1. Pour la version SPA 2.1 et ultérieure, le moniteur vérifie les rappels de longue durée pendant un maximum de 5 secondes. Si un rappel de longue durée est identifié, le système étend l' interaction en cours et réexécute le moniteur.

l'interaction sera complètement terminée lorsqu'il y aura une période de 5 secondes sans aucune tâche longue. Pendant la période d'extension précédant la fin de la dernière tâche longue observée, toute AjaxRequest et JavascriptError qui se produisent seront également associées à l'interaction. Il est important de noter que la durée de l’interaction n’inclura pas les 5 dernières secondes d’inactivité.

Notez que l’étape quatre peut être court-circuitée ou contournée dans certains scénarios.

Conseil

Le déclencheur d'événement popstate est géré de manière unique par rapport aux autres déclencheurs d'événement d'interface utilisateur en raison de son comportement spécifique dans les navigateurs. Lorsqu'un événement popstate se produit dans les 500 millisecondes suivant un autre événement d'interface utilisateur comme un clic, il sera fusionné dans l'interaction existante initiée par cet événement, sans modifier le déclencheur d'origine de l'interaction (par exemple, « clic »). Cependant, deux événements popstate consécutifs ne seront jamais fusionnés de cette manière.

L'interaction avec popstate comme déclencheur provient généralement d'actions du navigateur, telles que l'utilisation du bouton Précédent ou Suivant, ou d'actions liées au code, telles que la modification programmatique de l'URL.

Types de reporting SPA des données

@@ -39,54 +38,39 @@ Trois grandes catégories de données d'applications à page unique peuvent être signalées à New Relic :

Chacun d’entre eux crée un événement BrowserInteraction . Si une ou plusieurs requests AJAX font partie d'une interaction, les événements AjaxRequest associés sont également créés. Ces événements et leurs attribut peuvent être requêtes dans le générateur de requêtes.

Important

L'interaction par défaut ou non personnalisée n'attend pas que requests réseau soient terminées. Ils sont associés à l'interaction sur une base telle quelle, ce qui signifie que seules requests terminées avant que l' interaction ne soit récoltée par le planificateur y sont liées. Si une demande réseau a une durée lente ou longue et démarre dans le cadre d'une interaction, elle peut se situer en dehors de cette fenêtre temporelle et ne pas être associée à l'interaction.

Vous pouvez également prolonger manuellement la durée d'une interaction pour vous assurer qu'elle reste ouverte jusqu'au retour d'une demande réseau importante à l'aide de l'API.

Chargement initial de la page

Un initial page load est un changement d'URL traditionnel, résultant d'un chargement ou d'un rechargement complet d'une URL. Ceci est indiqué dans le navigateur lorsqu'un événement de chargement de page se déclenche (l'événement window.onload ) et est également appelé navigation matérielle. Les chargements de page initiaux apparaissent avec les changements d'itinéraire dans l'interface utilisateur du navigateur.

Modifications d'itinéraire

Les utilisateurs de SPA expérimentent des changements d'itinéraire dynamiques de manière similaire aux chargements de pages. Les visiteurs d'un site ou d'une application ne se soucient généralement pas de savoir how une nouvelle vue leur a été fournie ; ils savent simplement que lorsqu'ils effectuent une action, une nouvelle vue apparaît. Pour cette raison, nous traitons les changements d'itinéraire de la même manière que les chargements de pages dans l'UI.

Afin de monitorer de manière optimale les applications monopages, nous commençons monitoring toute interaction qui pourrait théoriquement conduire à des changements d'itinéraire.

  • Si ces interactions ne terminent pas les étapes heuristiques définies ci-dessus, l'agent lance monitoring mais les abandonne ensuite.
  • Si ces interactions do suivent toutes les étapes, l'agent enregistre la séquence comme un événement BrowserInteraction terminé.

Une interaction est considérée comme un changement d'itinéraire et enregistrée en tant qu'événement BrowserInteraction si l'URL change entre le début et la fin. Les modifications d’URL sont suivies de deux manières :

  • L'événement popstate. La modification de l'URL par programmation, par exemple en définissant window.location.hash, déclenchera cet événement.
  • pushState ou replaceState est appelé. Les SPA utilisent généralement ces méthodes API d’historique pour mettre à jour l’URL.

Les modifications d'itinéraire apparaissent avec les chargements de page initiaux dans l' UIdu navigateur.

Notez que l'agent signale des fragments de hachage à partir des URL de changement d'itinéraire. Si vous utilisez hacher pour transmettre des données privées ou sensibles, ces données peuvent être visibles par l'utilisateur de votre compte New Relic. Pour plus d'informations sur la collecte et la création de rapports de données, consultez Sécurité du navigateur.

monitoringpersonnalisé

Toutes les applications sont différentes et ont des besoins monitoring différents. Vous pouvez utiliser l' API SPA pour personnaliser l'interaction de votre navigateur ou définir vous-même la manière dont elle est capturée.

événement personnalisé est enregistré sous BrowserInteraction événement et présente la différence d'attribut suivante :

  • L'attribut category aura la valeur Custom.
  • L'attribut trigger aura la valeur api. (Il s'agit de la valeur par défaut mais peut être modifiée avec l'API.)

L'API vous permet de déterminer quand démarrer et arrêter une telle interaction personnalisée, si l'heuristique ci-dessus ne correspond pas à votre base d'utilisateurs ou à votre application.

événement et attribut

Nous enregistrons les interactions du navigateur qui conduisent à des changements d'itinéraire et à des chargements de pages, ou qui sont créées via l'API, sous la forme d'événement BrowserInteraction et requests AJAX sous la forme d'événement AjaxRequest. Vous pouvez requêter ces événements dans le générateur de requêtes.

Droits d'auteur © 2025 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.