# WooCommerce hosting: choose a host by measured speed, not reviews

> Good WooCommerce hosting is the plan that builds your cart, checkout and account pages fast without a cache. How to test that before you pay, and what else a store needs from a host.

Updated 2026-09-26 · WordPress & WooCommerce · HTML version: https://getreport.app/guides/woocommerce-hosting

Good WooCommerce hosting is the plan that builds your cart, checkout and account pages quickly without any cache, because those pages differ for every shopper and cannot be cached. Any host can serve a cached product page fast; what separates them is uncached Time to First Byte, PHP capacity under load, an object cache and a database with room to grow. This guide is for store owners choosing or leaving a host. It is part of the [WooCommerce store checklist](https://getreport.app/guides/woocommerce-store-checklist), which covers the rest of a fast store. At the end you will have a short list of requirements, a test you can run on a trial plan, and a table to decide with.

There is no single best WooCommerce hosting. Rankings test empty demo sites and often earn a commission. Your own store is the only benchmark that counts, and you can run it in an afternoon.

## Quick answer

- **Test uncached pages.** Time the first byte of `/cart/` and `/my-account/` on each candidate host. Google's web.dev guidance rates TTFB good at 0.8 s or less at the 75th percentile of real visitors; aim well under that from a nearby location.
- **Meet the official minimums.** WooCommerce recommends PHP 8.3 or newer, MySQL 8.0+ or MariaDB 10.6+, HTTPS and a WordPress memory limit of 256 MB or more.
- **Ask for an object cache** (Redis or Memcached) and enough PHP workers for the shoppers you get at your busiest hour.
- **Run WP-Cron from a real server cron**, so orders, emails and stock updates in the Action Scheduler run on time.
- **Require staging and backups you can restore**, with restores that do not wipe orders placed since the backup.
- **Keep card data off your server** with a payment gateway that uses hosted fields or a hosted payment page. That shrinks your PCI scope; it does not remove it.

## Why WooCommerce hosting is different from WordPress hosting

A blog can live almost entirely in a page cache. A store cannot: the cart, checkout and my-account pages are built by PHP and the database on every request, and most cache setups also skip the cache on every page once a shopper has something in the basket. [Keeping cart, checkout and account pages out of the cache](https://getreport.app/guides/woocommerce-caching-cart-checkout-and-account-pages) explains why that is right and how to set it up.

So the pages where people pay are the pages the host builds from scratch. The [cart-fragments request](https://getreport.app/guides/woocommerce-cart-fragments-the-ajax-call-on-every-page) can add an uncached PHP call to every page view, and orders, emails and webhooks run as background jobs.

The general method for comparing hosts is in [choosing a WordPress host by measured TTFB](https://getreport.app/guides/choosing-a-wordpress-host-by-measured-ttfb); this guide adds what a store needs on top.

## What a WooCommerce host must offer

### Current PHP, database and memory

WooCommerce's own server recommendations (woocommerce.com, "Server recommendations", for current 10.x releases) ask for:

| Requirement | WooCommerce recommends | WordPress recommends |
| --- | --- | --- |
| PHP | 8.3 or greater | 8.3 or greater |
| Database | MySQL 8.0+ or MariaDB 10.6+ | MySQL 8.0+ or MariaDB 10.11+ |
| HTTPS | Supported | Supported |
| WordPress memory limit | 256 MB or greater | Not stated |
| Web server | Apache or nginx | Not stated |

WordPress's requirements page (wordpress.org/about/requirements) sets the higher MariaDB bar, so pick MariaDB 10.11 or newer to satisfy both. Older PHP and MySQL versions may still run WooCommerce, but they are no longer supported, and PHP versions past end of life get no security fixes. Ask which versions the control panel offers.

### PHP workers for uncached requests

Every uncached request, such as a cart view, a checkout update or a product search, holds one PHP process until it is done. Hosts limit how many run at once, and call them PHP workers, PHP-FPM processes or entry processes. When all are busy, shoppers queue, and at the limit get a 503 or 508 error.

For a store, the worker count matters more than disk space. Ask how many the plan allows and whether you can add more during a sale.

### An object cache

A persistent object cache keeps the results of repeated database queries in memory, in Redis or Memcached, so uncached pages ask the database less. WordPress uses it through an `object-cache.php` drop-in in `wp-content`, usually installed by the host or a plugin. It helps most on exactly the pages a store cannot page-cache: cart, checkout, account, search and the admin.

Ask whether it is included, private to your site, and how much memory it gets.

### A database with room to grow

Orders, customers, sessions and the Action Scheduler all live in the database. High-Performance Order Storage (HPOS), the default for new stores since WooCommerce 8.2, keeps orders in their own tables, which makes order searches and reports cheaper. It does not make the database smaller: a store with years of orders still needs memory for the database server and fast disks. On shared plans, ask about database size limits and whether the database runs on the same machine as PHP.

### WP-Cron from a real cron job

WooCommerce runs its background work through the Action Scheduler (Tools → Scheduled Actions): order emails, stock updates, webhooks, subscription renewals. By default WordPress triggers these jobs from WP-Cron, which runs only when someone visits the site. On a quiet store, jobs run late; on a busy one, the checks add work to visitor requests.

The fix is a real server cron that calls `wp-cron.php` every minute or few, with `define( 'DISABLE_WP_CRON', true );` in `wp-config.php`. A host must let you create that cron job, or run one for you. [wp-cron and scheduled tasks](https://getreport.app/guides/wp-cron-and-scheduled-tasks) shows the exact lines.

### Staging, backups and restores that keep orders

Updates need a staging copy first, and a restore must not throw away today's orders. Ask whether staging can push files and settings back to live without overwriting the database, and how often backups run. A nightly backup restored at 5 pm loses every order placed since midnight unless you export them first. [Staging with WordPress plugins and host tools](https://getreport.app/guides/staging-with-wordpress-plugins-and-host-tools) and [backups that actually restore](https://getreport.app/guides/backups-that-actually-restore) cover both.

### Resource limits on shared plans

Shared plans cap CPU time, memory, concurrent processes and often the number of files (inodes), and a store's uncached pages hit those caps long before a blog does. Read the plan's fair-use section and ask what happens when you exceed them: throttling, error pages or a forced upgrade. [Server response time on shared hosting](https://getreport.app/guides/server-response-time-on-shared-hosting) shows what hitting those limits looks like from the outside.

### Location and a CDN

Distance adds delay to every uncached request, which a CDN cannot serve from its edge. Host near most of your shoppers, and use a CDN for images, scripts and cached pages. The CDN must not cache the cart, checkout, account pages, `/wp-json/wc/store/` or `?wc-ajax=` requests; [CDN basics](https://getreport.app/guides/cdn-basics-what-it-fixes-and-what-it-does-not) explains what it can and cannot fix.

### Payments and PCI scope

Any store that takes cards has obligations under PCI DSS, but how much of them lands on your hosting depends on the payment gateway. If card numbers are typed into the gateway's own fields (an iframe or hosted fields) or on a hosted payment page, they go straight to the payment provider and never touch your server. That is what can keep a store in the shortest self-assessment questionnaire, SAQ A.

It does not take your site out of scope. Since the PCI Security Standards Council's SAQ A update in 2025, merchants that embed a payment form must confirm their site is protected against malicious scripts, because a script injected into the checkout can still read what shoppers type. So the host must keep the server patched, and you must control what loads on the checkout. A host's "PCI compliant" label covers its own infrastructure, not your site; ask your payment provider which questionnaire applies to you.

### Support that knows WooCommerce

When the checkout fails during a sale, you need support that knows cache exclusions and PHP worker limits. Before you buy, ask two concrete questions: "Do you cache `/cart/` or skip it for the `woocommerce_items_in_cart` cookie?" and "How many PHP workers does this plan have?" How fast and how precisely they answer tells you more than a review.

## How to test WooCommerce hosting before you pay

### 1. Measure your current host first

> **Free tool:** [TTFB test: check your time to first byte](https://getreport.app/tools/ttfb-test): Free TTFB test: measure time to first byte from Frankfurt, in a Lighthouse run and from real Chrome users, plus the redirects before the page. No sign-up.

Run the [TTFB test](https://getreport.app/tools/ttfb-test) on three addresses of your live store: a product page (usually cached), `/cart/` and `/my-account/`. The cart and account pages are not cached, so their first byte is the server building the page. With an empty basket the checkout either redirects to the cart or shows an empty-cart notice, so an anonymous test does not time the real checkout; the cart is the closest stand-in. The test measures from Frankfurt, adds Lighthouse's server response time and, where Google has enough traffic, the real-user TTFB from the Chrome UX Report.

> **Check: Time to First Byte.** TTFB is how long the server takes to start answering. Everything else waits for it, so a slow first byte makes every other metric worse. Google's 800 ms target is for real visitors, network included; Lighthouse flags the server's own share above 600 ms (see server response time).
>
> 1. Add page caching (WordPress: WP Rocket, LiteSpeed Cache, or your host's cache; Shopify does this for you).
> 2. Put a CDN in front (Cloudflare, Bunny) so the first byte comes from a nearby edge.
> 3. Check database-heavy plugins and slow hosting; a plan with more CPU often fixes this outright.

> **Check: Server response time.** Lighthouse flags a first byte slower than 600 ms. Caching and hosting fix this for most CMS sites.
>
> 1. Enable full-page caching (WordPress: WP Rocket, LiteSpeed Cache, WP Super Cache; or your host's server cache).
> 2. Use a CDN and keep database queries out of the request path.

> **Check: Real-user Time to First Byte.** How long real visitors wait for the server's first byte, including their network. Google's threshold for "good" is 800 ms.
>
> 1. Cache pages and use a CDN close to your visitors; see the TTFB finding above.

### 2. See how your host does for other sites

> **Free tool:** [Web hosting speed test: is your host slow?](https://getreport.app/tools/hosting-speed-check): Free web hosting speed test: see who hosts a site, how fast its server sends the first byte, and how that compares with other sites on the same host.

The [hosting speed check](https://getreport.app/tools/hosting-speed-check) names the network and managed host behind the server. Once getReport has checked 50 sites on the same host, it shows your first byte next to the anonymous median and slowest quarter of all of them. When most sites on your host answer faster than yours, the host is not the limit: your plugins, caching or plan are. Behind a CDN the origin host is hidden, and no comparison is shown.

> **Check: Speed against other sites on your host.** Comparing your server with other sites on the same host shows where a slow first byte comes from. When most sites on the host answer faster, the host is not the limit; slow plugins, missing page caching or an undersized plan usually are. The numbers are anonymous, from sites we checked, and appear only once a host has 50 sites.
>
> 1. Turn on full-page caching first; it removes most of the server's work for repeat visits.
> 2. Profile the slowest plugins or database queries (Query Monitor on WordPress) and remove or replace them.
> 3. If the site is already cached and lean, ask the host for a larger plan or move to a faster one.

> **Check: A CDN is in front of the site.** A CDN serves your files from a location near each visitor and absorbs traffic spikes. Without one, visitors far from your server wait longer for every file.
>
> 1. Put the site behind a CDN such as Cloudflare, Bunny or Fastly; the free tiers cover most small sites.
> 2. At minimum, serve images and static files from a CDN hostname.

### 3. Put a copy of your store on each candidate

An empty install is fast anywhere, so test a copy of your real store. Move it to each candidate during the trial or money-back period, on the temporary domain the host gives you, and turn off real payments and order emails on the copies.

On each copy, time the same pages at the same hour, three runs each: a product page, a category page, `/cart/` and `/my-account/`. Then add a product to the basket in a browser and time a few more pages, because a shopper with a full basket skips the page cache.

### 4. Check the store setup on the new host

> **Free tool:** [WooCommerce SEO and speed checker](https://getreport.app/tools/woocommerce-checker): Free WooCommerce SEO and speed check: product schema with price and stock, out-of-stock pages left indexable, cart fragments and a cached cart or checkout.

Run the [WooCommerce checker](https://getreport.app/tools/woocommerce-checker) on a product page of each copy. It fetches `/cart/` and `/checkout/` once as an anonymous visitor and reads the response headers for a cache hit, so it catches a host cache that serves the cart to everyone. It does not measure load or PHP workers; run a load test only with the host's permission.

> **Check: Cart and checkout bypass the page cache.** A cached /cart/ or /checkout/ shows one visitor another visitor's basket, breaks nonces and payment forms, and produces the "session expired" errors shoppers abandon on. Every caching plugin excludes these pages by default; a CDN or host cache in front of them often does not.
>
> 1. Exclude /cart/, /checkout/ and /my-account/ (and their translations) from every cache layer: the caching plugin, the host's page cache and the CDN (Cloudflare: a Cache Rule with "Bypass cache" for those paths and for requests with a woocommerce_* cookie).
> 2. Re-test after purging: the responses should carry cache-control: no-store or a cache status of BYPASS/MISS.

### 5. Fill in one table

| Host / plan | Data centre | Product TTFB | Cart TTFB | Account TTFB | PHP | Object cache | PHP workers | Real cron | Staging | Price / month |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Current | | | | | | | | | | |
| Candidate A | | | | | | | | | | |
| Candidate B | | | | | | | | | | |

Pick the plan with the lowest uncached times that meets every requirement, and keep the report links as evidence.

## Common mistakes

- **Choosing by the cached home page.** Every host serves a cached page fast. Judge on `/cart/` and `/my-account/`.
- **Leaving WP-Cron on page visits.** On a quiet night, order emails and stock updates wait for the next visitor.
- **Moving hosts to fix a slow site.** If the [hosting speed check](https://getreport.app/tools/hosting-speed-check) shows your site slower than most on the same host, fix caching and plugins first. [What a slow server looks like](https://getreport.app/guides/ttfb-what-a-slow-server-looks-like) helps you tell the two apart.

## Questions people ask

### What is the best WooCommerce hosting?

There is no single best host; the best one is the plan that serves your own store's uncached pages fastest near your shoppers. Rankings test empty demo sites, and many earn a commission. Put a copy of your store on two or three candidates during their trial, time `/cart/` and `/my-account/` three times each, and check PHP 8.3+, an object cache, enough PHP workers, real cron, staging and backups. Then choose on those numbers.

### Do I need special hosting for WooCommerce?

No, any host that meets WooCommerce's recommendations can run it: PHP 8.3 or newer, MySQL 8.0+ or MariaDB 10.6+, HTTPS and a 256 MB memory limit. What a store needs beyond a blog is capacity for uncached pages: enough PHP workers, an object cache and a database with room for orders. Plans sold as "WooCommerce hosting" may add these, but test them rather than trusting the label.

### Is shared hosting enough for a WooCommerce store?

For a small store with a few orders a day, often yes, if the uncached cart and account pages answer well under 0.8 s. Shared plans cap CPU, memory and concurrent PHP processes, so they struggle during sales or with large catalogues. Watch for 503 or 508 errors at busy times and a first byte that is fine at night and slow at noon. Those point to the plan's limits.

### How much PHP memory does WooCommerce need?

WooCommerce recommends a WordPress memory limit of 256 MB or more. You set it with `define( 'WP_MEMORY_LIMIT', '256M' );` in `wp-config.php`, but it cannot exceed the PHP `memory_limit` the host allows, so check the PHP value in the host's panel and the result under WooCommerce → Status. Heavy extensions, imports or large reports may need more.

### Does WooCommerce need Redis?

It does not require it, but a persistent object cache such as Redis or Memcached is one of the most useful things a WooCommerce host can offer. It keeps repeated database query results in memory, which speeds up the cart, checkout, account pages and admin that a page cache cannot serve. Ask whether it is included and private to your site.

### Does my web host have to be PCI compliant for WooCommerce?

Not if card data never reaches your server. With a gateway that uses hosted fields, an iframe or a hosted payment page, card numbers go straight to the payment provider, which can keep a store in the short SAQ A questionnaire. Your site still has to be protected against malicious scripts on the checkout, so keep the server patched and ask your payment provider which questionnaire applies.

### What TTFB should a WooCommerce cart page have?

Aim for well under 0.8 s, the limit Google's web.dev guidance rates good at the 75th percentile of real visitors. The cart is built by PHP on every request, so it will be slower than a cached product page. If it takes well over a second from a nearby location, the host, the PHP version, a missing object cache or a heavy extension is the bottleneck.