Best Managed Hosting for WooCommerce (PHP Workers Explained)
Most WooCommerce hosting advice tells you to pick a plan by visit count. For a store, that's the wrong metric, and following it is how people end up on a "fast" plan that falls over the moment a few shoppers check out at once. The number that actually predicts whether your store stays up under load is PHP workers, and it's the spec most managed plans bury. Once you understand why carts break the usual caching playbook, the right WooCommerce host gets obvious, and it's often not the one with the biggest visit allowance.
What a PHP worker actually is
A PHP worker is a slot that runs one PHP request at a time. If your plan has 3 workers and 5 people simultaneously load an uncached page, 3 are served right away and 2 wait in line. Add more concurrent uncached requests than you have workers, and the queue grows: pages slow, then time out. On a content site this rarely bites, because most pages are cached and served without touching a worker at all. A store is different, and that difference is the whole article.
Why WooCommerce breaks the caching playbook
Managed WordPress hosting is fast largely because it caches pages, serving a stored copy instead of rebuilding it with PHP. That works beautifully for blog posts and landing pages. It does not work for the three pages that matter most in a store: cart, checkout, and my-account cannot be cached, by design. Each one runs live: validating coupons, checking inventory, calculating tax and shipping, processing payment. Every one of those requests needs a PHP worker, and holds it for the duration.
So a store's load profile is the opposite of a blog's. Your traffic number can look modest while your concurrent uncached requests, people actually shopping and checking out, overwhelm a small worker pool. This is why a store on a plan with a generous visit limit but only 2 workers can crawl during a sale: the visits aren't the constraint, the simultaneous checkouts are. (It's the same reason cache-everything advice fails for stores, you must exclude /cart/, /checkout/, and /my-account/ from caching, which throws them straight onto the workers.)
Worker counts, compared
This is where WooCommerce-built hosts separate from general managed WordPress. Published worker figures (verify current specs, they change by tier):
| Host | PHP workers | Built for stores? |
|---|---|---|
| Shared hosting | ~1-2 | No |
| Kinsta (entry) | ~2, scaling to ~8 on higher tiers | Smaller stores only on entry |
| WP Engine | Per-tier limits (scale with plan) | OK on higher tiers |
| Rocket.net | Unlimited (all plans) | Yes |
| Nexcess | Auto-scales to 100+ | Yes (WooCommerce specialist) |
Which host to pick
- Rocket.net → unlimited PHP workers on every plan removes the worker question entirely, strong default for a store that wants headroom without tier-juggling. (Now part of the hosting.com group as of 2025.)
- Nexcess → the dedicated WooCommerce specialist: auto-scaling workers to 100+, store-specific tooling, PCI-compliant infrastructure, and no visit overage. The caveat to state plainly: Nexcess is owned by private equity (One Equity Partners, via Liquid Web), so if PE ownership is a concern for you, weigh that, see managed WordPress not owned by private equity.
- Kinsta / WP Engine → fine for smaller stores, but mind the worker count on lower tiers; a 2-worker entry plan is a content-site plan, not a store plan. You may need to size up specifically for concurrency, not visits.
The rule that saves stores: buy for concurrent checkouts, not for visits. Estimate your peak simultaneous shoppers (especially during promos), and make sure the worker pool clears it with room to spare. A store that goes down during its own sale loses far more than the cost of the bigger plan.
FAQ
What are PHP workers and why do they matter for WooCommerce?
A PHP worker runs one PHP request at a time. WooCommerce carts, checkout, and my-account can't be cached, they run live PHP per request, so each concurrent shopper holds a worker. Too few workers and checkouts queue or time out. Worker count predicts store performance better than visit limits.
How many PHP workers does WooCommerce need?
More than a typical entry plan. Shared hosts give 1-2; entry managed plans can be as low as 2, which chokes under a few simultaneous checkouts. WooCommerce-built hosts offer far more, Rocket.net advertises unlimited, Nexcess auto-scales to 100+. Aim for double-digit workers minimum, scaling with concurrency.
What's the best managed WooCommerce host?
For worker headroom: Rocket.net (unlimited) and Nexcess (auto-scale 100+, WooCommerce specialist). Nexcess is the dedicated choice but is PE-owned (One Equity Partners via Liquid Web). Kinsta and WP Engine work for smaller stores if you size up for concurrency.
Can't I just cache the checkout to fix this?
No, and you shouldn't try. Cart, checkout, and my-account must be excluded from caching or they break (stale prices, wrong cart, failed orders). That's exactly why they hit PHP workers directly, and why worker count, not caching, is the lever for store performance.