Slow session tracing

Prerequisites

The browser monitoring SDK of Application Real-Time Monitoring Service (ARMS) does not report static resource information loaded on the page by default. To obtain information about static resources loaded on the page and enable slow session tracing, set SendResource to True in the config file of the SDK. After the application is redeployed, when an onload event on the page is triggered, the information about static resources loaded on the current page is reported. Then, you can quickly locate slow page loading problems in ARMS browser monitoring.

The SDK configuration is as follows:

<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://retcode.alicdn.com/retcode/bl.js","__bl");
</script>

Note The reporting of static resource loading information is triggered during page onload, with a large amount of information reported. When the loading time is greater than 8s, the full report mode is used. If the loading time is within the range of 2s to 8s, 5% of the information is sampled and reported. If the loading time is less than 2s, no information is reported. We recommend that you do not set this parameter if your application requires high page performance.

Portal

In the left-side navigation pane, choose Browser Monitoring. On the Browser Monitoring page, find the target application and click the application name.
In the left-side navigation pane, choose Application > Session Traces.

Use case: locate page performance bottlenecks

The following example shows how to locate page performance bottlenecks.

In the left-side navigation pane, choose Application > Page Speed. The result is shown in the following figure. It took 36.7s to completely load the page at 11:00.
On the Page Speed page, scroll down the page to the Slow Page Session Trace (Top 20) section. This section lists the top 20 sessions with the lowest page loading speed within the specified period of time.

In the following figure, the page loading speed of a session at 11:36:46 is 36.72s. This access is the direct cause for the sharp increase in the page loading time.
In the Page column of the Slow Page Session Trace (Top 20) section, click a page name, and choose Session Traces > Session Details from the shortcut menu. The Page Resource Loading Waterfall section displays the waterfall chart for page static resource loading. You can use this waterfall chart to quickly locate the performance bottlenecks for resource loading.
Choose Session Traces > Session Details. In the Page Information section of the page that appears, you can view the client IP address, browser, operating system, and other information of the current access and locate the cause for slow session and optimize the page accordingly.

FAQ

Why is Size 0 on the resource loading waterfall chart?
Size is obtained by PerformanceResourceTiming.transferSize. The read-only attribute of transferSize indicates the size of the extracted resource in eight bits. If resources are obtained from the local cache or are cross-origin resources, the returned value of this parameter is 0.

Open the Chrome browser, press F12 to open the developer tool panel. When Disable cache on the Network tab is not selected, transferSize is 0.

Solution

Select Disable cache. Then, the actual value of transferSize is displayed.
Why is Time 0 on the resource loading waterfall chart?
Time is obtained by PerformanceResourceTiming.duration. On the static resource loading waterfall chart, Time is sometimes 0. The reason is that the request hits a long cache that is controlled by max-age.

Solution

Open the Chrome browser and press F12 to open the developer tool panel. Clear Disable cache on the Network tab and refresh the page. Then, the network access time is displayed.
Why is the returned value for Time 0?
The value of many time-related parameters returned by an API is 0. The reason is that the time point for obtaining the cross-origin resources is 0 due to the same-origin policy. The following attributes are involved:
- redirectStart
- redirectEnd
- domainLookupStart
- domainLookupEnd
- connectStart
- connectEnd
- secureConnectionStart
- requestStart
- responseStart
Solution

In the resource response header, add Timing-Allow-Origin, for example, Timing-Allow-Origin:*.
In which time range does the API loading waterfall chart show the API loading status?
The corresponding time range for API loading waterfall chart is as follows:
- Start time: the time when the page starts to load
- End time: full page loading time + 1 minute
The API loading waterfall chart shows the overall status of the requested API during page loading.
Why is the response time on the API loading waterfall chart different from that on the page resource loading waterfall chart?
The response time on the API loading waterfall chart is several milliseconds longer than that on the page resource loading waterfall chart, because the two values are obtained in different ways. Specifically, the response time on the API loading waterfall chart is the time consumed from the API sending a request to the API returning the data. The API response time on the page resource loading waterfall chart is obtained by calling performance.getEntriesByType('resource') provided by the browser.

The several-millisecond difference does not affect the troubleshooting of performance bottlenecks.
What is the start time of the timeline on the API loading waterfall chart?
The timeline start time of the API loading waterfall chart is the difference between the time when the API sends a request and the time when the fetchStart value of the page is returned. This timeline displays when the API sends the request and its response time.

Prerequisites

Portal

Use case: locate page performance bottlenecks

Other channels for detecting performance problems

FAQ

More information