The worst time to discover your website can’t handle traffic is when the traffic arrives. I’ve seen it happen several times: a client gets featured in a newspaper, a product goes viral on social media or a long-planned sale starts at midnight, and within minutes the site slows to a crawl and then stops responding. By the time anyone can fix it, the moment has passed. Load testing WordPress before the big day is how you find those limits calmly, in advance.
Load testing is the practice of simulating many visitors at once to see how a site behaves under pressure. It answers practical questions. How many people can browse at once before pages slow down? At what point does checkout start failing? Which part breaks first: the web server, PHP, the database or something else?
You don’t need a big budget or a performance engineering team to do useful load testing. This article covers a practical approach for WordPress sites preparing for a known spike.
When load testing is worth it
Not every site needs it. A brochure site with steady traffic and good caching can usually handle far more than it ever receives. Load testing becomes valuable when:
- You’re expecting a specific spike: a launch, a sale, a media appearance, an email to a large list
- You run WooCommerce, membership or learning sites where many requests can’t be cached
- You’ve recently changed hosting, theme or major plugins
- You’ve had slowdowns or outages during past busy periods
Rule one: don’t test production without care
Load tests generate a lot of traffic. Run against a live site, they can slow it down for real visitors, trigger hosting limits or look like an attack to your host or firewall.
Options:
- Test a staging copy on identical infrastructure. Ideal, but only meaningful if staging truly matches production in server size and configuration.
- Test production during quiet hours, with your host’s knowledge, starting small and stopping immediately if real visitors are affected.
- Ask your host. Many managed hosts have policies on load testing, and some will help.
Also whitelist the load testing tool in Cloudflare or your firewall, or you’ll end up testing how quickly the firewall blocks you instead of how well the site performs.
Choosing a tool
Several good tools exist, free and paid.
k6 is an open-source tool from Grafana that uses JavaScript for test scripts. It’s powerful, well documented and can run from your own machine or in the cloud. It’s my usual choice.
Loader.io and similar hosted services let you run simple tests from a web interface without installing anything. Good for quick checks.
Apache JMeter is mature and feature-rich, with a graphical interface, though it has a steeper learning curve.
Locust uses Python scripts and suits people comfortable with Python.
Whichever you choose, run tests from a machine with a good connection, or from the tool’s cloud service, so the test machine itself isn’t the bottleneck.
Design realistic scenarios
The most common load testing mistake is hammering the homepage with thousands of identical requests. If the homepage is cached, that mostly tests your cache, and the site looks fine. Then on launch day, people search, filter, add to cart and check out, all of which bypass the cache, and the site falls over.
Think about what real visitors will do during your spike. For a WooCommerce sale, a realistic mix might be:
- 50% browsing: homepage, category pages, product pages
- 20% searching and filtering
- 15% adding to cart and viewing the cart
- 10% proceeding to checkout
- 5% completing an order, against a test payment gateway
For a content site after a media mention, it might be mostly the featured article, with some navigation to other pages and the occasional newsletter signup.
A simple k6 script
Here’s a basic k6 test that ramps up virtual users browsing several pages:
The stages ramp up to 50 users, then 200, then back down. Each virtual user picks a random page, checks for a 200 response and then pauses two to five seconds, like a real person reading.
The thresholds define what success looks like: 95% of requests under 1.5 seconds and fewer than 1% failing.
For cart and checkout testing, scripts get more complex, because they need to handle cookies, nonces and form submissions. k6 handles all of this, but it takes some work to script the WooCommerce flow correctly.
Test cached and uncached paths separately
It helps to run separate tests:
- Cached pages only. This tells you how many visitors your caching layer can handle. Usually very high.
- Uncached pages. Search results, cart, checkout and logged-in pages. This tells you your PHP and database capacity, which is usually much lower.
- A realistic mix. The scenario you designed above.
The uncached test is often the eye-opener. A site that serves 1,000 cached page views per second may only handle 20 checkouts per second before slowing down.
Watch the server while you test
The load testing tool shows response times and errors. The server shows why. During tests, watch:
- CPU usage. Sustained 100% means PHP or the database is the bottleneck.
- Memory. Running out leads to swapping or processes being killed.
- PHP-FPM workers. If all workers are busy, new requests queue. PHP-FPM’s status page shows active and idle workers.
- Database. Slow queries, connection limits and lock waits.
- Error logs. PHP errors, 502 and 504 gateway errors and database connection errors.
Tools like htop, the PHP-FPM status page and your host’s monitoring dashboards are enough for most tests.
Reading the results
A typical result looks like this: response times stay flat as users increase, then at some point start rising, then errors appear. The point where response times begin to climb is your practical capacity. The point where errors appear is your breaking point.
Compare those numbers with your expected traffic. If you expect 300 concurrent visitors and response times start climbing at 150, you have work to do. If they stay flat at 1,000, you’re in good shape.
Common bottlenecks and fixes
Too few PHP workers. Requests queue while workers are busy. Increasing pm.max_children helps if there’s spare CPU and memory.
CPU exhausted. PHP is doing too much work per request. Profile uncached pages with Query Monitor or a profiler and look for slow plugins. Upgrading the server is a short-term option.
Database slow under load. Missing indexes, heavy queries from plugins and an undersized database server. A persistent object cache like Redis reduces database load considerably.
WooCommerce cart fragments. The AJAX request that updates mini-cart contents bypasses the cache and runs on many page views. Disabling it where it isn’t needed, or loading it only when the cart has items, reduces uncached load.
External API calls. Plugins that call external services on page load, such as shipping rate calculators, currency converters or social counters, slow down under load and can fail. Cache their results or move them off the critical path.
Cache misses. Query strings from marketing campaigns, like utm_source, can cause cache misses on every visit. Configure your cache to ignore common tracking parameters.
Retest after fixes
After each fix, run the same test again. Improvements should show as higher capacity or lower response times at the same load. Keep notes of each test, the change made and the result. That record is invaluable next time.
On the day itself
Load testing reduces risk, but it doesn’t remove it. On the day of a big event:
- Have someone watching the server and analytics in real time.
- Know how to scale up quickly, whether that’s resizing a server or asking your host to add resources.
- Have a lightweight fallback page ready, such as a static “we’re experiencing high demand” page, in case things go wrong.
- Avoid deploying changes on the day.
The goal of load testing isn’t a perfect site. It’s knowing, in advance, what your limits are and what you’ll do when you approach them.
Don’t forget third-party services
Payment gateways, email delivery providers and search services have their own limits. Check rate limits on any API your checkout depends on, and confirm your transactional email service can handle a sudden burst of order confirmations. Load testing WordPress once before a major event is far cheaper than an outage in the middle of it.
Frequently asked questions
How many virtual users should I test with?
Start with your expected peak concurrent visitors and go well beyond it, ideally two to three times. Remember that concurrent users is much lower than visitors per hour, because people spend time reading.
Will my host mind if I load test?
Some hosts prohibit it or require notice, because it looks like an attack. Check their terms and tell them in advance.
Can I load test a WooCommerce checkout with real payments?
Use the payment gateway’s test mode on a staging site. Never run load tests that place real orders or charge real cards.
My cached pages handle heavy load. Am I safe?
Not necessarily. Most failures during sales happen on uncached paths like cart, checkout and search. Test those specifically.
