Load Testing: Validate Your Site Before a Traffic Spike

A website load test simulates hundreds or thousands of simultaneous visitors to verify that your site can handle the traffic. It is the only way to know, before the big day, whether your store will survive Black Friday or if your server will crash at the first media spike. Here is how to conduct a useful test without getting drowned in numbers.

What a website load test measures

A load test does not measure your site's aesthetics, but its robustness. It answers three specific questions:

• How many simultaneous users can the site serve without degrading the experience?
• What is the response time when the load increases?
• At what point do errors begin to appear?

The goal is not to take down the site for fun, but to find the breaking point before your visitors do. This allows you to discover what fails first: the web server, the database, the cache, or the network.

Define a realistic scenario

A test is only as good as its scenario. Simulating ten thousand requests on the homepage is useless if your visitors spend most of their time on the catalog or the cart.

Build a scenario that mirrors your real traffic:

• Include the most visited pages, not just the homepage.
• Mix user profiles: the reader, the shopper, and the buyer.
• Reproduce the traffic surge: a launch spike does not happen all at once; it ramps up over a few minutes.
• Account for authenticated requests, which are more expensive than public pages.

A realistic scenario reveals the true bottlenecks. An artificial scenario gives you false reassurance.

The tools: k6 and Locust

Two open-source tools dominate this field.

k6 is a performance testing tool developed in Go and scripted in JavaScript, designed for developers. It is lightweight, command-line based, and covers spike testing, progressive stress testing, and soak testing. It also integrates into continuous integration pipelines to automatically test with every deployment.

Locust is a Python tool where each simulated user is orchestrated by a lightweight coroutine. It offers a web interface to launch and monitor tests, load distribution across multiple machines, and a headless mode for automation scripts.

Both tools perform the same function: injecting traffic and measuring the response. The choice depends largely on your team's skills — JavaScript or Python.

Reading results: response time and errors

A load test generates mountains of data. Focus on the two critical metrics.

Response time should not be read as an average, but as a percentile. The 95th percentile (p95) indicates the time under which 95% of requests are served: if the average is 200 ms but the p95 is 3 seconds, a minority of visitors suffers from critical slowness — and these are often the ones who abandon their visit.

The error rate is even more telling. As soon as errors (timeouts, 500 errors, refused connections) exceed a small fraction of a percent, you have reached a limit. A site that responds quickly but returns errors under load is not a site that holds up.

Fixing: cache, queries, scaling

The test shows the symptom; you must address the cause. Fixes almost always involve the same levers:

• Cache: A page served from the cache does not strain the processor or the database. This is the most immediate gain.
• Queries: A slow or unindexed query is enough to saturate the entire database. Optimize the most expensive ones.
• Scaling: If the infrastructure is simply under-provisioned, add memory or vCPUs.

At Atlas Hoster, load testing is part of the high availability methodology: the team simulates your peak with k6 or Locust, then fixes what breaks — cache, queries, limits, scaling — before your customers arrive.

A load test serves not only for performance: it also validates your high availability architecture. And for stores, it is a prerequisite for any commercial operation, as explained in our article on online store speed.

When to re-run the test

A load test is a snapshot, not a guarantee. Re-run it:

• before each launch or major commercial operation;
• after each significant change: new version, new theme, new plugin;
• with each hosting change or scaling adjustment;
• at regular intervals, even without changes, to detect performance drift.

To avoid forgetting, you can schedule a lightweight test at regular intervals via a scheduled task: our help on cron jobs shows you how. Also monitor your resource limits, as disk space and bandwidth are among the first signals of saturation.

If your site must withstand a sudden and unpredictable spike, a prior test is your best insurance: our article on managing a viral spike explains how to prepare.

For a site that must hold up before, during, and after the spike, discover Atlas Hoster's high availability offer, which includes load testing in its workflow.

Pitfalls to avoid

• Testing from the same machine as the site: you measure local latency, not what your visitors experience. Launch the test from outside.
• Simulating unrealistic load: a scenario that does not match your real traffic predicts nothing.
• Looking only at the average: a correct average response time can mask serious slowness at the 95th percentile.
• Ignoring the error rate: a site that responds quickly but returns errors is a site that does not hold up.
• Concluding after a single test: load, code, and hosting evolve; an isolated test has only a point-in-time value.

Frequently asked questions

How many simulated users are needed for a test?

Start with your current peak traffic and aim for 1.5 to 2 times that level to maintain a margin. For an unprecedented launch, estimate the expected peak based on your acquisition channels and add a safety margin.

Can a load test take my production site down?

Yes, that is precisely the risk — which is why it is better to test on a staging or pre-production environment identical to production, rather than on the site hosting your real customers.

What is the difference between a load test and a performance test?

A load test measures resilience under high, simultaneous traffic; a performance test measures the speed and experience of an individual visitor. The two are complementary.