What is Browser-based Load Testing?

Conventional load testing involves simulating traffic by creating a load at an API or protocol level. For example, you might use Apache JMeter to send tens of thousands of requests to a REST API server and analyze the response times, error rates and other performance metrics.

There are several reasons for taking this approach:

• Hardware is expensive and protocol-based tests are highly efficient using tools like Apache JMeter.
• Load testing is often outsourced to third parties on an infrequent basis to verify performance.
• Many applications that required load testing were thick clients that could only be accessed via thick clients.

The problem with protocol-based tests is that they don't test anything beyond the server response. For example, Apache JMeter doesn't actually perform browser tasks, such as rendering HTML or executing JavaScript, so these timings aren't included in the performance test results.

Browser-based tests incorporate these browser timings into the performance testing results to paint a more complete picture. While it's more resource-intensive to spin-up actual instances of browsers, the rise of cloud computing has lowered these costs over time — and it's now an affordable option.

LoadNinja makes it easy to create browser-based load tests using a record and playback process. With minimal scripting, you can quickly record specific actions and replay them across tens of thousands of real browsers. You can use the results to drill down into specific virtual user sessions to diagnose problems.

LoadNinja makes it easy to record and playback tests

Load Testing Best Practices

Browser-based load testing differs from protocol-based load tests in many ways. The most significant is that most browser-based load tests are either recorded and replayed or written in Selenium since they include a series of actions that must be taken on a real web browser instance.

Check out our free quickstart guide to generating fake parameterized data for your load tests.

There are several best practices to keep in mind when browser-based load testing.

#1: Plan the Test

Start by clearing your browser cache and cookies to avoid using any cached data. While LoadNinja uses TrueLoad Technology to spin up a new browser within your browser for record and playback, many other record-based solutions don't include that level of functionality and require a clean slate.

You should also ensure that new scenarios start from the web browser's start. If you start recording a scenario after connecting to the test server, the playback might fail because there was no initial access provided to the test server in the script that's ultimately replayed in simulations.

Browser-based load testing also requires careful attention to detail. Unlike protocol-based tests, browser-based tests must mimic actual user behavior. This means carefully recording the parameters in each test and replacing them with variable values that simulate unique users rather than the same user.

#2: Start with One

It's easy to record a browser-based test and rush to scale it up to thousands of virtual users. The problem is that a single error in the test could render the performance results useless and generate unnecessary expense at scale. It's important to go through each recording and verify that everything is correct.

In some cases, you can use a single recorded scenario to identify bottlenecks before scaling the test. These bottlenecks may be unrelated to the number of virtual users and additional testing conditions, which makes them critical to identify before scaling up the test to production levels.

You should also run the test as an actual user would use the application. For example, the timing between steps should include the time it takes for the user to think through their next action. If you provide no think time, it could put an abnormal load on the test server. You should also ensure that each click is recorded properly.

#3: Avoid Real Servers

Production environments may have existing network traffic that could affect performance testing results. For instance, a live production server is experiencing constant fluctuations in network traffic and resource usage, which makes it impossible to come up with a baseline figure.

While running performance tests on a staging server won't harm production users, that doesn't mean that you should try to crash the staging server. The goal is to identify performance bottlenecks under various loads rather than determining how many concurrent tasks it would take to cause a failure.

It's equally important to ensure that any third-party APIs are properly mocked or disabled in the test environment. For instance, you may want to avoid running thousands of live payments that you would have to manually refund through a payment process, while CDNs may cloud true performance.

The Bottom Line

Browser-based performance testing provides a much more accurate look into the real user experience. Rather than testing server responses, you can see exactly how a user's browser would behave under various loads. This is especially useful in front-end, JavaScript-heavy applications.

Don't forget to check out our free quickstart guide to generating fake parameterized data for your load tests.

LoadNinja makes it easier than ever to load test using real browsers and record-and-playback functionality. Rather than outsourcing performance testing or relying on protocol-based tests, you can easily record and playback complex browser-based tests without writing a single line of code.