Website Capacity Testing in WordPress: How to Estimate Website Capacity Safely

What this page covers

A practical way to estimate website capacity in WordPress: run a safe internal concurrency test, read the req/s and p50/p95 results, and translate them into a realistic “visitors capacity” range for your site.

Why “website capacity” is often misunderstood

Most people mix three different things: server-side execution capacity (PHP/WordPress), network/CDN effects, and front-end speed. This guide isolates the first one on purpose, so you can compare hosting environments and spot bottlenecks without external stress tools.

Many site owners look for website capacity testing or ways to estimate website capacity because they want one simple answer: how much load can my site handle before it slows down or breaks?

The honest answer is: it depends on what you mean by “load”. Throughput Check focuses on one specific layer that matters a lot for WordPress: internal PHP + WordPress execution capacity.

What website capacity testing means in WordPress

Website capacity testing in WordPress means measuring how much internal PHP and WordPress execution your environment can process under controlled concurrency. Instead of guessing based on traffic or PageSpeed scores, you test real internal workload and read measurable limits.

What Throughput Check measures (and what it doesn’t)

• Measures: internal REST request throughput, p50/p95 timing, stability/errors while increasing concurrency.
• Doesn’t measure: real external visitors, browser rendering, CDN caching, network latency, or “PageSpeed”.

This is exactly why it’s useful: you get a clean baseline of what your WordPress installation can process without the noise of outside traffic tools.

What a “concurrency test” means for WordPress

A concurrency test checks how your server behaves when multiple requests happen at the same time. In WordPress, this matters because many real situations create parallel work:

• traffic spikes from campaigns
• WooCommerce bursts during drops or promotions
• many users triggering REST/AJAX actions
• background tasks overlapping with real users

Throughput Check runs a controlled internal test at 5 → 15 → 30 concurrent requests and reports how performance changes at each stage.

How Throughput Check works (quick technical overview)

The plugin sends concurrent requests to an internal REST endpoint inside your own site:

/wp-json/throughput-check/v1/profile?mode=real

In “real” mode, each request performs a small but realistic workload:

• multiple get_option() calls
• a small WP_Query (5 published posts)
• a cache set/get operation

Then it calculates:

• Estimated requests per second (req/s)
• Average client response time
• Batch duration
• p50 / p95 latency (median and “slow tail”)
• Errors / stability
• A–D grade based on req/s thresholds

Installation and where to run the test

1. Upload the plugin to /wp-content/plugins/throughput-check
2. Activate it in WordPress Admin → Plugins
3. Go to Tools → Throughput Check
4. Click Run Test

You’ll see the environment snapshot (PHP/MySQL/memory/plugins), then the results for 5, 15, and 30 concurrency stages.

How to interpret the results

1) Requests per second (req/s): your internal capacity baseline

req/s is the simplest capacity signal: how many internal WordPress requests your environment can process per second under the tested workload.

Higher is generally better, but always look at it together with p95 and errors. A system that shows a big number but becomes unstable at 30 concurrency is telling you something important.

2) p50 and p95: speed vs “slow tail”

• p50 is the “typical” response time (median).
• p95 is the slow tail: the requests that start to lag when your server is under parallel load.

If p50 looks fine but p95 spikes at higher concurrency, you’re likely hitting a bottleneck (CPU saturation, database contention, PHP workers, object cache behavior, etc.).

3) Errors and stability: the part people ignore

If errors appear during the 15 or 30 stage, treat that as a hard warning for real traffic spikes. Capacity isn’t just “fast”; it’s fast and stable under concurrency.

How to estimate “visitors capacity” from req/s (without lying to yourself)

This is the part most guides get wrong. There is no universal conversion from requests per second to visitors, because visitors generate different numbers of requests depending on your theme, plugins, caching, and user behavior.

But you can create a useful estimate by using a simple model:

• Step A: decide what a “typical visit” means for your site (example: 2 pages viewed).
• Step B: estimate how many server-side requests each page view causes in your setup (cached vs uncached matters a lot).
• Step C: use your Throughput Check req/s as an internal ceiling for PHP/WordPress execution.

Quick example (keep it conservative): if your test shows 80 req/s stable and your “real visit” effectively generates ~4 meaningful server-side requests, you’re looking at roughly 20 visits per second during that kind of workload. Convert that into per-minute or per-hour only after you sanity-check with your analytics and caching configuration.

Use this estimate to compare environments (hosting A vs hosting B), validate changes (before/after a plugin), and set safe expectations for campaigns — not as a marketing number.

Understanding the A–D grade

Throughput Check assigns a grade based on estimated req/s:

• A: ≥ 120 req/s
• B: ≥ 80 req/s
• C: ≥ 50 req/s
• D: < 50 req/s or errors detected

Think of the grade as a quick internal baseline. The real value is the stage-by-stage table: it shows how your system behaves as concurrency rises.

When to use Throughput Check (best moments)

• Before a launch or marketing campaign (baseline + risk check)
• After moving hosting / changing PHP version (compare results)
• When a site “feels slow” but front-end tools don’t explain why
• When you want a quick capacity snapshot without external stress tools

What to do if results are low or unstable

If you see low req/s, high p95, or errors at 15/30 concurrency, don’t guess. Use the results as a pointer:

• Compare the environment snapshot (PHP version, memory limit, active plugins).
• Repeat the test after one change at a time (plugin off, caching layer tweak, PHP workers).
• Use the same workflow to compare staging vs production or two hosting providers.

The goal is not a perfect number — it’s a repeatable, quick way to understand internal capacity and reduce surprises.

FAQ