WooCommerce Hosting: What Your Store Actually Needs

Quick answer: WooCommerce hosting needs enough PHP workers, memory, and database capacity to handle concurrent shoppers at checkout, not just storage and bandwidth. Match your plan to peak orders per hour and choose a host that excludes cart, checkout, and account pages from page cache.

Key takeaways

• Generic shared hosting often fails at the cart because of PHP worker limits, memory exhaustion, and database connection caps, not disk space.
• PHP workers, PHP memory limit, MySQL version, and object cache matter more than “unlimited” storage or visits.
• Size your plan from peak concurrent shoppers, not monthly order totals; a single worker serves only a few requests per second.
• Budget for renewal pricing and migration costs, not just the intro rate; the three-year cost often doubles.

Why cheap shared hosting breaks at the cart and checkout

Cheap shared hosting is built for low-traffic blogs, not stores with concurrent shoppers. The limits that matter only appear when several people add items and proceed to checkout at the same time. That is when you see the first symptoms: slow cart updates, failed payments, and error pages that only happen during promotions.

The first bottleneck is PHP worker limits. Each PHP worker handles one request at a time. Shared plans often cap concurrent workers at a low number per account. When all workers are busy, new requests queue or fail, and the shopper sees a spinning cart or a 508 error. The symptom is intermittent slowness that disappears when traffic drops.

The second is memory exhaustion. WooCommerce, its extensions, and the active theme can push a single request past the default PHP memory limit. When that happens, the request dies with a blank page or a 500 error. The symptom is a fatal error in the logs and a cart that empties or a checkout that never completes.

The third is database connection caps. Shared hosts limit simultaneous MySQL connections per account. Under load, WooCommerce sessions and queries compete for connections, and new requests are refused. The symptom is “Error establishing a database connection” during traffic spikes, even though the database is fine.

These failures are not random. They follow traffic. A store that works all week can fail during a newsletter send or a flash sale. If you see those patterns, the plan is undersized for WooCommerce, not broken.

The specs that actually matter for WooCommerce

Ignore storage and “unlimited visits” when comparing plans. Focus on the resources that WooCommerce consumes on every page load and every cart update. The numbers below are the ones that change behavior under load.

PHP version and memory limit. Run a current PHP version and set the memory limit to at least 256 MB, preferably 512 MB if you use many extensions. A low memory limit is the most common cause of white-screen checkout failures. Check the limit in the host’s panel, not just in WordPress.

PHP workers. This is the number of concurrent PHP processes your plan allows. It is often hidden in shared plans. Ask support for the worker count and whether it is per site or per account. For WooCommerce, workers are the real ceiling on concurrent shoppers.

CPU and RAM. Shared plans pool CPU and RAM, so a noisy neighbor can slow your store. Look for plans with dedicated or guaranteed CPU shares. If the host cannot tell you the CPU limit, assume it is low.

MySQL version and connections. Use MySQL 8 or MariaDB 10.4 or newer. Ask how many simultaneous database connections your account gets. A low cap causes connection errors during checkout.

NVMe disk. NVMe storage speeds up database reads and file access. It is a real improvement over older SATA SSDs, but it will not fix a worker shortage.

Object cache. A persistent object cache such as Redis reduces database load for cart and session data. It is optional for small stores but valuable as order volume grows.

Marketing numbers like “unlimited bandwidth” or “free domain” are noise for WooCommerce. They do not address concurrency, memory, or database limits. If you are comparing plan types, see types of web hosting to understand what each tier really includes.

The PHP worker math: sizing from orders per hour

One PHP worker can handle roughly one request at a time. A typical WooCommerce page might take 200–500 ms of PHP time. That means a single worker can serve about two to five requests per second, but only if each request is short. Cart and checkout requests are heavier and hold the worker longer.

Estimate peak concurrent shoppers, not monthly orders. If you expect 20 orders in an hour during a promotion, and roughly one in ten visitors buys, that is about 200 visitors in that hour. If they arrive evenly, that is about 3–4 per minute, which is easy. But traffic rarely arrives evenly. A newsletter send can bring 50 visitors in a minute. At 300 ms per request, that is 15 seconds of PHP work per second, which needs multiple workers.

A practical rule: assume each concurrent shopper needs one worker during cart and checkout. If you expect 10 people to be in the cart or checkout at the same moment, you need at least 10 workers, plus headroom for catalog pages. Most small stores are fine with 10–20 workers. Stores running ads or flash sales should ask for 20–30.

