Best Hosting for WooCommerce: What a Store Actually Needs From a Host

The best hosting for WooCommerce is whatever can serve the pages that cannot be cached. That is the whole problem in one sentence. A brochure site can be flattened into HTML and served from a cache at almost no cost, but a cart, a checkout and an account page are different for every visitor, so every one of those requests runs PHP and hits the database. A host that looks fast on a blog can fall over on a store at a tenth of the traffic.

Which is why most WooCommerce hosting comparisons are not very useful. They rank providers on the same list of features every host has had since 2015 — free certificates, daily backups, a staging button — and skip the three numbers that decide whether checkout works on your busiest day.

Table of contents

• Why WooCommerce breaks the assumptions shared hosting is priced on
• PHP workers are the number that actually decides checkout
• The database is the part that falls over first
• Caching: what you can cache and what you must not
• Cron, sessions, and the jobs nobody watches
• What to actually ask a host before you pay
• How this fits the rest of the stack
• FAQ

Why WooCommerce breaks the assumptions shared hosting is priced on

Shared hosting economics rest on an assumption: most requests never reach PHP. A page cache sits in front, the same HTML goes out to everybody, and one server can hold a great many sites because most of them are mostly idle.

WooCommerce breaks that assumption in a specific place. Once a visitor has anything in their cart, WordPress sets a session cookie, and any sane cache configuration stops serving that visitor cached pages. From that moment on, every page view is a full PHP execution with database queries behind it.

So a store has two populations of traffic that behave nothing like each other:

• Browsers who have not added anything yet. Cacheable, cheap, essentially free.
• Everyone in a session. Uncacheable, expensive, and the ones who were about to give you money.

The second group is small as a share of visitors and enormous as a share of server load. Any host evaluation that does not separate the two is measuring the wrong thing.

PHP workers are the number that actually decides checkout

A PHP worker is one process that can handle one request at a time. If your plan has four workers and each uncached request takes 600ms, you can serve roughly six or seven dynamic requests a second before requests start queueing.

When workers are exhausted, requests do not fail cleanly. They wait. The visible symptom is a checkout page that takes eleven seconds and then works fine on refresh, which is the worst possible failure because it looks like a fluke and it is actually a capacity limit.

The awkward part is that plenty of hosts do not publish this number. They publish visits per month, which is a marketing figure derived from an assumption about cache hit ratio that has nothing to do with your plugin load. If a host cannot tell you the worker count, you are being asked to buy capacity you cannot see.

What to ask for, in order:

1. How many PHP workers, or how much memory the pool gets and what the per-process limit is.
2. What happens when they are exhausted — queue, error, or scale.
3. Whether admin-ajax and the REST API share the same pool as front-end traffic. They usually do, and a badly behaved plugin polling admin-ajax can eat your checkout capacity from the inside.

The database is the part that falls over first

WooCommerce writes a great deal more than a blog does. Every order creates rows, every cart update touches session storage, and older stores keep much of that in the options and post-meta tables where it was never meant to live.

Three specific things are worth checking:

• Autoloaded options. WordPress loads every option marked autoload on every request. Plugins that store large blobs there add a fixed cost to every single page view, cached or not. A store that has been running three years and collecting plugins usually has megabytes in there.
• Transients. Without a persistent object cache, transients go in the database, so a plugin that caches aggressively is writing to your database aggressively.
• Order storage. Newer WooCommerce installs can use dedicated order tables rather than the post tables, which is a large improvement on stores with real order volume. Whether that migration has run matters more than most host features.

The hosting question underneath all of this is simple: is the database a real, separately resourced instance, or is it sharing CPU and disk with the web process on the same small box? Under load those two behave completely differently, and the second degrades in a way that is very hard to diagnose from the outside.

Caching: what you can cache and what you must not

Good WooCommerce caching is mostly a list of exclusions. Get the list wrong in one direction and the store is slow; get it wrong in the other and you show one customer another customer’s cart, which is a considerably worse day.

The pages that must never be page-cached are cart, checkout and account. The rule that enforces it is a cookie-based bypass — if the session cookie is present, skip the cache. Most decent WordPress caching layers do this by default, and most bad configurations are somebody having disabled it to improve a benchmark score.

What helps rather more than page caching:

