The single-page application as a new trend

The model of a traditional web application (left) in direct comparison with an Ajax web application (right). Author: DanielSHaischt

At the end of the 90s, the Web development team argued that the computing power of the server is clearly superior to the clients and for this reason dynamically generated content should be generated on web servers or application servers and the client gets a static HTML page in the browser is shown.

The client with the browser was purely limited to the presentation of content, while the application and data retention layer was located on the server.

In 2005, Ajax came up with a technology that took a completely new approach. On the client, the "Ajax Engine" provides an active component that processes user actions and, if necessary, sends requests to the server and evaluates responses. It gives the user the impression that basically the entire application runs on the client.

Today you can see many more frameworks, such as AngularJS, React or Vue.js using this approach. In addition, new protocols, such as e.g. WebSockets, which insist that information be processed and processed on the client.

In the single-page application, a URL is usually called only at the beginning and HTML code is transmitted. JavaScript, which runs on the client and dynamically changes the DOM structure of the displayed web page, is also transmitted along with the HTML code. The user sees changed content in his browser, but the URL remains constant over the lifetime of the application.

This turnaround also affects the performance of a web application. While in the past the response times of the server could tell the speed of the application, today the performance depends essentially on the computing speed of the client. Thus, the test must be much more thoughtful in terms of test environments, since the web application can be used by a large number of different devices.

End-User-Experience as a new metric in the performance test

Most Performance Measurement tools work at the Web History level. The tools send requests to the web server and receive the response and provide response times as a measure.

However, single-page applications now have an active component on the client that processes the content of responses and adjusts the current DOM structure. The duration of this processing until it is displayed in the browser is not part of the response time and may vary depending on the client.

To be able to reliably assess the performance of a single-page application, the response time is not a sufficiently good metric. It's much more about measuring the time that elapses from the user action on the page until the ad changes in the browser. This time is referred to in the literature as End-User Experience.

The End-User Experience starts e.g. by clicking on an element of the web page and ending when an expected information is visible in the browser. Thus both processing steps are covered by the active component on the client of this metric.

Joint use of performance test and test execution tools

Test setup for the performance test with measurement of the End-User-Experience

When it comes to measuring the End-User Experience, test execution tools are very appropriate, as they usually interact with a browser. The test scripts control the application via controls that are displayed in the browser and also perform checks on them.

The disadvantage is usually to test execution tools that you can usually run only one instance on a computer, otherwise the test scripts interfere with mouse clicks or keyboard input each other in the process.

The parallel execution of multiple test scripts on a computer, however, is the strength of performance test tools, as they send requests purely via the network card.

The two strengths of the respective test tools can be combined by using a few computers to measure the End-User Experience and at the same time generating a large number of queries to the servers via the performance test tool.

NeoLoad and QF-Test are a good team for this task

Using QF-Test in the performance test
Import of QF test scripts into NeoLoad

We, the company Muth Partners, rely on NeoLoad and QF-Test for performance testing with End User Experience measurement.

The two test tools can be used together perfectly with the help of a plugin developed by us. In addition to measuring the end-user experience, QF-Test scripts can almost automatically be imported into NeoLoad. This makes it easy

  • to use the existing test scripts for the functional testing of your software in the performance test to measure the end-user experience.
  • to import the existing test scripts for the functional testing of your software into NeoLoad to create load with comparable scripts without having to redevelop it.

Muth Partners improves your performance tests

If you are interested in integrating NeoLoad and QF-Test, please contact us.

As a Neotys service partner and QFS partner, our consultants can help you bring the integration of both tools into your environment.

 German Version

Your benefit

  • Measuring the End-User Experience as a strong metric
  • Reuse existing scripts
  • Import of scripts
  • Single Point of Thruth in NeoLoad

More Details

Your contact


Schweier, Dirk O.
Dirk O. Schweier
Teamleiter Testautomatisierung