How much traffic can WordPress handle?
The honest answer depends on caching, so here is a real number to start from. A fresh WordPress 6.8 install from the official Docker image, MySQL 8.4, no cache plugin, on a 4 vCPU / 8 GB server, answered about 75 requests a second with every core busy. Past about 200 simulated users, requests started timing out. Here is what ran out, what that means in visitors, and what raises the limit.
WordPress 6.8 with no cache on 4 vCPU / 8 GB
| Simulated users | What WordPress did |
|---|---|
| Under 100 | 69 requests a second, p95 950 ms, no errors |
| 100 to 200 | 77 requests a second, p95 about 3 s, no errors |
| About 210 | Requests a second stopped growing, at about 78 |
| About 250 | 75 requests a second, p95 3.4 s, 8% timed out |
| About 500 | 77 requests a second, p95 3.4 s, 29% timed out |
| About 1,000 | 63 requests a second, 57% timed out |
| About 1,500 | 26 requests a second, 85% timed out |
| 2,400 to 2,500 | 64 requests a second, 78% timed out |
| Whole run | 23,326 requests answered, 55,946 timed out (71%) |
The short answer
With no cache, this setup topped out at about 75 to 78 requests a second. That was the ceiling. Past about 200 simulated users, more users did not get more requests answered. They waited in line until they hit the 10 second timeout.
With a page cache or a CDN in front, most logged-out visitors get a saved copy of the page instead of WordPress building it again, and this ceiling stops being the number that matters for them. Logged-in users, carts, checkouts and anything else the cache skips still run into it.
What ran out
CPU, on every core. All 4 cores were over 90% busy from about the first second, with the work spread across Apache and its PHP worker processes, none of them above 5% of a core. MySQL used about half a core, so the database was not the limit. PHP building every response was.
OPcache was already on, because the official image enables it. So this is not the "you forgot OPcache" case. It is what PHP and WordPress cost per request on a fresh install.
That is the opposite of the Node.js apps we tested on the same server size, which each filled one core and left the rest idle. WordPress really does use every core you give it.
From requests a second to visitors
A simulated user in this test sends a request, waits for the answer and sends the next one straight away. A real visitor loads a page and then reads for a while. So 200 simulated users is far more traffic than 200 people on your site at once. Compare requests a second, not users.
An uncached page view costs roughly one PHP request, since images, CSS and JavaScript are static files that Apache sends without running WordPress. If your pages cost about as much as this API call, 75 a second is about 4,500 page views a minute, or 270,000 an hour at a perfectly even rate.
Traffic is never even. A link from a big site or a newsletter send puts most of its clicks into the first few minutes, so plan for the busiest minute, not the daily average. And a real theme with plugins often does more work per page than this bare API call on a fresh install, so your own ceiling can be lower.
What raises the limit
A page cache for logged-out visitors. Plugins such as WP Super Cache or W3 Total Cache save the finished HTML of a page and send that copy to the next visitors. For a blog or marketing site, where nearly everyone is logged out, this is usually the first thing to do. Check whether your host already caches at the server level before adding a plugin.
A cache in front of WordPress. A reverse proxy cache (nginx fastcgi_cache, Varnish) or a CDN with a short TTL answers repeated requests before they reach Apache and PHP at all. That also covers the REST API, which most page cache plugins do not cache by default.
An object cache, when the database is the slow part. Redis or Memcached with an object cache plugin keeps the results of repeated queries in memory. In this run MySQL was not what ran out, so it would not have moved the ceiling much. Sites with heavy plugins or a large store lean on the database more, so check before adding one. The official Docker image does not include the PHP Redis extension, so you would add it to your own image.
Fewer plugins on uncached pages. Every active plugin loads on every request that misses the cache, so each one adds PHP work to every logged-in page, cart and API call.
A bigger server. Because WordPress used every core, more cores do raise the uncached ceiling. The run report sized this setup at 8 vCPU / 16 GB to comfortably serve about 100 requests a second. That is a lot of server for 10 posts, which is why a cache usually comes first.
What this test does not tell you
One read only endpoint (GET /wp/v2/posts through the REST API, 10 posts), logged out, no theme rendering, no plugins, one run on shared vCPU with all load from one place. Your theme, plugins and content change the number. Use it as a reference point for a fresh install, not as your answer.
Test your own WordPress setup
The compose file used here is public at github.com/DevMatei/stresix-showdowns: WordPress, MySQL and a small wp-cli service that installs it and adds the posts. Copy it, add your theme and plugins, and point Stresix at your repository. It starts the stack on a fresh server, ramps up simulated users, and the report shows requests a second, p95, and which service ran out first. Run it once without your cache and once with it to see what the cache is worth. Your first run is free.
Frequently asked questions
How many visitors can WordPress handle?
It depends mostly on caching. In our run, a fresh WordPress 6.8 install with no cache on a 4 vCPU / 8 GB server answered about 75 requests a second before requests started timing out. With a page cache or CDN in front, most logged-out visitors never reach PHP, so the uncached number matters mainly for logged-in users and pages the cache skips.
Does WordPress use all CPU cores?
Yes. Requests run in separate PHP worker processes, so the work spreads across cores. In this run all four cores were over 90% busy from about the first second.
Will a bigger server make WordPress faster?
For uncached requests, more cores raise the ceiling, because WordPress used every core here. For logged-out traffic, a page cache or CDN is usually the cheaper first step.
Is the database the bottleneck in WordPress?
Not in this run. MySQL used about half a core while PHP kept all four cores busy. Sites with heavy plugins or large stores can be different, so measure before adding an object cache.
Related guides
Stop guessing your specs. Start knowing them.
Point Stresix at a repo or Docker image and get a number you can deploy on, in one run. Your first run is free, no card.
Start a free load test