The phrase turned up in a hosting comparison, or in a reply from your host’s support team: “your site is running out of PHP workers.” It sounds like staff you forgot to hire. In fact, once you have PHP workers explained properly, they become one of the most useful ideas for understanding why a WordPress site can be quick for one visitor and painfully slow for the tenth, on the same afternoon, with nothing changed.
This post explains PHP workers in plain language and shows how they affect website speed: what a worker does, which requests need one, what happens when they are all busy, and what you can do about it before paying for more. It deliberately gives no figures for hosting plans, because those differ between hosts and change often. The idea behind them does not.
PHP workers explained: what one actually does
WordPress is written in PHP. When a request arrives that WordPress has to answer itself, the server hands it to a PHP process. That process loads WordPress, runs the plugins and theme, talks to the database and produces the page. While it is doing that, it is busy. It cannot start on anyone else’s request until it has finished.
A PHP worker is one of those processes. Your server, or your hosting account, keeps a fixed number of them ready. Hosts call the limit different things: PHP workers, PHP processes, entry processes, concurrent processes. On servers that run PHP-FPM, it is set in the pool configuration. On shared hosting it is usually part of your account’s limits. The labels differ; the effect is the same. There is a ceiling on how many PHP requests your site can work on at the same instant.
A useful way to picture it is a pharmacy counter. Each pharmacist serves one customer at a time. If three pharmacists are on duty and three customers are at the counter, the fourth waits. If each customer’s order takes a while, the queue grows fast, even though the shop is not crowded.
Which requests need a worker
Not every request does. This is the part that explains most of the confusion.
| Request | Needs a PHP worker? |
|---|---|
| Image, stylesheet, script or font file | No. The web server sends the file directly. |
| Page served from a server or plugin page cache | Usually no, or only very briefly, depending on how the cache is set up. |
| Page that is not cached (first visit after a purge, excluded page) | Yes, for the whole time it takes to build. |
| Cart, checkout and account pages on a store | Yes, every time. |
| Any page a logged-in user views | Usually yes, since most caches skip logged-in visitors. |
| Background AJAX and REST API requests from plugins | Yes, each one. |
| Every screen in the WordPress admin | Yes. |
| WP-Cron runs, scheduled imports, backups started from WordPress | Yes, often for a long time. |
| Bots requesting pages that are not cached, or the login page | Yes. |
So a site with a hundred visitors reading cached blog posts may barely touch its workers. A store with ten customers adding to cart, while a staff member edits products and a plugin fires background requests every few seconds, can use all of them.
What happens when every worker is busy
New PHP requests wait in a queue. The visitor sees nothing unusual at first, just a page that takes longer to start loading. If the queue moves quickly, the delay is small. If requests are slow, the wait stretches.
If a request waits too long, something along the chain gives up. Depending on how the server is built, the visitor gets a 502, 503 or 504 error, or a hosting page saying a resource limit was reached. Our guide to 502, 503 and 504 errors on WordPress explains what each of those codes means when you see them.
The pattern that gives it away: the site is quick when you test it alone, but slow or failing when real traffic arrives, and it recovers by itself a few minutes later.
Time matters as much as the count
People tend to think only about how many workers they have. How long each request holds a worker matters just as much.
Think back to the pharmacy. Three pharmacists who each take a minute per customer can serve far more people in an hour than three who each take five. On a server, a page that takes a fraction of a second to build frees its worker almost immediately. A page that waits on a slow database query, or on an outside service such as a shipping rate lookup, holds that worker for the whole wait. During that time the worker is doing nothing useful, yet nobody else can use it.
This is why making uncached requests faster often does more than buying more workers. Halve the time each request takes and, in effect, you have doubled your capacity, without changing the plan.
Why stores and busy plugins run short first
WooCommerce is the classic case. Shoppers with something in their cart get personal pages that cannot be cached. The checkout talks to payment and shipping services. The admin is busy with orders. And several plugins make background requests from every open browser tab.
Two background sources are worth knowing by name:
- admin-ajax.php. Many plugins send requests to this file from the front end, for things like live search, popups, view counters or cart updates. Each one needs a worker. Our post on WooCommerce cart fragments covers one of the best-known examples.
- The WordPress Heartbeat. While someone has the editor open, the browser checks in with the server at intervals to autosave and manage post locks. Several staff with several tabs open add up.
Membership sites, learning platforms and booking systems behave similarly, because so much of what their users see is personal.
How to tell whether you are short of workers
Look for these together, not one at a time:
- Errors or very slow page starts that appear only at busy times and disappear on their own.
- Your hosting panel’s resource graph shows the process or entry-process line hitting its limit at those times.
- Cached pages stay quick while uncached pages, the admin and checkout slow down.
- The host’s error log mentions the process limit or the PHP pool reaching its maximum.
If the graphs show the site well under its process limit when it was slow, workers are not your problem. Look at the page itself instead. And if the slowdowns line up with campaigns, sales or newsletter sends, our post on why a site slows down when it gets busy walks through those situations.
Using fewer workers, before buying more
- Cache everything that can be cached. Every cached page is a request that never needs a worker. Check that ordinary pages really are being served from cache, especially after purges.
- Make uncached requests quicker. Slow queries and outside calls hold workers longest. Find them and fix or replace the plugin responsible.
- Cut background chatter. Look at the Network tab in your browser’s developer tools on a normal page. Repeating requests to admin-ajax.php or the REST API are worth questioning.
- Move scheduled work off visitor traffic. Heavy tasks triggered by WordPress’s built-in scheduler compete with customers for the same workers.
- Keep bots in check. Crawlers hammering uncached URLs, search pages or the login form use workers just as customers do.
Only when those are done, and the graphs still show the limit being hit by genuine visitors, is more capacity the right answer.
Questions to ask your host
You do not need the host to explain their whole architecture. These questions get the useful parts:
- What is the limit on simultaneous PHP processes for my account or plan, and what is it called in your panel?
- What does a visitor see when that limit is reached: a queue, a slow page, or an error page?
- Can you show me when my account hit the limit over the last month, and which URLs were being requested at the time?
- Is the limit per site or shared across all sites in my account?
- How long can a single PHP request run before it is stopped?
The third question is the most valuable. If the host can see that the limit was reached while a bot requested search pages, or while a plugin’s background request repeated every few seconds, you have found a cause you can fix yourself.
For how the server fits into speed more broadly, and what an upgrade can and cannot change, see our section guide on whether hosting affects website speed. It sits within our wider guide to website performance.
Frequently asked questions
Does a site with more PHP workers load each page faster?
Not on its own. One visitor’s page uses one worker, and extra workers sitting idle do not build that page any quicker. More workers help only when many uncached requests arrive together and some would otherwise wait. For a single visitor, the speed of each request is what counts.
Can a caching plugin stop me running out of PHP workers?
It can reduce the pressure a lot on sites where most pages are the same for everyone, because cached pages skip PHP. It cannot help with carts, checkouts, logged-in users, the admin or background plugin requests, so a store or membership site can still run short even with good caching.
Do PHP workers affect the WordPress admin?
Yes. Every admin screen is built fresh by PHP, and the editor also sends regular background requests. When several people work in the admin during a busy period, they use the same workers as your visitors, which is why the dashboard and the shop can slow down together.
Is a worker the same as a CPU core?
No. A worker is a process that handles one request at a time, while the CPU is the processor those processes run on. A server can have more workers than cores. If too many workers are busy doing heavy work at once, they compete for the processor and each one gets slower.
Seeing the process limit hit and unsure what is filling it? Our website speed optimisation includes a review of server response time alongside caching and database work. That way you learn whether the queue comes from the site or from the plan before paying for more, and any fixes wait for your approval.
Next in this series: HTTP/2 vs HTTP/3: What Changes and How to Check