Do the math from your own numbers. Take your busiest hour of orders, multiply by ten to estimate visitors, then divide by 60 to get visitors per minute. Multiply by the average request time in seconds to get the PHP seconds per second, which is roughly the worker count you need. Add 50% headroom. If the host cannot give you worker counts, that is a warning sign.

Shared vs managed WooCommerce vs VPS vs cloud

Shared hosting is cheap and easy, but it pools resources and hides worker limits. It fits stores under 50 orders a month with low concurrency. It fails when traffic spikes or when extensions push memory. If you start here, choose a host that publishes renewal pricing and has a real upgrade path, such as the small-business plans at Namecheap.

Managed WooCommerce hosting is tuned for stores: worker counts are higher, caching rules exclude cart and checkout, and support understands WooCommerce. It fits stores doing 50–500 orders a month that want fewer knobs. The trade-off is cost and less control over the stack. For a provider shortlist, see managed WordPress hosting.

A VPS gives you dedicated CPU, RAM, and worker capacity at a predictable price. You manage the server or pay for management. It fits stores that have outgrown shared plans but do not want cloud complexity. The risk is that a misconfigured VPS can be slower than good shared hosting.

Cloud hosting scales resources on demand and offers managed options. It fits stores with unpredictable spikes or high order volumes. It can be cost-effective at scale but expensive if left unmanaged. A managed cloud plan is a common next step; see this Cloudways review for one option.

Tier	Fits	What you control	Main risk
Shared	Under 50 orders a month, low concurrency	Very little; limits are pooled and often unpublished	Worker and memory caps appear exactly during a promotion
Managed WooCommerce	50–500 orders a month, no server admin wanted	Caching rules and plugin stack, within the host policy	Higher price and less control; some hosts restrict migrations
VPS	Stores that outgrew shared and want predictable CPU and workers	Everything: PHP version, workers, database, cache	A misconfigured server can be slower than good shared hosting
Managed cloud	Unpredictable spikes or high order volume	Application and cache; the provider runs the infrastructure	Cost scales with resources and rises quietly if left untuned

No single tier is best. Match the tier to your peak concurrency and your willingness to manage a server. If you are unsure, start with a plan that has clear worker counts and an easy upgrade path.

Caching a store correctly

Page caching is essential for catalog pages, category pages, and blog posts. It reduces PHP and database load, which frees workers for checkout. But caching must exclude cart, checkout, and my-account pages. Those pages contain session-specific data and must never be served from a shared cache.

Most caching plugins and host-level caches have WooCommerce-specific exclusion rules. Turn them on. If you cache the cart page, shoppers see other people’s carts or empty carts. That is the session bug that empties carts: a cached page serves a stale session cookie or nonce, and WooCommerce resets the cart.

Object caching is different. A persistent object cache such as Redis stores database query results and session data in memory. It reduces database load and speeds up cart and checkout queries. It does not replace page caching, and it does not fix a worker shortage. Use it when your database is the bottleneck.

Test caching after any change. Add an item to the cart, go to checkout, and refresh. Then open the site in a private window and confirm the cart is empty. If the cart persists across sessions, caching is misconfigured.

For a broader look at how server speed affects conversion, see conversion rate strategies that depend on fast checkout.

CDN, image optimisation and Core Web Vitals on product pages

A CDN serves static assets from locations near the shopper. It reduces latency for images, CSS, and JavaScript, and it offloads bandwidth from your server. It helps product pages load faster for distant visitors. It does not fix PHP worker limits, database connection caps, or slow checkout queries.

Image optimisation reduces file size without visible quality loss. Product images are often the heaviest assets on a store. Compressing them and serving modern formats improves Largest Contentful Paint, a Core Web Vitals metric. It does not make checkout faster.

Core Web Vitals on product pages are mostly about images, layout shift, and render-blocking scripts. Fix those with a CDN, image compression, and lazy loading below the fold. Do not lazy-load the main product image, or you hurt the metric you are trying to improve.

What CDNs and image optimisation cannot fix: a slow database, too few PHP workers, or a caching rule that breaks the cart. Those are hosting problems. If your product pages are fast but checkout is slow, look at the server and the cart caching rules.

The non-negotiables checklist

Before you launch or migrate, confirm these items. They are not optional for a store that takes payments.

