cache.lat
Almost all WordPress sites seem fast with a single person browsing. The problem appears when a campaign, a mass email, or a social media mention arrives and a hundred visitors come in at once. A load test tells you what happens at that moment before it actually happens.
What a load test measures (and what it doesn't)
A load test simulates many simultaneous visitors and records how your server responds. What's worth looking at:
- Response time (TTFB) as the number of visitors rises.
- Error rate: 5xx responses, timeouts, or refused connections.
- Breaking point: the concurrency level at which times spike.
It doesn't measure the browser experience (that's Core Web Vitals), but rather the server's capacity to handle requests.
Before you start: basic rules
Test your own site, nothing else
Launching load against someone else's site can be illegal and, on your own hosting, can violate its terms. Check your provider's policy or give notice before running a heavy test.
Do it in staging or during low-traffic hours
If the test takes the site down, better that it be a copy or a Tuesday at dawn. Avoid testing in the middle of a campaign.
Note down the starting configuration
PHP version, active plugins, cache plugin and its status. Without that you won't be able to compare results.
How to do it step by step
- Choose a tool. There are online services with limited free plans (for example Loader.io or BlazeMeter) and local tools like k6 or Apache Bench (ab).
- Start small. A short test with few simultaneous visitors to validate that everything works.
- Go up in steps. Double the load each round and note when errors start.
- Test different URLs. The homepage, a post, and a dynamic page (cart, search) behave very differently.
- Repeat with and without cache. The comparison is the most revealing part.
Why cache changes the result so much
Without page cache, every visit runs PHP and queries the database. With 50 simultaneous visitors that can already overload shared hosting. With the page served as a static file, the server barely works per visit, and the time curve stays flat for much longer.
If you want to understand exactly what happens on each request, look at how cache.lat works; and if you need the architecture details, they're in the technical data.
How to read the results
- Flat times and zero errors: your configuration handles that level. Try one step higher.
- Times that grow linearly: the server is running out of CPU or PHP workers. Check whether pages are really being served from cache.
- Sudden errors: it's usually a connection, memory, or database limit. Check the hosting logs.
- Slow dynamic pages with cache active: these are routes that are normally excluded (cart, checkout, account). That's expected; optimize queries and plugins there.
Common mistakes
- Testing only the homepage and believing the whole site can handle it.
- Adding random parameters to the URL that bypass the cache and measure an unrealistic scenario (or, conversely, forgetting that real ones do exist).
- Running the test from the server's own network: the latency doesn't represent your visitors.
- Not repeating the test after every important change.
Conclusion
A load test doesn't have to be complex: with a free tool, an hour, and a bit of method you'll know how much traffic your site supports and where the bottleneck is. If you want a hand interpreting results or evaluating cache.lat on your site, write to us from the TuNegocioEnLinea contact page.