PHP workers are the processes on your server that handle dynamic PHP requests — the uncached, live work that builds pages for platforms like WordPress. Each PHP worker can process one such request at a time, so the number of PHP workers a plan provides sets how many simultaneous dynamic requests your site can handle before others have to queue. For dynamic sites — especially WooCommerce stores, membership sites, and busy WordPress sites — PHP workers are often the real capacity limit, more so than bandwidth or storage.
This guide explains what PHP workers do, why they matter, what happens when you run out, and how to tell whether a plan has enough for your site.
Did you know?
For a dynamic WordPress site, PHP workers are frequently the true bottleneck. A store can have ‘unlimited’ bandwidth and plenty of storage yet still slow down because it has run out of PHP workers.
What a PHP worker does
PHP is the language WordPress and many other platforms are built in, and a PHP worker is a process that executes PHP code to build a page. When a request comes in that cannot be served from cache — a cart update, a logged-in dashboard, a form submission — a PHP worker runs the code, queries the database, and assembles the response.
Crucially, each PHP worker handles one such request at a time. So if your site receives several uncached dynamic requests simultaneously, each needs a worker. The number of PHP workers your plan provides therefore determines how many of these live requests can be processed at once.
Why PHP workers matter for dynamic sites
Static, cached pages barely touch PHP — they are served ready-made, so they do not consume a worker. Dynamic, uncached requests are different: every one needs a PHP worker. This is why PHP workers matter most for dynamic sites where much of the activity cannot be cached.
WooCommerce carts and checkouts, membership dashboards, and busy interactive WordPress sites generate lots of uncached requests, so they lean heavily on PHP workers. For these sites, the PHP worker count is often the real limit on how many users can be actively doing things at once.
What happens when you run out
When all your PHP workers are busy, additional dynamic requests have to queue and wait for a worker to free up. To the visitor, that shows up as slowness — pages that take longer to respond during busy periods — and, if the queue grows too long, timeouts or errors.
This is a common cause of a store or membership site feeling sluggish under load even when bandwidth and storage are fine. The site has effectively hit its concurrency limit: not enough workers to serve everyone’s live requests at once, so people wait in line.
How many PHP workers do you need?
It depends on how dynamic your site is and how many people use it at once. As a rough guide:
- Simple, well-cached blog: few workers needed; most requests are cached.
- Small business site: a modest number is plenty.
- WooCommerce store: more workers, since carts and checkouts are dynamic.
- Membership site: more again, as logged-in pages cannot be cached.
- Busy or high-concurrency site: the most, to serve many live requests at once.
Pro Tip
Good caching reduces how many PHP workers you need, because cached pages skip PHP entirely. Before buying more workers, make sure caching is working — it frees workers for the requests that genuinely need them.
How to tell if a plan has enough
When comparing plans for a dynamic site, look for the PHP worker count — good hosts publish it. Entry plans provide fewer workers, and higher tiers provide more, which is one of the main reasons a busy store or membership site is pushed toward a larger plan.
If your current site slows specifically during busy periods while bandwidth and storage look fine, PHP workers are a likely cause. The fix is either better caching (to reduce demand for workers) or a plan with more workers (to increase supply). Checking this number is key for any dynamic site.
Getting the most from your PHP workers
You can make your PHP workers go further before needing more. Strong caching is the biggest lever, since it serves cached pages without touching PHP, leaving workers free for genuinely dynamic requests. Optimising your site — efficient plugins, a current PHP version, a fast database — also lets each worker finish faster and serve the next request sooner.
So the strategy is: cache aggressively, keep the site lean and current, and choose a plan whose PHP worker count matches how dynamic and busy your site is. Do that, and your site stays responsive under load rather than queuing visitors during the moments that matter most.
Want hosting with generous, honest specs?
Hostinger’s plans come with fast NVMe storage, ample resources, free SSL, and clear limits — no fine-print surprises. From a few dollars a month; use code PROTIPS for the reader discount.
FAQs
What are PHP workers in web hosting?
PHP workers are server processes that handle dynamic PHP requests — the uncached, live work that builds pages for platforms like WordPress. Each worker processes one such request at a time, so the number of workers sets how many simultaneous dynamic requests your site can handle before others queue.
Why do PHP workers matter?
Because dynamic, uncached requests — carts, checkouts, logged-in dashboards, form submissions — each need a PHP worker, while cached static pages do not. For dynamic sites like WooCommerce stores and membership sites, the PHP worker count is often the real limit on how many users can be active at once.
What happens when a site runs out of PHP workers?
Additional dynamic requests queue and wait for a worker to free up, which visitors experience as slowness during busy periods and, if the queue grows too long, timeouts or errors. It is a common reason a store or membership site feels sluggish under load even when bandwidth and storage are fine.
How many PHP workers do I need?
It depends on how dynamic and busy your site is. A well-cached blog needs few; a small business site needs a modest number; a WooCommerce store or membership site needs more because their pages cannot be cached. Busy, high-concurrency sites need the most workers.
Does caching reduce PHP worker usage?
Yes, significantly. Cached pages are served ready-made without running PHP, so they do not consume a worker. Good caching frees your workers for the genuinely dynamic requests that need them, so it is worth ensuring caching works before buying a plan with more workers.
How do I know if my plan has enough PHP workers?
Check the PHP worker count in the plan’s specs — good hosts publish it. If your site slows specifically during busy periods while bandwidth and storage look fine, PHP workers are a likely cause. The fix is better caching to reduce demand, or a plan with more workers.
The bottom line
PHP workers are the server processes that handle dynamic, uncached PHP requests, each processing one request at a time. The number your plan provides sets how many simultaneous live requests your site can handle before visitors queue — which makes PHP workers the real capacity limit for dynamic sites like WooCommerce stores, membership sites, and busy WordPress installs.
When workers run out, the site slows during busy periods, so match the worker count to how dynamic and busy your site is. Cache aggressively to free workers for requests that truly need them, keep the site lean and current, and check the PHP worker figure when comparing plans — it tells you far more about a dynamic site’s capacity than bandwidth or storage.
When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. PHP workers handle live requests one at a time — for dynamic sites they are often the true capacity limit.