Bad user experience impacts business. This is the reason you might want to know how many concurrent users your website can handle appropriately.
Load testing helps you simulate those users to asses your system performance and know if your website or web app meets your goals.
This guide provides guidance and recommendations to get started, creating user scenarios, and avoiding common pitfalls to load test a website.
On a website, performance is a crucial part of the user experience. It is often measured by the response time to visualize or interact with some information. The two main actors affecting the user experience response time are:
Frontend performance focuses on browser metrics like rendering time, interactive time, loading time, among others.
Backend performance, on the other hand, focuses mostly on the server response time and the amount of returned errors.
Which one is more important? It depends! In general terms, the performance golden rule states:
80-90% of the end-user response time is spent on the frontend.
But this is not necessarily accurate.
With an increasing amount of visits to your website, the frontend response time remains roughly the same. Still, when your system struggles with the increased concurrency, the backend time might grow exponentially with the rise of concurrent users.
The following chart illustrates this situation:
In short, whenever you are concerned about the availability and scalability of your website.
If you have a very low number of users, backend performance won't likely be an issue. Spend your time optimizing the frontend.
But as the number of users grows, you should start spending more time improving and testing the performance of your backend. In the performance golden rule, Steve Souders pointed out that:
If you’re worried about availability and scalability, focus on the backend.
When testing how your system behaves with some concurrent users, browser metrics are, in most cases, less useful.
Because each browser runs independently, the number of concurrent users in a load test will not affect browser metrics like rendering time.
A load test focuses on testing the performance of the requests to your backend. The two most fundamental aspects to analyze are the server response time and the number of returned errors.
For example, a load test simulating hundreds of concurrent users could validate that:
- Your server doesn't respond with errors.
- The response time for 95% of your users should be below 400ms.
- The response time of your images must always be below 600ms.
Below, some common recommendations that you could consider when load testing a website:
We recommend you to consider performance testing an iterative and continuous process.
You start small by testing, evaluating, and iterating frequently.
Start small and simple, make sure you get something out of the testing first, then expand the test suite and add more complexity until you feel that you’ve reached the point where more effort spent on realism will not give enough return on your invested time.
The first thing is to decide what to load test. On the one hand, you could test your critical services, the most valuable to your business, and have the most significant risks. On the other hand, test the most frequent user journeys.
With this information, it’s time to analyze the frequency of usage, business value, performance risks, and any other critical performance aspect of your organization to help you deciding what to load test first.
Next, you should decide what types of load tests to run. Check out the following articles to learn more:
You could define your load tests based on the observation of your normal and peak traffic levels, and use this formula to determine the number of VUs to specify in your load tests:
VUs = (hourly sessions * average session duration in seconds)/3600
- hourly sessions = Number of sessions per hour
- average session duration = Average time between the first and last request of each user
Refer to Determining Concurrent Users in Your Load Tests to learn how to calculate the formula using Google Analytics.
We recommend to Load test in a pre-production environment that mimics the production environment as closely as possible.
Testing regularly in a pre-production environment allows assessing the performance of your website over time and catch performance regressions before they reach production.
Load testing a website in pre-production allows breaking your systems without worrying about the interruption of your service. Load testing in production is risky, but if your processes and team are mature, you could run your load tests in production as part of your chaos experiments. Sometimes it is the best way to get a picture of the real world.
Load tests should mimic user journeys as closely as possible. These user journeys, aka user scenarios, generally involve complex actions in a logical flow (dozens or hundreds of requests).
The process of creating this type of load test could be tedious. But the recording of a user session could facilitate the job of starting the test creation for you.
Check out the Session Recording guide to learn more about how to auto-generate your load test from a user session.
You may have various external requests happening for a normal visitor on your site — for example, Analytics tools, Social Networks, Widgets, etc.
While these requests do impact the user experience on the frontend, they have no impact on the performance of your system on your backend. We highly recommend removing all third party requests from your test script for the following reasons:
- Third-party requests have no impact on your backend performance.
- Third parties may throttle requests, skewing your results.
- Third parties add a lot of noise to your test result data which makes understanding results harder.
- It may be against the TOS with the third party to run a test against their system.
You should consider your CDN as a third-party provider and do not include CDN requests in your load tests because of the reasons explained previously. Additionally, load testing a CDN may cost you money.
But there are also valid cases to test your CDN in case you want to understand something about your CDN provider.
When testing web sites it's common that you have to interact with HTML to submit forms, extract data, check for existence of elements or text etc.
For submitting a form, check out Response.submitForm([params]).
By default, the standard metrics of a load testing tool -- for example, the response time metric will aggregate the values of all the website requests. But you might want to see the results of these metrics filtered by the type of resources:
- 95th percentile response time of all the images.
- 99th percentile response time of all the API requests.
Different types of resources could behave very differently and could make meaningless the value of the aggregated metrics.
If you might want to filter your metrics based on different types of requests, consider using the tagging feature.
Groups help you organize your load test around a common logic. When a load test simulates a user scenario visiting multiple pages, it is a good practice to set up a group for each webpage to organize your load test and facilitate the visualization of your test results.