A single-page application (SPA) is a single URL web application run entirely in a web browser.  Here are a few things you should consider before choosing the right application for SPA load testing.

One of the first items to take into account is that SPA logic relies heavily on JavaScript technology. Every time a user clicks a button or performs any other action on the web page (navigating between tabs, filling web forms, etc.), a browser executes JavaScript and renders the web page.

Secondly, the authentication in an SPA involves HTTP headers carrying access credentials (e.g., JSON web tokens). Access tokens are provided by an SPA server for each session. When a browser executes HTTP calls, it extracts the token from the SPA server response and passes it back with each HTTP request.

These SPA logic traits put limitations on SPA testing with applications such as JMeter. JMeter is NOT a browser and works at the protocol level. JMeter allows emulating SPA web requests to the server without testing application itself. However, creating any requests to operate with user data on the page requires corresponding knowledge in web development.  For example, to log into a SPA, you need to authenticate client’s calls per each session. Otherwise, page performance can’t be tested accurately.

On the other hand, LoadView works like a real browser and supports JavaScript execution and authentication logic at the browser level. All that you need to do is to script user actions on the SPA page using the built-in recorder and set up a load pattern. It’s as simple as that!

The test will be performed in a real browser (Chrome or Internet Explorer options are available) to simulate real user experience and provide realistic test results.


For more information on web application load testing, see Getting Started with Load Test Setup and Configuring Web Application Task.

Common Use Cases

In order to show the nature of SPA testing, let’s consider a test scenario that repeats the process of changing user data on the Users page of the Dotcom-Monitor Account Settings menu. The page is a typical example of a SPA.

Since the Users page is authenticated, we need to log into the application before testing the page. Login testing may be tricky without a browser because of the SPA authentication traits described before.

Depending on the authentication results, the page content is loaded. In general, all the data, including UI, are processed at the back-end and delivered in HTML. Thus, to receive the data, GET requests should be sent to the page URL. However, when it comes to SPAs, there’s no data in the server response except JavaScript scripts. Find the page source on the picture below.

In comparison to the server response, let’s have a look at the page elements rendered by the browser. The browser renders the page content dynamically including the user data, headers, menu panel, and the user list grid. Since the UI elements are not included in the HTML, and only rendered by the browser, they can’t be tested without JavaScript execution.

For example, the Edit User dialog handler is already included in the initial server response and no calls are executed additionally. Checking if the pop up dialog is rendered correctly requires a related script execution and can’t be accomplished by HTTP requests.

Find the example of requests that are sent to the server upon editing user data.

In conclusion, if you want to test SPA performance, a real browser-based load testing solution, such as LoadView, can provide you with comprehensive load testing results.