Tous les produits
Search
Centre de documentation

Application Real-Time Monitoring Service:Traçage des sessions lentes

Dernière mise à jour :Aug 10, 2026

La fonctionnalité de traçage des sessions lentes fournit un diagramme en cascade (waterfall) qui visualise le chargement des ressources statiques sur votre page. Elle vous permet d'analyser les données de performance détaillées et d'identifier rapidement les goulots d'étranglement.

Prérequis

Important

Le rapport sur le chargement des ressources statiques se déclenche au chargement de la page et peut générer un volume de données important. Pour gérer ce volume, un échantillonnage basé sur le temps de chargement s'applique : toutes les données sont rapportées pour les chargements dépassant 8 secondes, 5 % sont échantillonnés pour les chargements entre 2 et 8 secondes, et aucun rapport n'est envoyé pour les chargements inférieurs à 2 secondes. Si votre application impose des exigences strictes en matière de performance, n'activez pas cette configuration.

  • Vous avez intégré Browser Monitoring. Pour plus d'informations, consultez Prise en main de Browser Monitoring.

  • Modifiez la configuration du SDK.

    Par défaut, le SDK ARMS Browser Monitoring ne rapporte pas les informations sur les ressources statiques. Pour utiliser la fonctionnalité de traçage des sessions lentes, définissez sendResource sur true dans la section config du SDK.

    <script>
    !(function(c,b,d,a){c[a]||(c[a]={});c[a].config={pid:"atc889zkcf@8cc3f6354******",imgUrl:"https://arms-retcode.aliyuncs.com/r.png?",sendResource:true};
    with(b)with(body)with(insertBefore(createElement("script"),firstChild))setAttribute("crossorigin","",src=d)
    })(window,document,"https://sdk.rum.aliyuncs.com/v1/bl.js","__bl");
    </script>
  • Redéployez votre application.

    Après le redéploiement de l'application, les informations sur les ressources statiques sont rapportées lorsque l'événement onload de la page est déclenché. Cela vous permet d'utiliser Browser Monitoring dans ARMS pour identifier rapidement les problèmes de lenteur au chargement des pages.

Point d'entrée

  1. Connectez-vous à la console ARMS. Dans le volet de navigation de gauche, choisissez Browser Monitoring > Browser Monitoring.

  2. Sur la page Browser Monitoring, sélectionnez une région dans la barre de navigation supérieure et cliquez sur le nom de l'application que vous souhaitez gérer.

  3. Dans le volet de navigation de gauche, choisissez Application > Session Tracing.

Cas d'utilisation : identification des goulots d'étranglement de performance

Cette section explique comment identifier un goulot d'étranglement de performance sur une page.

  1. Dans le volet de navigation de gauche, choisissez Application > Access speed. Le graphique affiche un temps de chargement complet de la page de 36,7 secondes à 11 h 00.

    页面加载时间详情

  2. Sur la page Access speed, faites défiler vers le bas jusqu'à la section Slow Page Session Trace (TOP20). Cette section répertorie les 20 sessions les plus lentes pour la page dans la plage horaire spécifiée.

    Pour modifier la plage horaire, cliquez sur le sélecteur de temps dans le coin supérieur droit de la page et choisissez une nouvelle plage dans la liste.

    Une session à 11 h 36 min 46 s affiche un temps de chargement de page de 36,72 secondes, identifiant cet accès comme la cause de l'augmentation soudaine du temps de chargement.

  3. Dans la section Slow Page Session Trace (TOP20), cliquez sur un nom de page dans la colonne Page.

    La page Slow Loading Details s'ouvre et affiche un diagramme en cascade des performances du chargement des ressources statiques, ce qui vous aide à localiser rapidement le goulot d'étranglement.

  4. Dans la section Page Information en haut de la page Slow Loading Details, examinez l'URL de la page, l'heure d'accès, le temps de chargement complet de la page, le temps d'analyse du DOM, l'adresse IP du client, le navigateur et le système d'exploitation. Utilisez ces informations pour déterminer si le problème est causé par des problèmes réseau ou d'autres facteurs et effectuez des optimisations ciblées.

Autres méthodes pour identifier les problèmes de performance

En plus de la page Access speed, vous pouvez également utiliser la page Session Tracing pour trouver des problèmes de performance.

  1. Dans le volet de navigation de gauche, cliquez sur Session Tracing pour ouvrir la page Session Tracing, qui répertorie les sessions de l'application. Vous pouvez également filtrer les sessions par nom d'utilisateur, ID utilisateur, ID de session, IP d'accès, URL de la page, navigateur, version du navigateur, type de réseau et région.

  2. Cliquez sur un ID dans la colonne Session ID pour ouvrir la page Session Details et afficher un résumé et un traçage pour la session. Pour plus d'informations, consultez Traces de session.

