On this page:
Web applications built using Single Page Application (SPA) principles minimize network traffic by transferring to the browser itself much of the computing work for creating what the user sees. The initial page request downloads everything that is necessary for constructing all aspects of the application, with the possible exception of some data, including html partials and fragments, that may be fetched dynamically from the back-end in response to user interaction.
Your Rating:
Results:
53
Browser RUM supports virtual pages created using the AngularJS framework, sometimes known simply as Angular. The individual Views (a meaningful non-transient UI presentation) that the user sees are referred to as virtual pages. In AngularJS, a virtual page is comprised of the rendered template of the current route in the context of the main layout file.
Instrumentation Support for AngularJS
The JavaScript Agent supports instrumentation by default for AngularJS versions 1.x. For Angular versions 2 and 4, you would need to manually report events with the JavaScript API.
Routing Engines
AngularJS applications that have multiple Views use a route to move from one virtual page to another. You can use AppDynamics Browser RUM to instrument any virtual page that uses either of two routing engines, ngRoute or ui-router.
Metrics
Because virtual pages are constructed in the browser, normal page view metrics must be adjusted. In essence, what a metric for AngularJS must do is correlate the time between various routing events, using their timestamps. Metrics are calculated as follows:
| Full Metric Name | Short Metric Name | How Calculated |
|---|---|---|
| End User Response Time (not used for waterfall UI) | PLT | virtualPageStart to virtualPageEnd |
| HTML Download Time | DDT | viewChangeStart to viewChangeEnd |
| HTML Download and DOM Building Time | DRT | viewChangeStart to viewDOMLoaded |
| DOM Building Time | DPT | viewChangeEnd to viewDOMLoaded |
| DOM Ready Time (used instead of PLT for waterfall UI) | DOM | viewChangeStart to viewDOMLoaded |
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 |
|---|---|---|
| virtualPageStart | locationChangeStart | stateChangeStart |
| viewChangeStart | routeChangeStart | stateChangeStart |
| viewChangeEnd | routeChangeSuccess | stateChangeSuccess |
| viewDOMLoaded | viewContentLoaded | viewContentLoaded (may happen multiple times - timestamp overwritten each time) |
| viewFragmentsLoaded | load time of the last HTML fragment | |
| xhrRequestsCompleted | response time of the last XHR requests | |
| viewResourcesLoaded | load time of the last resources | |
| virtualPageEnd | the latest one among viewContentLoaded, xhrRequestsCompleted and viewResourcesLoaded | |
Page Load Process Visualized
Visualized the page load process looks something like this:
Compare these to the standard page metrics, which are shown here.
Excluding Heartbeats or Background Requests from Timings
You may wish to exclude certain events from your virtual page timings. To do this you can customize the JavaScript agent when you inject it.
Add the following snippet before you add the JavaScript agent file, adrum.js, to the page:
Option for excluding XHRs
<script type="text/javascript">
(function(config) {
(function(spa) {
(function(angular) {
(function(vp) {
vp.xhr = {
"exclude": {
"urls": {
pattern: '.*/dealActiveUsers'
}
}
};
})(angular.vp || (angular.vp = {}));
})(spa.angular || (spa.angular = {}));
})(config.spa || (config.spa = {}));
})(window["adrum-config"] || (window["adrum-config"] = {}));
</script>
Seeing Correlated Server Times
Since there isn't a regular HTML page timing to which correlated server timings can be linked, to see 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.