Your biggest campaign of the year goes live at 9am, an hour later traffic is triple a normal day. It’s that ‘surge in traffic’ is what all the planning was for, and it is also the moment a website is most likely to slow to a crawl or drop offline.
A stress test rules ahead of time. It shows how much traffic your site can absorb before performance suffers, while you still have room to strengthen the weak points. The five steps below cover what a stress test involves and how to run one, on any platform.
What a stress test is (and what it isn't)
A stress test pushes your site past its normal traffic, then keeps pushing until performance starts to give. The question it answers is a practical one: how many visitors can arrive at once before the site slows down or stops responding?
Stress testing, load testing, and speed testing get used interchangeably, but each has a distinct job. Here is how they compare.
Test type | What it measures | When to use it |
Stress test | How much traffic the site handles before it slows or fails | Ahead of a planned traffic spike, such as a campaign |
Load test | Performance at an expected level of traffic | Capacity planning for steady, predictable growth |
Speed test | How quickly a single page loads for one visitor | Everyday performance tuning |
For a campaign, the stress test is the one to run, because the ceiling is the number that actually matters. The method carries across platforms, too. A WordPress stress test and a Magento stress test use the same tools and the same thinking, and the same goes for Shopify or a custom build. Your platform decides which fixes you apply, not how you run the test.
When to stress test a website
Stress testing is not a routine task. It is worth doing ahead of any moment when you expect a deliberate spike in traffic, such as:
A product or feature launch
A seasonal or promotional sale, such as Black Friday
A press feature or PR campaign that could drive sudden interest
A holiday peak you can plan for in advance
A site that has just been redesigned or moved to new hosting, and has not yet been proven under real load
For ecommerce sites, the checkout deserves particular attention. A slowdown their costs sales. If your store already feels sluggish at the final step, it is worth resolving that first; our guide to why your WooCommerce checkout is still slow covers the common causes.
For a wider view of handling sudden surges, see whether your website can handle a spike in traffic.
Agencies and freelancers benefit from building a stress test into their pre-handoff checklist. Confirming that a client's site holds up under campaign load before launch protects both the client's results and your own reputation.
How to stress test a website in five steps
You do not need to be a developer to follow this. Many guides on how to stress test websites open straight into command-line tools; this one keeps things practical and links to the deeper technical detail where it helps.
Step 1: Set up a staging environment first
Important: never run a stress test on your live site. You are deliberately pushing it toward its limits, so always use a copy.
Create a staging environment, a private copy of your site hosted in the same or a similar setup. Most managed hosts offer one-click staging; on WordPress, that is usually a single option in your hosting dashboard or a plugin such as WP Staging. The same approach applies to any platform.
One detail makes the difference: your staging environment should match production's resources as closely as possible. Testing on a smaller staging server produces numbers that will not reflect the real thing. For a step-by-step setup, see our guide to configuring a WordPress testing sandbox.
Step 2: Establish your baseline
Before simulating traffic, understand what normal looks like. Open your analytics and note:
Your highest number of concurrent visitors to date
Your busiest hour, measured in sessions
The traffic level you realistically expect from the campaign
Set your test target above that expected peak, with a margin for the unexpected. If your best day reached 500 concurrent users and the campaign could triple that, test for 1,500 and then push further. The goal is a figure tied to what this specific campaign might bring, not a round number.
Step 3: Choose the right tool
You only need one tool, and the best choice depends on how hands-on you want to be. Three accessible options cover most needs.
Tool | Best for | How it works | Cost |
Non-technical site owners | Verify your domain, point it at a URL, set a target number of clients, and watch the results in your browser. No install or code. | Free tier, with paid plans above it | |
Developers who want scripted, repeatable tests | Write a short JavaScript test and run it from the command line. Handles 30,000 to 40,000 virtual users per instance, and more when distributed. | Open source and free; k6 Cloud for distributed runs | |
A quick server-level check, if you have terminal access | A single command, included with Apache. It is single-threaded, so on very heavy runs it can reach its own limit before your server does. | Free |
If you are not technical, Loader.io is the simplest place to start. To keep things minimal, a single ApacheBench command sends 1,000 requests, 100 at a time:
ab -n 1000 -c 100 https://staging.yoursite.com/
For scripted, repeatable tests, k6 uses short JavaScript files you can save and reuse. Both tools have thorough documentation for going further when you need it.
Step 4: Run the test and read the results
Start below your target and increase the load gradually, so you can watch performance change as visitors climb. Three measurements matter most.
Metric | What it tells you | A healthy result |
Response time | How long pages take to load under load | Stays steady, with no sudden spike as users increase |
Error rate | The share of requests that fail | Stays under roughly 1% |
Throughput | Requests served per second | Keeps rising with users, then levels off smoothly |
The clearest sign of trouble is a server error. Two are worth recognizing sights.
Code | Meaning | Usual cause |
Service unavailable | The server is overloaded and cannot take the request right now | |
Gateway timeout | One part of your stack waited too long for another and gave up |
Availability shapes search visibility as well. When a site keeps returning 5xx errors, Google reads it as an overloaded server, so its crawlers slow down and pages that fail repeatedly can fall out of the index over time. Google sets this out in its own documentation.
Step 5: Act on the results
If the test reveals a limit, that is a good outcome: you have found it in private, with time to improve things before the campaign. The most effective fixes, in order:
Caching. Most campaign visitors are logged out, and a cached page reaches them without touching your database or application code, which is where load builds fastest. Carts and checkouts are the exception, since they cannot be cached the same way, so an object cache such as Redis eases the pressure there. On WordPress, a plugin like Object Cache Pro sets this up.
Image optimization. Compress and lazy-load large images, so pages stay light under load.
Plugin and extension review. A single poorly built add-on can slow down every request, so identify and replace it.
A hosting upgrade. Sometimes the honest conclusion is that the server itself is the limit.
On WordPress specifically, why WordPress is slow and nine fixes works through the common culprits, and WordPress Site Health flags issues such as a missing persistent object cache. To measure your improvements, PageSpeed Insights is a reliable check, and Google's Core Web Vitals set the benchmarks worth aiming for. For a broader plan, see our guide to website speed optimization.
Your pre-campaign checklist
Run through this before you launch any campaign. When every line is checked, you can go live with confidence.
Check | What good looks like before you go live |
Staging tested | The test ran on a production-matched staging copy, not the live site |
Baseline known | You know your real peak concurrent users from analytics |
Target set | You tested for a realistic campaign peak, plus a safety margin |
Caching on | Page cache for anonymous traffic, object cache for dynamic pages |
Errors controlled | Error rate stayed under roughly 1% at your target load |
No 5xx at peak | No 503s or 504s appeared before you reached your target number |
Images optimized | Compressed and lazy loaded |
Plugins reviewed | No single plugin or extension slowing response time |
Hosting headroom | The server holds target load with room to spare |
Rollback ready | You can revert quickly if anything slips through |
What a Magento store learned
Soxcessful, a Magento store, ran regular marketing activations, exactly the kind of planned traffic spike a stress test prepares for. During those campaigns, the site repeatedly went offline under the load.
The immediate cost was downtime. The quieter cost was searching visibility. Every outage met Google's crawlers with server errors, and repeated 5xx responses signal an overloaded site, so Google crawls it less often and, if the pattern holds, drops the affected pages, exactly as its documentation describes. The result was lost rankings at the very point campaign traffic should have been converting.
The lesson is a simple one: a stress test shows whether a site can handle campaign load before the campaign begins. And because Soxcessful runs Magento rather than WordPress, it is a useful reminder that this applies to any platform. The checkout is usually the first area to feel the strain, whatever the technology behind it.
When the results point to your hosting
If you have worked through the fixes and the site still cannot hold your target, treat it as a clear signal rather than a setback: the foundation needs to be stronger for what is ahead.
Reliable hosting is what keeps a campaign online when traffic surges, and the way your hosting affects traffic and performance is often underestimated. When 44,000 cPanel servers went offline in a single incident, sites on managed hosting built for load stayed available throughout. If your stress test keeps pointing to the server, it is worth moving to a plan built for the spike, well before your next campaign.
Planning your next campaign? Our team can set you up with managed hosting that has the headroom to take the spike in its stride.
Frequently asked questions
What is the difference between load testing and stress testing?
Load testing checks that your site copes at the traffic level you expect. Stress testing keeps going, raising the load until something is given. Before a campaign, the stress test is the one that earns its place, because it finds the ceiling rather than confirming a quiet day.
What is the best free website stress test tool?
It comes down to how hands-on you want to be. Loader.io runs in the browser on a free tier with nothing to install, which suits most site owners. Developers usually reach for k6, which is open source. And if you already have server access, ApacheBench is free and built into Apache.
How do I stress test a WordPress site?
Always start on a staging copy rather than the live site. Note your real traffic peak in analytics, point a tool like Loader.io at the staging URL, and push past the number you expect from the campaign. Watch response time, error rate, and throughput as the load climbs, then fix whatever falls short. Caching is usually the first place to look.
How many users should I simulate?
Work from your own data. Take the highest concurrent user count you have recorded, scale it up to what the campaign might realistically bring, then add a buffer on top. A target with no basis in your real traffic will not tell you much.
-1-(1).webp)