FAQ

  1. Pourquoi Size est-il égal à 0 dans le diagramme en cascade du chargement des ressources ?

    Les données Size proviennent de PerformanceResourceTiming.transferSize. La propriété en lecture seule transferSize représente la taille de la ressource récupérée en octets. Cette propriété renvoie 0 si la ressource est récupérée depuis le cache local ou s'il s'agit d'une ressource cross-origin.

    Dans le navigateur Chrome, appuyez sur F12 pour ouvrir les outils de développement. Si la case à cocher Disable cache de l'onglet Network n'est pas sélectionnée, la valeur de transferSize est 0.

    Solution

    Sélectionnez la case à cocher Disable cache. La valeur de transferSize est alors rapportée correctement.

    ▶ 1: PerformanceResourceTiming {initiatorType: "link", nextHopProtocol: "h2", workerStart: 0, …}
    ▶ 2: PerformanceResourceTiming {initiatorType: "link", nextHopProtocol: "h2", workerStart: 0, …}
    ▶ 3: PerformanceResourceTiming {initiatorType: "link", nextHopProtocol: "h2", workerStart: 0, …}
    ▼ 4: PerformanceResourceTiming
        connectEnd: 410.7099999964703
        connectStart: 410.7099999964703
        decodedBodySize: 232002
        domainLookupEnd: 410.7099999964703
        domainLookupStart: 410.7099999964703
        duration: 195.52999999723397
        encodedBodySize: 59637
        entryType: "resource"
        fetchStart: 410.7099999964703
        initiatorType: "script"
        name: "https://g.alicdn.com/cm-design/arms/1.2.81/scripts/arms/nls/messages_zh.js"
        nextHopProtocol: "h2"
        redirectEnd: 0
        redirectStart: 0
        requestStart: 514.6799999929499
        responseEnd: 606.2399999937043
        responseStart: 562.94999999227
        secureConnectionStart: 410.7099999964703
      ▶ serverTiming: []
        startTime: 410.7099999964703
        transferSize: 60043
        workerStart: 0
      ▶ __proto__: PerformanceResourceTiming
        transferSize: 60043
        workerStart: 0
      ▶ __proto__: PerformanceResourceTiming
  2. Pourquoi Time est-il égal à 0 dans le diagramme en cascade du chargement des ressources ?

    Les données Time proviennent de PerformanceResourceTiming.duration. Lorsque vous affichez le chargement des ressources statiques dans le diagramme en cascade, la valeur de Time est parfois égale à 0. Cela se produit parce que la requête atteint le cache et est contrôlée par une politique de cache à long terme utilisant max-age.

    Solution

    Dans le navigateur Chrome, appuyez sur F12 pour ouvrir les outils de développement. Sélectionnez la case à cocher Disable cache dans l'onglet Network et actualisez la page. Le temps consommé par les requêtes réseau s'affiche alors.

  3. Pourquoi de nombreuses valeurs de temps renvoyées sont-elles égales à 0 ?

    Vous remarquerez peut-être que de nombreuses valeurs d'API liées au temps sont égales à 0. Cela se produit car la stratégie same-origin définit les informations de timing pour les ressources cross-origin à 0. Cela affecte principalement les propriétés suivantes :

    • redirectStart

    • redirectEnd

    • domainLookupStart

    • domainLookupEnd

    • connectStart

    • connectEnd

    • secureConnectionStart

    • requestStart

    • responseStart

    Solution

    Ajoutez l'en-tête Timing-Allow-Origin à l'en-tête de réponse. Par exemple : Timing-Allow-Origin: *.

  4. Quelle période de temps le diagramme en cascade du chargement des API représente-t-il ?

    Le diagramme en cascade du chargement des API correspond à la période suivante :

    • Heure de début : moment où la page commence à se charger

    • Heure de fin : 1 minute après le temps de chargement complet de la page

    Le diagramme en cascade du chargement des API visualise toutes les requêtes API effectuées pendant le processus de chargement de la page.

  5. Pourquoi la durée dans le diagramme en cascade du chargement des API diffère-t-elle de celle du diagramme en cascade du chargement des ressources de la page ?

    La durée dans le diagramme en cascade du chargement des API peut être légèrement plus longue que dans le diagramme en cascade du chargement des ressources de la page. Cette différence s'explique par des modes de calcul distincts : le graphique API mesure le temps entre l'envoi de la requête et la réception de la réponse, tandis que le graphique des ressources de la page utilise l'API performance.getEntriesByType('resource') du navigateur.

    Cette légère différence de temps n'affecte pas votre capacité à identifier les goulots d'étranglement de performance.

  6. Que représente l'heure de début de la chronologie dans le diagramme en cascade du chargement des API ?

    L'heure de début de la chronologie dans le diagramme en cascade des API correspond à la différence entre le moment où une requête API est initiée et l'heure fetchStart de la page. Cette chronologie montre le point d'initiation et la durée de la requête API pendant le processus de chargement de la page.

Informations complémentaires