PHP Workers Explained: Why a Busy Site Slows Down

Short answer: A PHP worker is a process on your server that builds one page at a time. If your site gets more simultaneous requests than it has free workers, the extra visitors wait in a queue and the site feels slow or shows errors. You fix it by serving more pages from cache, shortening the time each request takes, blocking wasteful traffic and, only then, buying more workers.

What a PHP worker is

When someone opens a page on a WordPress site, the web server hands the request to PHP, the programming language that builds the page from your theme, plugins and database. The process that does this job is called a PHP worker. Each worker can handle one request at a time. When it finishes, it takes the next request in line.

Your hosting plan decides how many workers you have. Cheap shared plans may share a pool among many sites and hide the number, while some managed WordPress hosts state it openly, for example “2 workers” or “4 workers”. Technical names differ, such as PHP-FPM children or processes, but the idea is the same: a fixed number of lanes, and every request needs one.

A restaurant is a fair comparison. The workers are the cooks. If every dish takes a few minutes and there are two cooks, you can serve a table every minute or so. If twenty tables arrive at once, the last guests wait a long time, even though the kitchen is working as fast as it can.

Why a site is quick for you and slow for a crowd

If you test your site alone, every request finds a free worker, so the speed you see depends only on how fast the code runs. Under load the picture changes, because a request that must wait for a free worker adds queue time on top of the processing time.

A simple calculation shows the limit. If a page takes half a second to build and you have four workers, the site can complete about eight uncached requests per second. That is plenty for a small business site with a few visitors a minute, but a sale email, a social media post or an aggressive bot can push far more requests than that in a few seconds.

Once the queue is long, the server may give up on some requests and return an error such as 503, 504 or, on some hosts, 508. If you see those under load, read the 508 resource limit error and why a website slows during traffic spikes.

What uses a worker and what does not

This is the most useful part to understand, because it shows where to act. A page that is served from cache is delivered by the web server, or by a CDN, without running PHP. It needs no worker and takes a few milliseconds. A page that is not cached must run through PHP, and that holds a worker for the whole time the page is being built.

Typical requests that always use a worker include:

Logged-in users, including editors in the dashboard and customers with an account.
Shopping carts, checkouts and account pages, which are normally excluded from caching.
Search results and pages with unusual query strings.
Background calls such as admin-ajax.php and the REST API, described in admin-ajax.php high usage.
Scheduled tasks triggered by visits, covered in WordPress cron and performance.
Bots and scrapers that request pages the cache has not stored yet.

This is why an online shop usually needs more workers than a brochure site that has the same number of visitors. Many of its requests cannot be cached.

Signs that you are running out of workers

The site is fast when you test at night and slow at busy moments.
The time to first byte rises sharply under load, while images and scripts load normally.
The dashboard becomes very slow while the front end stays quick, or the other way around.
Errors like 502, 503 or 504 appear in bursts.
Your host’s dashboard shows resource limits reached, entry processes at maximum or a worker graph that stays flat at the limit.

Look at the pattern over time. If slow periods match your newsletter, a campaign or a crawler visit, the cause is concurrency, not a general lack of speed. Server logs help you see who is making the requests, as explained in reading access logs to spot attacks.

Keep a simple note each time it happens: the time, what you were doing, and what the host reports. A week of notes usually reveals a pattern, such as a scheduled import, a backup that runs during working hours or a crawler that returns every morning. Moving such tasks to quiet hours costs nothing and can remove the problem without any other change.

Step one: cache more pages

The cheapest improvement is to stop using PHP for pages that do not need it. Full-page caching stores the finished HTML so that most visitors never reach PHP at all. Read page caching explained and how to choose a WordPress caching plugin. Check that your cache really works, especially for visitors who arrive with tracking parameters in the address, which can cause cache misses on some setups. A CDN can also serve cached pages close to the visitor, see whether you need a CDN.

An object cache helps the requests that cannot be page-cached, because it saves repeated database work. The guide to object caching with Redis explains when it is worth the effort.

Step two: make each request shorter

Workers are busy for as long as a request takes. If you halve the processing time, you double the capacity without paying for anything. Common causes of slow requests are:

Heavy plugins that run many database queries or call external services on every page. See how to find slow WordPress plugins.
Slow or bloated databases, covered in slow database queries in WordPress.
An outdated PHP version. Newer versions are usually faster, as described in PHP version and performance.
Calls to slow outside services, such as a payment or shipping lookup that waits for an answer.
Constant background polling from the dashboard, explained in the WordPress Heartbeat API.

One slow request can block a worker for ten seconds, which is the same as twenty fast ones. Tracking down the few slowest requests often gives more improvement than any hosting upgrade.

Step three: block the traffic you do not want

Not every request is a customer. Scrapers, vulnerability scanners and aggressive crawlers can fill every worker for minutes. Rate limiting, a web application firewall and simple bot rules turn them away before they reach PHP. See bad bots and aggressive crawlers and rate limiting explained. Also protect the login page, because repeated login attempts use a worker each time, as described in login brute-force protection.

Step four: add capacity only when needed

If the site is cached, efficient and protected, and it still runs out of workers, then more workers are a fair purchase. Raising the number without fixing slow code treats the symptom: the same wasteful requests simply use a bigger pool, and the bill rises. Compare plans by what you actually need, and see shared hosting versus VPS for the next step up.

Be cautious with plans that advertise “unlimited” resources. Behind the claim there is still a limit on simultaneous processes, and when you reach it the host may slow or stop your site without a clear message. Ask the provider in plain words how many requests your plan can process at the same time and what happens when that number is exceeded. A clear answer is a good sign of an honest host.

Before you buy, measure. Note the number of simultaneous requests at your busiest times, the average time per uncached request and the share of requests that are cached. With those three numbers you can estimate the number of workers you need and discuss it with your host in specific terms.

How Site AI Audit helps

Site AI Audit does not count your PHP workers or load-test your server. It reports Google PageSpeed measurements for your site, including LCP, CLS and INP, along with server response time, compression and page weight, together with SEO, security headers, SSL and e-mail authentication. A high server response time is a hint that requests are slow or queued. The first check is free, covers up to 50 pages and needs no sign-up. You can run a free check of your website or see the plans for weekly monitoring.

The bottom line

PHP workers are the lanes your site uses to build uncached pages. When the lanes are full, visitors queue and the site slows down or fails. Cache what you can, shorten the slow requests, block unwanted bots and buy more workers last. A few simple measurements will tell you which of these steps matters most for your site.

BUJ

How many PHP workers does my site need?

It depends on how many uncached requests arrive at the same time and how long each takes. A small cached site may need only two, while a busy shop may need many more.

Do cached pages use a PHP worker?

No. A page served from a full-page cache or a CDN is delivered without running PHP, which is why caching is the most effective first step.

Why is my admin area slow even with few visitors?

Dashboard requests are never cached and often run heavy queries. A few editors working at once can keep several workers busy.

Will more workers make my site faster?

Only if requests are queuing. They do not make a single slow request faster, so fix slow code first.

How do I see the worker limit on my host?

Check your hosting dashboard or plan description, and ask support for the PHP-FPM or process limit if it is not shown.