You are highly recommended to use SPA2 Monitoring for all SPA frameworks, especially Angular 1–5 and React. If you have questions about which SPA monitoring version to use, see Which SPA Monitoring to Use? for more information.
The following sections show you how to use SPA1 monitoring for AngularJS 1 applications and manually report events for Ember.js applications. This page also provides information about the AngularJS 1 support for SPA1 monitoring.
- IE 10 and Edge is supported. IE 10+ and Edge cannot be in compatibility mode with IE 9 or older browsers.
Manual Injection for Angular 1.x Applications
For non-Angular applications,
angular.js, but before
angular.js is bootstrapped.
To learn which Angular versions have monitoring support, see Monitoring Support for AngularJS.
Manual Injection for Ember.js Applications
Monitor Virtual Pages
When a user requests a new page, the route handler renders the associated template to form the new content of the virtual page. You can listen for events in the route handler indicating when the handler is started and completed, which in effect mark the lifetime of the virtual page. To monitor the virtual page, you start a Virtual Page Event when the
activate event is triggered, close the Virtual Page when the
deactivate event is triggered, and then report the completed virtual page.
The code snippet below listens to the
deactivate events and reports the created virtual page event.
Use Virtual Pages to Capture Errors
You can also create actions in the routing handlers that can be monitored through virtual pages. For example, you might want to monitor Ajax calls. You can create an action that performs the Ajax call and then use a Virtual Page event to capture the results and errors as shown in the code snippet below.
Monitoring Support for AngularJS 1
AngularJS 1 applications that have multiple Views use a route to move from one virtual page to another. You can use Browser RUM to instrument any virtual page that uses either of two routing engines,
Because virtual pages are constructed in the browser, normal page view metrics must be adjusted. In essence, what a metric for AngularJS 1 must do is correlate the time between various routing events, using their timestamps. Metrics are calculated as follows:
|Full Metric Name||Short Metric Name||Calculation|
|End User Response Time|
(not used for waterfall UI)
|HTML Download Time||DDT|
|HTML Download and DOM Building Time||DRT|
|DOM Building Time||DPT|
|DOM Ready Time|
(used instead of PLT for waterfall UI)
Because the two routing engines function in slightly different ways, what the AppDynamics event consists of differs slightly, based on the engine.
|AppDynamic Event Name||ngRoute Equivalent||ui-router Equivalent|
|load time of the last HTML fragment|
|response time of the last XHR requests|
|load time of the last resources|
|the latest one among |
Page Load Process Visualized
Visualized the page load process looks something like this:
Compare these to the standard page metrics, which are shown in Browser RUM Metrics.
Exclude Heartbeats or Background Requests from Timings
adrum.js, to the page:
Enable Resource Timing Collection for Virtual Pages
By default, Virtual Pages for AngularJS 1 do not include resource timing metrics. You need to set the Angular virtual page property
View Correlated Server Times
Since there isn't a regular HTML page timing to which correlated server timings can be linked, to view server times you must drill down from the Dashboard or Snapshot virtual page view to the component XHR requests. The server times can be seen there.