WooCommerce Hosting Requirements Calculator
Calculate recommended CPU cores, RAM memory, PHP workers, and Redis caching setup for your WooCommerce catalog size and concurrency.
Store Profile
Without edge offloading, every visitor session consumes origin PHP workers and CPU cycles during database query execution.
Sizing a WooCommerce Hosting Plan: PHP Workers, RAM & Object Cache
1. Why WooCommerce Hosting Sizing Differs From a Standard WordPress Site
A brochure or blog WordPress site can be served almost entirely from a page cache — most visitors never touch a PHP worker at all. WooCommerce breaks that model: cart contents, session data, and checkout are unique per visitor by definition and can't be cached the same way, which means a meaningful share of every WooCommerce store's traffic always reaches PHP and the database directly. This is exactly why hosting plans sized for a "typical WordPress site" of similar traffic frequently under-provision a WooCommerce store — the caching assumptions that work for content sites don't hold for commerce.
2. How These Recommendations Are Calculated
PHP worker count scales from peak concurrent visitors (roughly one worker per 4 concurrent visitors, reflecting typical request duration and reuse), CPU cores step up in tiers as worker count grows, RAM scales primarily with catalog size (SKU/variation count) rather than traffic since a larger catalog means more data loaded and cached per request, and Redis object caching is flagged as recommended once either catalog size or concurrency crosses a threshold where WordPress's default database-backed object cache becomes a measurable bottleneck. Toggling static edge offloading dramatically reduces the PHP worker, CPU, and RAM figures because catalog-page requests — typically the majority of total traffic on a WooCommerce store — no longer reach the origin server at all.
3. How to Use This Calculator
- Enter your actual monthly order count and total SKU/variation count from your store admin.
- Estimate peak concurrent visitors — check your analytics for your busiest hour's concurrent-user figure, not your daily average.
- Compare the recommendation with and without static edge offloading to see the infrastructure impact of removing catalog traffic from the origin.
- Use the output as a starting conversation with your host or infrastructure team, not a final purchase decision — see limitations below.
4. Common Sizing Mistakes
- Sizing for average traffic instead of peak. A store that's comfortable at typical daily traffic can still fall over during a flash sale or ad campaign spike if PHP worker capacity was never sized for peak concurrency.
- Ignoring plugin overhead. Heavy WooCommerce extensions (subscriptions, bookings, multi-vendor, POS sync) add their own database and CPU load on top of core WooCommerce — this calculator's baseline doesn't account for a specific plugin stack's overhead.
- Assuming more RAM alone fixes slow checkout. Checkout latency is frequently a database query or third-party API bottleneck (payment gateway calls, tax/shipping API round-trips), not a memory constraint — throwing more RAM at a query-bound problem doesn't help.
5. Who This Calculator Is For
Store owners evaluating whether their current hosting plan matches their actual catalog and traffic profile, developers scoping a hosting migration, and agencies producing infrastructure recommendations for WooCommerce clients who need a defensible starting point for the conversation.
6. Limitations
These are general sizing baselines derived from standard WooCommerce architecture patterns, not a benchmark of your specific server stack, plugin combination, or database health. Actual resource needs vary by hosting environment (shared vs VPS vs dedicated), PHP version and configuration, theme/page-builder overhead, and how many active plugins run on every request. Treat this as a starting estimate for a conversation with your host or infrastructure team, not a guaranteed specification.
Reduce WooCommerce origin hosting costs with Nimbica Edge
Offload up to 80-90% of origin web server requests to Cloudflare edge nodes for sub-50ms catalog performance.
Frequently Asked Questions
What are PHP workers and why do WooCommerce stores need more of them?
PHP workers are the processes that handle uncached, dynamically-rendered requests on your WordPress server — each one occupied for the full duration of a request. Because WooCommerce cart, checkout, and account pages can never be served from a traditional page cache (they're unique per visitor), and because a poorly-cached catalog pushes even product browsing through PHP, WooCommerce stores typically need more concurrent workers than an equivalent-traffic blog or brochure site.
How does static edge offloading reduce hosting hardware requirements?
By serving product catalog and category pages directly from edge nodes as pre-rendered static HTML, those requests never reach the origin server's PHP workers or database at all — only genuinely dynamic pages (cart, checkout, account) still hit the origin. Since catalog browsing is typically the majority of total requests on a WooCommerce store, removing it from origin load can allow a much smaller server plan to comfortably handle the same visitor volume.
Is Redis object caching actually necessary for a smaller WooCommerce store?
Not always — this calculator flags it as "Recommended" once a store crosses roughly 200 SKUs or 20 peak concurrent visitors, because that's where WordPress's default database-backed object cache starts becoming a measurable bottleneck (product lookups, cart session data, and transients all hit the database repeatedly without an object cache layer). Below that threshold, a store can often run fine without it, though Redis is rarely harmful to add early.
Why does the recommended RAM depend on SKU count and not just traffic?
RAM in this model isn't primarily about handling concurrent requests — it's about the memory footprint of loading and caching a larger product catalog's data (attributes, variations, meta) in PHP's memory during each request and across the object cache. A high-traffic store with a small catalog can run comfortably on less RAM than a low-traffic store with an enormous, highly-variable catalog, because catalog size drives per-request memory usage more directly than visitor count does.