• A persistent object cache. This is the single biggest win on a store, because it takes repeated database queries out of the request entirely, including on uncached pages, which page caching cannot help with at all.
• A CDN for static assets. Product images are usually most of the page weight, and they are perfectly cacheable even when the HTML is not.
• Fragment-level thinking. The cart count in the header is the reason many themes make every page uncacheable. Loading it separately after the page renders lets the rest of the page stay cacheable.

Cron, sessions, and the jobs nobody watches

WordPress cron is not cron. It fires when someone visits the site, which means a quiet store runs its scheduled jobs late and a busy store runs the check on requests that were trying to do something else.

On a WooCommerce site the scheduled work is not decorative. Subscription renewals, abandoned-cart emails, stock synchronisation, order status transitions and the action scheduler queue all live there. A store with a backed-up action scheduler queue can look completely healthy on the front end while quietly not sending anybody their receipt.

So the questions for a host are whether you can disable the visitor-triggered cron and drive it from a real scheduler instead, and whether you get to see that it ran. This is the least glamorous item on the list and it is the one that produces support tickets from actual customers.

Sessions are a related trap. WooCommerce keeps its own session table, and it grows. On a store with bot traffic it grows fast, and the cleanup job that trims it is, of course, a scheduled task.

What to actually ask a host before you pay

Strip the feature grid down to the things that change behaviour under load:

1. How many PHP workers, and what is the memory limit per process? Anything under 256MB will fail on some plugin combination eventually.
2. Is the database a separate instance with its own resources?
3. Is a persistent object cache available, and is it included or extra?
4. Can I run real scheduled jobs instead of visitor-triggered cron?
5. What is the backup restore procedure, and have you tested it this quarter? A backup you have never restored is a belief, not a backup.
6. What happens at the plan ceiling — throttle, queue, overage bill, or autoscale?
7. Is there a staging environment, and does it include the database? Plugin updates on a live store without one is a dare.

None of those are answered by a page that says NVMe and 99.9% uptime. Every host has NVMe now. Not every host will tell you the worker count.

How this fits the rest of the stack

Store hosting is one of the few cases where the cheapest plan is genuinely a false economy, because the failure lands precisely on the page where money changes hands. It is worth modelling the whole thing before committing — the site, the database, the storage for product images and the bandwidth are four separate line items, and the RunxBuild hosting calculator shows them individually rather than as a single monthly figure.

RunxBuild runs WordPress on its own plan ladder from $3 a month, with a file manager and a database browser in the dashboard rather than behind SFTP and phpMyAdmin, which matters more than it sounds when you are trying to check one table at eleven at night. Autoscaling between a floor and a ceiling plan covers the traffic shape stores actually have, which is quiet most of the time and not quiet on launch day. You can open the dashboard and see the plan ladder before committing to anything.

Useful related references:

• Cloud WordPress hosting, and what it changes
• Clearing the WordPress cache properly
• WooCommerce alternatives worth considering
• Managed WordPress on RunxBuild
• The WordPress database browser

FAQ

What is the best hosting for WooCommerce?

The one that can serve uncached requests fast enough for your peak, which comes down to PHP worker count, per-process memory, and whether the database has its own resources. Those three numbers predict store behaviour far better than any feature list, and they are the ones least often published.

How much memory does WooCommerce need?

Give PHP at least 256MB per process. WooCommerce itself is not especially heavy, but the combination of a page builder, a payment gateway, a shipping plugin and an analytics plugin regularly is. A 128MB limit will work fine until the day it does not, usually during an import.

Can I run WooCommerce on shared hosting?

Yes, and plenty of small stores do it happily. The limit is not order value, it is concurrency: shared plans usually give you very few PHP workers, and checkout traffic cannot be cached, so a modest burst of simultaneous shoppers is enough to start queueing requests.

Why is my WooCommerce checkout slow when the rest of the site is fast?

Because the rest of the site is cached and checkout cannot be. Every checkout request runs PHP and queries the database, so it exposes the true speed of your stack. If cached pages load in 200ms and checkout takes four seconds, that four seconds is what your infrastructure actually does.

Do I need a persistent object cache for WooCommerce?

On a store with real traffic it is the single most useful addition. Page caching cannot help on cart, checkout or account pages, and an object cache can, because it removes repeated database queries from requests that must run dynamically.