As explained in our article ‘What is a Single Page Application (SPA)”, a SPA is a web application built around a single HTML page.
So, monitoring SPA user performance means that traditional performance metrics like Page Load Time (PLT) and newly Core Web Vitals are quite inadequate as they are only computed when a full page refresh occurs. So they miss nearly all user interactions that follow the initial page load! In a nutshell, monitoring user experience for SPAs (Single Page Applications) requires a different approach than traditional web performance!
In order to understand how to best monitor SPA performance, let’s first review the way an SPA works.
The SPA main principles
If we try to schematize how a SPA works, we can summarize the whole process in three main steps/events.
First, the user connects to the web application by typing the corresponding URL in the browser. This triggers a connection to the web server. This latter typically sends the following data to the client:
- The HTML code of the page
So, this basic principles emphasizes three aspects of an SPA that you should consider when looking to monitor its performances:
- The initial web page load process
- The subsequent API calls to external resources
Let’s deep dive and see for each one what you should monitor. We then discuss the metrics that can help you as well as the challenges you’ll face when monitoring SPA performance.
The initial web page load process
During the initial web page load process, the browser requests data from the server through a network connection. So first, you should be able to monitor network performances like latency and packet loss. You should monitor these performances for:
- The DNS resolution of the web server host name
- The TCP connection to the server
- The TLS session establishment (most of the web sessions are now secured through TLS)
Next, you should be able to monitor the successfulness of the transaction. Do you get some errors downloading the required resources? Or errors directly from the server that does not allow the transaction or is unable to respond?
And finally, you should be able to know how long it takes for the whole process to happen, not only in terms of data downloading time but also how long it takes for the user’s browser to render the page.
To help you monitor these different steps and elements, the W3C organization provides APIs to compute performance metrics. Navigation Timing and Resource Timing represent the ones you will find the most useful. They provide all metrics required to measure aspects mentioned above.
To help you with this, Chrome has developed the First Input Delay (FID) metric. It measures the time from when a user first interacts with a page to the time when the browser is able to react to it, meaning when it is able to begin processing event handlers in response to that interaction. Unfortunately, FID is only used for the first user interaction following a full web page refresh. Considering an SPA, this metric will not be much relevant as it won’t be calculated for all subsequent user interactions.
Fortunately, thanks again to the W3C APIs, it is possible to monitor tasks that take too long to execute and may impact the user. According to W3C, a “Long Task” refers to any event loop task that exceeds 50ms. Using this API can help you detect the usage of code that is too heavy to execute.
The API calls
In modern applications, third parties or CDN providers deliver up to ⅔ of the SPA content.
The SPA gets these data through API calls using Ajax.
All network performance measurements relevant to the initial HTML page are also applicable here. The big difference is that the content can this time be delivered by several dynamic locations that you generally do not have under control.
Being able to identify these sources of data, locate them and correlate the data with the corresponding users, devices and locations, is a key element in ensuring adequate SPA performance.
Monitoring SPA user performance: the challenges
Decentralized data model
Monitoring an SPA is radically different from monitoring a traditional web site.
Using the usual web performance metrics like Page Load Time does not reflect what a real user experiences during his/her SPA journey.
Fortunately, specific APIs let you monitor all events triggered by users interactions.
Nevertheless, as the application logic moves from a centralized server-centric to a decentralized users-centric model, the number of factors that may impact the application performance increases. You do not only rely on the network and server performance anymore. You also must take the browsers and potentially a lot more third-parties (CDNs, CSPs, …) into account.
To help you understand which element(s) of the whole chain mainly drive(s) performance, you have to be able to correlate a lot of data. These should help you answer the following questions where performance problems arise:
- Which transaction(s) are impacted?
- Does the problem impact specific users locations, devices, or browsers?
- Does the problem come from specific transactions to specific external providers? Which provider(s)? In which region(s)? For which API call(s)?
- Are some regions in the world more impacted due to network performance issues? Are some specific operators to blame? Why?
Mapping user interactions to application logic
SPA development technique can help segment the SPA application logic. An SPA router for example defines distinct URLs corresponding to specific application sections, so the user thinks he/she is navigating from one page to another (through different URLs), even if this does not trigger any HTML page refresh. By monitoring route changes, you can identify corresponding events (for example the different API calls) in order to better understand the possible user actions that may cause problems.