Choosing WooCommerce hosting that actually works
WooCommerce needs hosting that can run uncached PHP requests quickly, because cart, checkout and account pages cannot be served from a page cache. Judge a host on PHP worker count, whether Redis object caching is available, how the database is configured, and who is responsible for patching. Advertised bandwidth and disk space tell you almost nothing.
Hosting is where most WooCommerce performance problems begin and where almost none of them are diagnosed. The plan comparison tables that stores choose from measure disk space and bandwidth, neither of which has much to do with whether a checkout completes under load.
Why WooCommerce is harder to host than a website
A content site can be served almost entirely from cache. A store cannot. Cart contents, checkout, account pages and anything showing a logged-in customer’s data are generated per request, every request, because two visitors must never see each other’s basket.
That single constraint changes what good hosting means. Your homepage can be cached to within an inch of its life and it will not help the customer waiting on a checkout page. A store’s real capacity is its uncached request capacity, and that is what the plan comparison table never shows.
The four things worth asking about
Four questions separate hosting that will hold from hosting that will not. None of them appear on a pricing page.
| Question | Why it decides the outcome | Bad answer |
|---|---|---|
| How many PHP workers, and what happens at the limit? | Each uncached request holds a worker; exhaustion queues customers | “Unlimited” |
| Is Redis object caching available? | Removes repeated database queries within a page load | “We have caching” without specifics |
| How is the database configured and where does it run? | Query latency dominates uncached response time | Shared database host, no detail |
| Who applies security patches, and how quickly? | Decides whether an unpatched service is your problem or theirs | Silence |
Ask all four in one email. The quality of the reply tells you more than the specification does — a host that answers precisely has thought about stores, and a host that answers in adjectives has not.
PHP workers, and why “unlimited” is not an answer
A PHP worker handles one request at a time. A checkout that takes two seconds of server work occupies a worker for two seconds. Ten simultaneous checkouts on eight workers means two customers wait for a worker before their request starts.
Bandwidth is irrelevant to this and disk space is irrelevant to it. What matters is the arithmetic of workers against your slowest uncached request, which is why the useful question is not how many workers you get but what happens when they run out. Queuing is survivable. Errors at the checkout are not.
Reducing the time each request takes is usually cheaper than buying more workers, which is what the next two sections are about.
Object caching is the single biggest lever
WooCommerce asks the database a great many questions to render a page — product data, variations, prices, tax rules, cart contents, session state. Without object caching, the same query runs repeatedly within one page load.
Redis holds those results in memory for the duration, and enabling it is the largest single improvement available on most stores we audit. It is not a tuning detail; it is the difference between a store that feels quick and one that does not, on identical hardware.
Two things to check rather than assume: that Redis is actually connected rather than merely installed, and that it survives a deployment. We have found stores paying for object caching that had been silently disconnected for months.
The database is the part nobody looks at
Uncached response time is mostly database time. Three things matter and all three are invisible from the outside.
Where the database runs. On the same machine, latency is negligible. On a shared database host in another rack, every query pays a network round trip, hundreds of times per page.
Whether the tables are indexed for what WooCommerce actually asks. WordPress’s post-meta structure makes product queries expensive by nature; on large catalogues the indexes matter enormously, and on small ones they matter not at all.
How big the tables have got. Sessions, transients, order metadata and abandoned carts accumulate. A store that has never been cleaned down is answering every query against a table full of data from 2023.
Who patches what
Managed hosting and unmanaged hosting differ on one question that has nothing to do with performance: when a vulnerability is announced in PHP, the database, or the web server, who applies the fix?
On managed hosting, the host does, usually before you have read the announcement. On a VPS, you do, and if nobody has been given that job then nobody is doing it. Running your own supported PHP version is not optional — an unsupported one stops receiving security fixes entirely, and stores run on them for years without noticing.
This is the part of the decision that is not about money. A store on unmanaged hosting with no named administrator is carrying a risk it has not priced.
Staging is a hosting feature
WooCommerce updates need testing against real data, because the failures are rarely in the plugin and usually in the interaction between the plugin, your theme and your catalogue.
A staging environment that mirrors production — same PHP version, same database contents, same plugin set — turns an update from an act of faith into a fifteen-minute check. Hosting that offers one-click staging is worth more than hosting that offers more disk space, and it is the feature most often traded away to save a few pounds a month.
What we specify on client projects
Our default requirements, stated so a client can compare quotes on equal terms:
- A supported PHP version, currently maintained rather than merely working
- Redis object caching, connected and monitored
- A database on the same machine or the same private network
- Automated daily backups held off the server, with a tested restore
- One-click staging that copies production data
- Patching handled by the host, with a stated response time
- HTTP/2 or HTTP/3, TLS, and a CDN for static assets
That list is deliberately unglamorous. None of it is a feature anybody boasts about, and all of it is what separates a store that stays up during a campaign from one that does not.
How to test a host before you commit
Two checks, both cheap.
Measure an uncached response. Load a cart or account page — never the homepage — and look at time to first byte. That number is the hosting, stripped of caching and images.
Ask what happens under load. Not “can you handle traffic”, which invites a yes, but “what happens when PHP workers are exhausted”. A host that describes queueing behaviour has thought about it. A host that says it will not happen has not.
Migrating without breaking things
Moving hosts is routine and the failures are predictable: DNS moved before the data finished copying, a database dumped while orders were still arriving, or a staging URL left in the database so live pages point at a hostname that no longer exists.
The safe sequence is to copy, verify, freeze orders briefly, re-sync, then move DNS with a short TTL set a day in advance. Store migrations differ from site migrations in one respect that matters more than any other: an order placed during the move must not be lost, which is why the freeze exists even though it is inconvenient.