• SSL certificate included and forced on all pages, including checkout.
• Automated daily backups with a tested restore, not just a backup button.
• Staging environment that can be refreshed from live and pushed back safely.
• PCI-aware payment pages: use hosted fields or a provider that keeps card data off your server.
• Email deliverability: transactional email sent through a provider, with SPF and DKIM set.
• Staging-to-live workflow for plugin and theme updates, tested on a copy of the store.
• Clear upgrade path to more PHP workers without migrating to a new host.

If a host cannot meet these, it is not a WooCommerce host, regardless of its marketing. For small-business hosting that covers the basics without overpaying, see choosing small-business hosting.

Renewal pricing and the real three-year cost

Intro prices are not the cost of hosting. The renewal price is. Many hosts double or triple the price after the first term. Check the renewal rate before you buy, and note whether it applies to the plan or to add-ons like backups and SSL.

Watch for overage fees. Some plans charge for visitors, bandwidth, or PHP worker overages. A traffic spike can produce a bill that costs more than the plan. Ask what happens when you exceed the limit: throttling, extra charges, or a forced upgrade.

Bandwidth and visitor caps are usually not the binding limit for WooCommerce, but they can be. A product image-heavy store can burn bandwidth quickly. Check the cap and the overage rate.

Finally, the cost of leaving. Migration can take hours, and some hosts charge for it or make it hard. If the plan does not fit later, you want a clean export and a host that helps you move. Factor that into the three-year cost.

Compare plans on renewal price plus expected add-ons, not the first invoice. A slightly higher renewal with clear limits is often cheaper than a low intro price with overages.

Decision path by store size and what to monitor

Under 50 orders a month: a shared plan with at least 10 PHP workers, 256 MB PHP memory, and cart exclusions in the cache. Keep extensions light. Monitor checkout errors and page load time weekly. If you need a domain, register it cheaply and keep DNS in one place with Dynadot.

50–500 orders a month: managed WooCommerce hosting or a well-managed VPS with 20+ workers, Redis object cache, and staging. Monitor worker saturation, database connections, and cart errors during promotions. This is where cheap shared plans start to fail.

500+ orders a month: dedicated resources or managed cloud with autoscaling, 30+ workers, and a CDN. Monitor checkout latency and error rates in real time. At this level, a single slow query can cost orders.

In the first month after launch, watch four things: PHP worker usage at peak, database connection errors, cart abandonment rate, and checkout page load time. Set alerts for 500 errors and for checkout latency above two seconds. If you see repeated failures during traffic, upgrade workers before changing anything else.

If you are naming a new store, a short brandable domain helps repeat visits; you can buy one through Atom. The domain does not affect hosting performance, but it affects how easily customers return.

Frequently asked questions

How many PHP workers do I need for WooCommerce?

Most small stores do fine with 10–20 workers. Stores running ads or flash sales should ask for 20–30. Size from peak concurrent shoppers in the cart and checkout, not monthly orders. If the host will not disclose worker counts, assume they are low.

Can I run WooCommerce on cheap shared hosting?

Yes, if your order volume is low and traffic is predictable. It breaks when several shoppers hit checkout at once or when extensions push memory. Choose a shared plan with published memory limits and an easy upgrade path, and test the cart under load before you rely on it.

Why does my cart empty when I enable caching?

The cart, checkout, and my-account pages are being cached. Those pages contain session-specific data and must be excluded from page cache. Enable WooCommerce-specific exclusion rules in your cache plugin or host panel, then test in a private window.

Do I need a CDN for a WooCommerce store?

A CDN helps product pages load faster for distant visitors and reduces bandwidth use. It does not fix PHP worker limits or slow database queries. Use one if you have international customers or image-heavy pages, but fix hosting limits first.

What should I monitor after moving to a new host?

Watch PHP worker usage at peak, database connection errors, checkout latency, and cart abandonment. Set alerts for 500 errors and for checkout taking longer than two seconds. Compare the first month against your old host before you cancel the old plan.

What to do next

Write down your peak orders per hour and the number of shoppers you expect in the cart at once. Ask three hosts for their PHP worker count, PHP memory limit, MySQL connection cap, and renewal price. Test the cart and checkout on a staging copy before you commit. If a host cannot answer those questions, move on. Choose the plan that fits your peak, not your average, and keep an upgrade path open.

Disclosure: some links in this article are affiliate links. If you buy through them we may earn a commission at no extra cost to you.