How to Choose the Best Hosting for WooCommerce: Speed, Workers, and Scale

Most WooCommerce speed advice is really WordPress speed advice with "eCommerce" pasted on top. That's the problem. A WooCommerce store isn't a blog with a shopping cart bolted on — cart and checkout pages can't be cached, every logged-in session hits the database, and a host that looks fast in a GTmetrix screenshot can still choke the moment ten people try to buy at once.

The best hosting for WooCommerce gives your store dedicated PHP workers for concurrent checkouts, persistent Redis object caching to keep MySQL from buckling under product queries, and the headroom to scale without a plan migration during your next sale. Static page caching — the thing most "fast hosting" marketing leans on — barely touches the pages where you actually make money.

Hosting is usually the last thing store owners think to blame and the first thing that's actually broken. Below is what to check before you sign a 12-month contract, based on current benchmarks and how PHP workers, object caching, and database load actually behave under a real checkout flow.

Key Takeaways

• Cart, checkout, and account pages bypass page cache entirely — every visit consumes a live PHP worker, so worker count (not cache) is what determines checkout capacity.
• Kinsta ties PHP worker allocation directly to plan tier: 2 workers on Starter, 4 on the $115/month Business 1 plan (Kinsta's own recommended minimum for WooCommerce), up to 16 on Enterprise tiers.
• Redis persistent object caching can cut database queries by 50-80% on dynamic WooCommerce pages, according to hosting-performance write-ups analyzing query load before and after enabling it.
• Portent's analysis of billions of page views found ecommerce sites loading under 2 seconds convert at 3.05% versus 1.94% for sites loading in 3-4 seconds — a 57% difference from one second of load time.
• Google and Deloitte's "Milliseconds Make Millions" study found a 0.1-second mobile speed improvement lifted retail conversion rates by 8.4% and average order value by 9.2%.
• Cloudways offers far higher raw PHP worker ceilings than Kinsta, but Kinsta's container-based isolation and auto-scaling make it the safer default for stores that can't babysit server config during a traffic spike.

What Makes WooCommerce Hosting Different From Regular WordPress Hosting?

WooCommerce hosting is WordPress hosting engineered for pages that can't be cached — cart, checkout, and my-account — where every visitor triggers live PHP execution and direct database reads instead of a served static file. It differs from standard WordPress hosting in worker allocation, object caching support, and database tuning, because a blog can survive on page cache alone and a store cannot.

That distinction sounds pedantic until you watch it break in production. A content site with good page caching can serve 10,000 concurrent visitors off a handful of PHP processes, because Varnish or a similar layer intercepts the request before PHP ever wakes up. A WooCommerce store can't do that for the pages where revenue happens. WooCommerce explicitly excludes cart, checkout, and account pages from full-page caching plugins by default, precisely because caching a cart page risks showing one shopper another shopper's contents — a bug that's cost real stores real trust, not just theoretical risk.

Why Speed Actually Moves Revenue on a WooCommerce Store

The stats here get thrown around loosely, so it's worth being precise about where they come from. Portent's research, drawn from billions of tracked page views, found the average ecommerce conversion rate for pages loading in under 2 seconds is 3.05%, compared to 1.94% for pages loading in 3-4 seconds — a 57% relative lift from that one-second difference. Portent's broader dataset also shows conversion rates dropping by roughly 0.3 percentage points for every additional second of load time, on average.

Separately, a study commissioned by Google and conducted with Deloitte — "Milliseconds Make Millions" — tracked over 30 million mobile sessions across 37 retail and travel brands. It found that a 0.1-second improvement in mobile page speed lifted retail conversion rates by 8.4% and average order value by 9.2%, with travel brands seeing a 10.1% conversion lift from the same improvement. That's not a full second. That's one-tenth of one second, measured across real production sites, not a lab benchmark.

Here's the part that gets missed: neither of those studies is measuring homepage load time. They're measuring the speed of the pages deeper in the funnel — product pages, cart, checkout — which is exactly where static caching does you no good and PHP worker capacity does all the work.

PHP Workers: The Resource Nobody Checks Before Signing Up

A PHP worker is a single process that executes your site's PHP code — pulling product data, checking inventory, calculating cart totals — and hands back rendered HTML. Every uncached request, including every cart addition and every checkout step, consumes one worker for the duration of that request. Run out of available workers, and the next visitor queues behind everyone already being served.

This is the resource host marketing pages bury. "Unlimited bandwidth" and "unlimited visits" sound generous; worker count is what actually caps how many people can add to cart or check out at the same moment. Cloudways' own explainer on the topic puts it plainly: a PHP worker takes the code your site is built with, compiles it, and renders it for the visitor's browser, and every dynamic hit — checkout included — needs one.

Worker requirements scale with what your store actually does, not with traffic alone. A common industry starting point is 4 PHP workers for a store with real dynamic activity — enough to handle a handful of simultaneous checkouts without queuing. Sites with heavier concurrent checkout volume are frequently pushed toward 10-15 workers, and high-traffic stores toward 30 or more, according to hosting guidance aimed specifically at ecommerce sellers.

Where hosts differ sharply is how they gate that number:

• Kinsta ties workers directly to plan tier. The Starter plan ($35/month) includes just 2 PHP workers per site — workable for a low-traffic blog, thin for a store processing checkouts. Kinsta's own recommendation is the Business 1 plan at $115/month, which steps up to 4 PHP workers and is explicitly positioned as the WooCommerce minimum. Enterprise tiers scale to 8-16 workers.
• Cloudways takes the opposite approach — no fixed per-plan worker cap baked into the pricing tier, with far higher ceilings available as you scale server resources, and pricing starting around $14/month on entry-level cloud instances.

Neither number is inherently "better." Kinsta's caps are a tradeoff for isolation and predictability — you know exactly what you're getting and Kinsta manages the ceiling for you. Cloudways' openness is a tradeoff for control — you get more headroom, but you're the one deciding when to scale the underlying server, and getting that wrong under-provisions you during your busiest hour.

Redis Object Caching: What Actually Keeps MySQL From Falling Over

WordPress's default object cache is non-persistent — it exists only for the length of a single page load, then gets discarded, forcing the same database queries to run again on the next request. Redis replaces that with a persistent, in-memory store that survives across requests, so repeated lookups — product data, cart contents, session data — get served from memory instead of hitting MySQL every time.

WooCommerce leans on this harder than a typical WordPress site because it uses transients extensively for things like cart fragments and product lookups. Without a persistent object cache, every transient write becomes an INSERT or UPDATE against the wp_options table, and every read is a SELECT against a table that keeps growing. Enable Redis, and those transients move out of MySQL almost entirely — hosting-performance analyses comparing query counts before and after report 50-80% fewer database hits on dynamic pages once persistent object caching is active.

The catch: Redis needs a correctly set eviction policy to actually help. The default noeviction setting will start refusing new writes once memory fills up, which silently breaks caching instead of failing loudly. allkeys-lru is the standard recommendation for WordPress workloads, evicting the least-recently-used keys instead of choking. If you're checking whether Redis is doing its job on your current host, look at the hit ratio — under 60% generally means it isn't caching effectively for your traffic pattern, and it's worth comparing query volume before and after with a tool like Query Monitor.

Where Static Caching Stops Helping — and Live Resources Take Over

This is the part of WooCommerce hosting most buyers get backward: they shop for hosts based on homepage speed scores, then wonder why checkout still feels sluggish under load. Static full-page caching and live PHP/database resources solve different problems, and a host can be excellent at one while being mediocre at the other.

WooCommerce and most caching plugins explicitly exclude cart, checkout, and account pages from full-page cache by keying off cookies like woocommerce_items_in_cart — the moment a visitor has an active cart, cache gets bypassed for that session. That's correct behavior; caching a cart page risks leaking one customer's contents to another. But it also means a host advertising a 95/100 PageSpeed score on its marketing homepage tells you close to nothing about how that same host performs when 30 people are simultaneously on your checkout page during a flash sale.

PHP Memory Limits and Execution Time — the Quiet Failure Point

WooCommerce checkout, especially with several plugins and payment gateways stacked together, is memory-hungry. A PHP memory limit set too low doesn't usually crash the site outright — it throws a white screen or silently fails a checkout step, and the store owner finds out from an angry customer, not a server alert. 256MB is a reasonable floor for a WooCommerce install with a handful of plugins; stores running subscriptions, bookings, or heavier extensions often need 512MB or more.

Execution time limits matter just as much and get ignored more. A default 30-second max_execution_time is fine for a simple checkout, but it's tight for anything involving a slow third-party API call — real-time shipping rate lookups, tax calculation services, some payment gateway round-trips. If that call takes 35 seconds because the third-party API is having a bad day, a hard 30-second cap kills the transaction, not the third party. Hosts that let you raise these limits per-site, rather than forcing you into a fixed platform-wide default, give you room to absorb that kind of slow dependency without losing the sale.

Database Bloat: The Slowdown That Creeps Up on You

WooCommerce stores accumulate database weight in ways a blog never does — every abandoned cart, every guest checkout, every product view can generate rows nobody ever cleans up. The wp_options table is the usual offender, particularly the "autoloaded" options that WordPress pulls into memory on every single page load whether they're needed or not. A bloated autoload table doesn't fail dramatically; it just makes every page marginally slower, store-wide, and most owners never think to check it because nothing "broke."

This is where host-level tooling matters more than raw specs. A host that gives you visibility into slow queries, autoload size, and transient counts lets you catch this before it compounds. A host that just hands you phpMyAdmin and wishes you luck leaves you finding out the hard way, usually during your highest-traffic week of the year.

Scalability: Auto-Scaling vs. Manual Provisioning

Traffic spikes are not evenly distributed across a store's calendar — Black Friday, a viral mention, an email blast to your list can 10x traffic for a few hours and then vanish. How a host handles that gap separates a good WooCommerce host from a good general-purpose WordPress host.

Kinsta's infrastructure runs each site in an isolated container on Google Cloud Platform, and its higher tiers include auto-scaling that adds resources during a spike without you touching a dashboard. Cloudways takes a more manual, DIY-friendly route: you provision the server size upfront and vertically scale it yourself (or set up autoscale rules on supported cloud providers) when you see growth coming. That gives a technically comfortable owner more granular cost control — you're not paying for headroom you don't use most months — but it puts the responsibility for anticipating the spike on you, not the host.

A founder who checks server metrics weekly and knows their sales calendar can do very well on Cloudways at a lower monthly cost. A founder who wants to not think about infrastructure until something's wrong is better served paying more for Kinsta's managed auto-scaling — the cost difference is effectively an insurance premium against the 2am "the site's down during our biggest sale" call.

Security and PCI Considerations Specific to Stores

WooCommerce stores that handle any part of the payment flow directly — rather than fully offloading to a hosted checkout like Stripe Checkout — fall under PCI DSS obligations that a standard WordPress site doesn't have to think about. Even with tokenized payment gateways, a compromised host can expose customer order data, addresses, and partial payment metadata. Look for hosts offering free SSL with auto-renewal, server-level malware scanning, a web application firewall, and — critically — hourly backups rather than daily ones. A daily backup on a store doing steady sales can mean losing a full day of orders if something goes wrong; hourly backups cap that exposure to under 60 minutes in the worst case.

Common Mistakes Store Owners Make When Choosing Hosting

Picking a plan based on storage and bandwidth, not workers. Storage rarely runs out on a store; PHP worker capacity does, and it's the number most buyers never ask about.

Assuming a fast homepage means a fast checkout. These are measured by completely different mechanisms, as the table above shows. Ask any host directly what happens to cart and checkout performance under concurrent load — a vague answer is itself the answer.

Ignoring Redis until the site is already struggling. Object caching is dramatically easier to set up during initial build than to retrofit onto a store with a year of transient buildup and a bloated wp_options table.

Underestimating memory limits for a growing plugin stack. Every subscription add-on, loyalty plugin, and marketing integration adds memory overhead. What was comfortable at launch can be tight eighteen months later.

Treating all "WooCommerce-optimized" hosting claims as equivalent. The phrase gets used by hosts with 2 PHP workers on entry tiers and hosts with dedicated ecommerce infrastructure alike. Check the actual worker count and object caching support per plan, not the marketing label.

Kinsta vs. Cloudways vs. WP Engine for WooCommerce

All three are credible managed hosts, but they solve the WooCommerce problem differently, and the right pick depends on how hands-on you want to be with server management.

Kinsta runs every site in an isolated LXD container on Google Cloud Platform's premium tier network, which means one site's traffic spike can't starve another site's resources — a real risk on cheaper shared-container setups. Redis is built in on qualifying plans, PHP 8.2+ is standard, and the auto-scaling on higher tiers absorbs traffic spikes without manual intervention. The tradeoff is price: the $115/month Business 1 plan with 4 workers is Kinsta's own recommended WooCommerce floor, and that's before add-ons.

Cloudways wins on flexibility and cost. Starting around $14-50/month depending on the cloud provider and server size you choose, it gives technically comfortable owners direct control over PHP worker limits, Redis configuration, and server sizing — genuinely the strongest budget-to-power ratio for a founder willing to learn server basics or lean on Cloudways' support team. It's a legitimate choice, not just a cheaper compromise, for stores in growth mode that don't yet need fully managed infrastructure.

WP Engine sits closer to Kinsta on the managed spectrum but has historically been less generous with WooCommerce-specific tuning and Redis availability compared to Kinsta's default stack — worth checking current plan specs directly before assuming parity.

For a store where checkout downtime has a real dollar cost and you'd rather not be the one watching server load during a promotion, Kinsta's container isolation and worker allocation make it the safer default recommendation. Cloudways remains the right call if you're earlier-stage, comfortable with more hands-on management, and want to keep monthly hosting cost down while you validate growth.

WooCommerce Hosting Checklist Before You Sign Up

• Minimum 4 PHP workers included on the plan you're actually buying, not just the plan mentioned in marketing copy
• Persistent Redis or Memcached object caching available, with a documented eviction policy
• PHP memory limit of at least 256MB, ideally configurable higher
• Ability to raise max_execution_time for slow third-party API calls (shipping, tax, gateways)
• Hourly backups, not daily
• Free SSL, WAF, and malware scanning included
• Clear answer on how traffic spikes are handled — auto-scaling or manual, and what it costs either way
• Staging environment for testing plugin updates before they touch your live checkout

Frequently Asked Questions

How many PHP workers does a WooCommerce store need?

Most WooCommerce stores need a minimum of 4 PHP workers to handle a handful of simultaneous checkouts without queuing visitors. Stores with heavier concurrent traffic are often pushed toward 10-15 workers, and high-volume stores toward 30 or more, since each worker handles exactly one uncached request — including every cart and checkout hit — at a time.

Does page caching speed up WooCommerce checkout?

No. WooCommerce explicitly excludes cart, checkout, and my-account pages from full-page caching by design, keying off session cookies like woocommerce_items_in_cart. Checkout speed depends entirely on PHP worker availability, database query speed, and payment gateway response time — not on any caching layer.

Is Redis necessary for WooCommerce, or is it optional?

Redis is close to mandatory for any WooCommerce store beyond a handful of products, because WooCommerce writes and reads transients constantly for cart and product data. Without persistent object caching, those transients hit MySQL directly on every request; with Redis, hosting-performance comparisons report 50-80% fewer database queries on dynamic pages.

How much does slow hosting actually cost a store in lost sales?

Portent's analysis of billions of page views found ecommerce sites loading under 2 seconds convert at 3.05% versus 1.94% for sites loading in 3-4 seconds, a 57% relative difference. Separately, Google and Deloitte's "Milliseconds Make Millions" study found a 0.1-second mobile speed improvement lifted retail conversion by 8.4% and average order value by 9.2% across 30 million tracked sessions.

Is Kinsta or Cloudways better for WooCommerce?

Kinsta suits stores that want fully managed, isolated infrastructure with built-in auto-scaling and don't want to touch server settings — its $115/month Business 1 plan is the host's own recommended WooCommerce minimum. Cloudways suits technically comfortable owners who want more control over worker limits and server sizing at a lower starting cost, roughly $14-50/month depending on server size.

What PHP memory limit does WooCommerce need?

256MB is a reasonable floor for a standard WooCommerce install with a modest plugin count. Stores running subscriptions, bookings, memberships, or several marketing integrations typically need 512MB or more, since checkout with multiple active plugins is memory-intensive and a limit set too low tends to fail silently rather than throw a clear error.

Does WooCommerce hosting need to be PCI compliant?

If your store touches any part of the payment flow directly rather than fully offloading to a hosted checkout page, PCI DSS obligations apply. Look for hosts offering free auto-renewing SSL, a web application firewall, server-level malware scanning, and hourly backups, since even tokenized payment setups can expose order and customer data if the host itself is compromised.

Final Thoughts

Hosting is the one WooCommerce decision store owners tend to make once and never revisit, which is exactly backward — it's infrastructure your revenue depends on every single day, not a set-and-forget line item. The pattern that shows up again and again is owners chasing homepage PageSpeed scores while their checkout quietly queues under load because nobody checked worker count.

If you're picking new hosting or auditing what you already have, start with the two numbers that actually matter: PHP workers available at concurrent checkout, and whether Redis object caching is active and configured correctly. Everything else on a hosting comparison page is secondary to those two. For most serious WooCommerce stores, that points toward Kinsta's managed, isolated infrastructure; for earlier-stage stores comfortable with more hands-on control, Cloudways remains a genuinely solid, lower-cost alternative. Check your current worker allocation today — it takes five minutes and it's usually the answer nobody's checked.