The (in)sanity of performance testing web applications

At some point in the life of a product which owners value the user’s experience, an organization ends up developing some kind of performance test. You’ll find them in different forms however. For example, a load test is used to observe the behavior of the system while simulating a well-known set of circumstances (users, usage scenarios, etc). A stress test on the other hand, tries to hit the system as hard as it can to see if and when it succumbs under the load. But whatever your goals are, before you start to put too much trust in the results, you need to understand the complexities of such a test. It’s fairly common to end up with results that don’t say anything about the real deal.

What are we measuring?

Imagine a web-based application which has been designed using modern front-end development techniques. Such a Single Page Application (SPA) typically uses an architecture where a majority of the application runs in the browser and relies on HTTP APIs to interact with server-side logic. That raised the question about what part should be included in the performance test.

An end-to-end test that uses the actual browser is quite unpractical. Developers who’ve been automating their application using Nightwatch, Selenium or Puppeteer know exactly what I’m talking about. As an alternative…