Most WordPress owners have never heard of a PHP worker, and most of the time they don’t need to. But when a site slows down under load, or starts throwing intermittent errors during a traffic spike, the worker pool is usually the reason. It’s one of the quietest limits in hosting, and one of the most misunderstood.
What Exactly Is a PHP Worker
A PHP worker is a process that can execute one PHP request at a time. When a visitor loads a page, submits a form, or an admin saves a post, that request gets handed to a worker, which runs the PHP code, talks to the database if needed, and returns a response. Then the worker is free to pick up the next request.
Every server has a finite number of these workers running at once, set by the PHP process manager (commonly PHP-FPM). If your plan has, say, a pool of a certain size, that is the maximum number of PHP requests that can be actively processed at the exact same moment. It has nothing to do with total visitors per day. A site can get thousands of daily visits with no trouble and still choke during a five minute burst, because the burst is what matters. Concurrency, not volume, is the real constraint.
What Happens When Every Worker Is Busy
When all workers are occupied and a new PHP request comes in, it has to wait. If a worker frees up quickly, the wait is invisible. If not, requests start queueing, and the visitor experience degrades in a specific order:
- Time to first byte climbs, because the request is sitting in a queue before PHP even starts running it.
- Pages that were fast suddenly feel sluggish, particularly forms, search, cart and checkout flows, and anything logged in through wp-admin.
- If the queue backs up long enough, the web server gives up and returns a 502 or 503 error instead of a page.
- Core Web Vitals suffer directly. Interaction to Next Paint (target 200ms or under) and Largest Contentful Paint (target 2.5s or under) both depend on the server responding promptly. A saturated worker pool is one of the more common causes of INP and LCP regressions that have nothing to do with your theme or JavaScript.
This is why a site can pass every speed test run in a quiet moment and still fall apart during a sale, a viral post, or a bot crawl. The workers were never the problem at rest. They become the problem under concurrency.
Why Caching Is the Real Capacity Lever
You could add more workers, and sometimes that’s the right move, but the more efficient lever is making sure fewer requests need a worker at all, and that the ones that do finish faster. That’s what caching actually does, at every layer.
Full-page caching, like what LiteSpeed Cache provides on a LiteSpeed or OpenLiteSpeed server, stores a complete rendered copy of a page and serves it directly, often without invoking PHP at all for anonymous visitors. A page served from full-page cache never touches a worker. If most of your traffic is anonymous visitors browsing public pages, and full-page caching is configured well, you can serve a large multiple of your uncached capacity from the same worker pool, because those requests simply never enter the queue.
Persistent object caching, using Redis or Memcached as a drop-in, works differently but complements this well. It caches the results of expensive database queries and computed values in memory, so pages that do need PHP (logged-in users, dynamic content, WooCommerce carts) still run through a worker, but the worker finishes its job faster because it isn’t re-querying the database for things that haven’t changed. Faster execution means the worker returns to the pool sooner and is available for the next request. This matters enormously for stores and membership sites where full-page caching alone can’t cover every request.
Cloudflare in front of the origin adds a third layer. Edge caching can serve static and cacheable content straight from Cloudflare’s network before the request ever reaches your server, and the WAF and bot mitigation filter out a meaningful share of junk traffic (scrapers, credential-stuffing attempts, aggressive crawlers) before it can consume a worker at all. Keeping your origin IP unpublished also matters here: it’s part of what makes DDoS attempts land on Cloudflare’s edge instead of directly saturating your worker pool.
Diagnosing Worker Pressure
The tell-tale signs are intermittent, load-dependent slowness: a site that’s fine most of the day and chokes during specific windows, or 502/504 errors that come and go rather than persisting. Check your hosting dashboard or server stats for worker or process count during those windows. It’s also worth auditing what your plugins are doing with wp-cli, since plugins that run expensive queries, external API calls, or heavy cron jobs on every request hold a worker longer than they should, which quietly lowers your effective concurrency even before traffic grows.
wp plugin list --status=active
wp cron event listA long list of active plugins isn’t inherently bad, but a few heavy ones doing uncached database work on every page load can matter more than the total count.
Practical Ways to Stretch Capacity
- Enable full-page caching for anonymous traffic wherever your setup allows it.
- Add persistent object caching with Redis or Memcached, especially for WooCommerce, membership, or logged-in-heavy sites.
- Run PHP 8.3 with OPcache enabled. Newer PHP versions execute code faster, which shortens the time each worker spends per request.
- Put Cloudflare in front of the site for edge caching, WAF filtering, and bot mitigation, and keep the origin IP unpublished.
- Audit plugins for ones doing unnecessary uncached queries or excessive cron activity.
This is one area where a managed host earns its keep: a stack that pairs LiteSpeed with tuned worker pools, Redis object caching, and Cloudflare integration by default (which is how ServerBorn is set up) removes most of this tuning from your plate entirely.
The Takeaway
PHP workers are a hard, physical limit on how many requests your site can process at the exact same instant, and no amount of raw traffic capacity matters if a burst can exhaust that pool. The fix usually isn’t more workers, it’s fewer requests needing one in the first place, and faster completion for the ones that do. Full-page caching, object caching, current PHP, and an edge layer like Cloudflare all work together to multiply what a modest worker pool can actually handle.