Application Real-Time Monitoring Service:Slow session tracing

Enable static resource reporting in the SDK

By default, the ARMS Browser Monitoring SDK does not report static resource data. To enable slow session tracing, set sendResource to true in the SDK config object:

<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>

Replace the pid value with your own application PID from the ARMS console.

After you redeploy the application, the SDK reports static resource timing data each time the page fires its onload event.

Data sampling thresholds

Enabling sendResource generates a large volume of telemetry. To limit overhead, ARMS samples data based on page load time:

Size shows 0 in the resource waterfall

The Size value comes from the PerformanceResourceTiming.transferSize browser API. It returns 0 in two cases:

• The resource was served from the browser cache.

• The resource is cross-origin and the server does not set a Timing-Allow-Origin header.

To verify, open Chrome DevTools (F12), go to the Network tab, and select Disable cache. Reload the page -- the transferSize values should appear.

Time shows 0 in the resource waterfall

The Time value comes from PerformanceResourceTiming.duration. It returns 0 when the browser serves the resource from a long-lived cache controlled by the max-age directive, because no network request occurs.

To confirm, open Chrome DevTools (F12), go to the Network tab, select Disable cache, and refresh. The timing values should populate.

Cross-origin resources return 0 for all timing fields

Due to the same-origin policy, the browser returns 0 for the following timing attributes on cross-origin resources:

redirectStart, redirectEnd, domainLookupStart, domainLookupEnd, connectStart, connectEnd, secureConnectionStart, requestStart, responseStart

To fix this, add a Timing-Allow-Origin header to the cross-origin resource response:

Timing-Allow-Origin: *

This grants any origin access to the resource timing data. For more granular control, specify individual origins instead of *.

API waterfall chart time range

The API waterfall chart covers the period from page load start to one minute after the page is fully loaded. It shows the overall status of API requests made during page loading.

API response time differs between waterfall charts

The response time in the API waterfall chart is typically a few milliseconds longer than in the resource waterfall chart because the two charts measure timing differently:

This difference is negligible and does not affect bottleneck analysis.

API waterfall chart timeline start point

The timeline origin in the API waterfall chart equals the difference between when the API sends a request and the page's fetchStart timestamp. This reveals when each API request fires relative to the page load lifecycle.