The Web has evolved dramatically since its inception, embracing new and innovative technologies that have enhanced both business efficiency and the user experience. Single-Page Applications (SPA)—web apps that load a single HTML page and dynamically update the page as the user interacts with it—are among the most revolutionary of these innovations, having enabled dynamic and responsive web apps that resemble their native mobile and desktop counterparts. Dozens of frameworks are available for building SPAs, and the market is currently ruled by popular options such as React, AngularJS, and Backbone.js.
While SPAs generally make the end user experience better, they have made it harder for developers to have a true understanding of how their applications are performing. When 8 in 10 users will abandon an application if it doesn’t meet their performance expectations, it’s crucial that developers understand the performance of every important page, regardless of how it was rendered.
As a developer you should care about a few questions for your SPA:
How long did a page take to be visible and usable by your end user?
How did any backend requests related to the page perform?
How quickly were we able to download any resources such as CSS and images for a particular page?
If any errors are occuring, what page are they associated with?
Here at AppDynamics, we carefully studied the inner workings of Single-Page Applications, and have developed an out-of-the-box monitoring solution for SPA frameworks. In fact, we’re now able to monitor websites built on all of the popular frameworks, such as those mentioned above.
Introducing End User Response Time
At AppDynamics we think of two types of “pages”:
SPA frameworks trick the browser into not reloading the page on every navigation; rather, they change the URL and fetch new content via XMLHttpRequests (XHRs). A “virtual page” is one that isn’t loaded from the server, but is updated via XHRs.
A SPA is therefore comprised of one base page (the initial load) and multiple virtual pages for each navigation.
End User Response Time (EURT) is defined as the amount of time a page (either base or virtual) takes to load completely. EURT is calculated by determining the start and end times for each page:
EURT = end time – start time
What Does Page ‘Start Time’ Mean?
A virtual page transition begins with a trigger. For example, a user clicking a button will cause a virtual page transition. This click marks the start time for the virtual page load.
The trigger—in this case, a user click—fetches the data necessary for the virtual page. Similarly, this action can execute logic required for the virtual page transition. Hence, the accurate start time of a virtual page is the time when it was triggered. The trigger may vary, of course—a click, a timer, and so on.
When Does a Virtual Page End?
A virtual page ends when the entire page is rendered completely and there is no more network activity. There is no explicit browser trigger to indicate this, so AppDynamics waits for a period of inactivity (both user actions and browser) to declare a page load has ended. See the documentation for more details.
AppDynamics captures both the start and end times of a virtual page, and uses that data to compute the End User Response Time. The EURT metric tells us the entire time spent fetching data for the virtual page, including the rendering time and network time.
A page is nothing without the data it’s meant to display, so you will want to know how quickly that data made it from the server back to the browser. XMLHttpRequests are the main backbone for fetching data without reloading the page. Therefore AppDynamics correlates the performance metrics for XHRs with the virtual page responsible for executing them, so that you can see all contributors to the perceived performance for any given page.
We also correlate XHRs launched between the trigger of a virtual page and the URL change. Why? Again, because the XHRs are responsible for bringing data to the page.
In the example above, XHR1 launches before the URL change, but is responsible for fetching data for virtual-page transitioning. By comparison, XHR2 launches on the virtual page and is not responsible for fetching data for a new virtual page. Hence, when clicked by the user, both XHR1 and XHR2 will be correlated with the virtual page transition.
Resources such as images, CSS and scripts, which are loaded on a virtual page, are correlated with that page. And resources loaded between a virtual page’s start and end times are correlated with the virtual page as well. Again, any element that can contribute to a user’s perception of how a page performed needs to be associated with the page, otherwise it’s difficult to understand each element’s impact on user experience.
By accurately capturing the metrics that matter most, AppDynamics makes it easy for you to see the performance of your Single-Page Applications, identify the exact causes of any app slowdowns, and pinpoint and debug errors.