WooCommerce Hosting: The Guide to a Fast Online Store

Good WooCommerce hosting gets three things right: an up-to-date stack (PHP 8.3 or later, MySQL 8.0 or a recent MariaDB, HTTPS), a cache smart enough to tell the catalogue, which can be cached, from the cart and checkout, which never should be, and enough CPU and memory for the pages that can’t be cached. Add frequent backups and responsive support, because every minute of downtime costs sales.

Guide updated on 20 October 2026. Technical requirements are those published by WooCommerce and WordPress.org on that date.

What makes WooCommerce hosting fast?

Fast WooCommerce hosting serves public pages almost instantly from cache, while keeping enough power to build personal pages in real time: cart, checkout, customer account and search. What shoppers experience depends on both halves, not just on how quickly your home page loads.

A brochure site can run almost entirely from cache: once a page is generated, the server hands the same copy to everyone. A store can’t. As soon as someone adds a product to their cart, WordPress has to know who they are and recalculate totals, shipping, taxes and coupons before saving the order. Every one of those clicks runs PHP and queries the database.

That is why two stores with the same traffic can have very different needs. One whose visitors mostly browse stays light; one whose customers check out all day long works the server much harder. When you size your hosting, look at carts and orders, not just visits.

What server setup does WooCommerce require in 2026?

WooCommerce publishes its official server requirements: for version 10.8 and later it recommends WordPress 6.9+, PHP 8.3+, MySQL 8.0+ or MariaDB 10.6+, HTTPS support and a WordPress memory limit of 256 MB or more.

WordPress.org lists its own recommended requirements for core. Older PHP and MySQL versions may still run, but WooCommerce describes them as end-of-life: no more security fixes, which is not a risk worth taking on a site that handles orders and customer data.

You can check your store’s actual setup under WooCommerce > Status > System status, which lists PHP and database versions, the memory limit and your active plugins. It is also the first thing any support team will ask you for.

Why does a store work the server harder than a blog?

Because part of a store is personal. A page cache can only serve pages that look the same for everyone, and the cart, checkout and account pages are different for each visitor. They are generated on every request, and they happen to be the pages that turn visitors into customers.

The WooCommerce developer documentation is explicit: cart, checkout and My Account must stay out of the cache, and cookies such as woocommerce_items_in_cart, woocommerce_cart_hash and wp_woocommerce_session_ signal an active cart. A cache that ignores those cookies can show one customer’s cart to another, the worst failure a store can have.

Shared, VPS or dedicated: which hosting fits which store?

To launch a store or run a modest catalogue, WordPress-optimised shared hosting with a server-level cache is enough in most cases. A VPS or dedicated server makes sense when you need large guaranteed resources, custom server tuning, or have someone who can administer it.

The sensible approach is to start on a plan you can upgrade without migrating, then watch two signals: how fast the cart responds and how much of your account’s resources you use. At Hosterwise, you can move to a higher plan from your customer area at any time, prorated over the current period. Our guide to the best WordPress hosting covers the criteria that really matter, and LiteSpeed vs Nginx vs Apache explains why the web server makes a difference for dynamic pages.

How do you cache a store without breaking the cart?

Use a single caching plugin, ideally the one that drives your server’s own cache, check that cart, checkout and account pages are excluded, then enable the WooCommerce-specific options: purge product pages when stock changes and handle the mini cart privately.

On a LiteSpeed server, the free LiteSpeed Cache plugin does most of the work. According to the official LSCache for WordPress documentation, the My Account, Checkout and Cart pages are excluded from caching by default. Here is what to check:

1. Confirm your WooCommerce pages under WooCommerce > Settings > Advanced. If the cart, checkout or account page is assigned incorrectly, it may end up cached.
2. Set the product update interval under LiteSpeed Cache > Cache > WooCommerce. By default, a product is purged when its quantity or stock status changes, and categories only when stock status changes.
3. Turn on ESI (Edge Side Includes) under LiteSpeed Cache > Cache > ESI if your theme shows a mini cart in the header: the page stays cached and only the cart block is built per visitor. ESI needs LiteSpeed Enterprise, the edition Hosterwise runs, or the QUIC.cloud CDN; OpenLiteSpeed does not offer it.
4. Try “Vary for Mini Cart” if the mini cart shows the wrong content: it keeps a separate cached copy when the mini cart isn’t empty.
5. Disable any other page-caching plugin. Two stacked caches behave unpredictably.
6. Turn on the object cache under LiteSpeed Cache > Cache > Object if your host provides Redis or Memcached: it keeps the results of repeated database queries in memory and lightens the pages the page cache cannot serve (cart, checkout, admin). At Hosterwise, Redis is available on every plan: choose Redis as the method, enter the host and port shown in your customer area or provided by support, save, then check that the connection test shows Redis as connected.

Each tab is covered in our LiteSpeed Cache setup guide. To confirm a page is served from cache, look at its response headers:

# Product page: should return "x-litespeed-cache: hit" from the second visit
curl -sI https://www.example.com/product/my-product/ | grep -i x-litespeed-cache

# Cart: should never return "hit"
curl -sI https://www.example.com/cart/ | grep -i -E "x-litespeed-cache|cache-control"

Which WooCommerce settings lighten the database?

Enable High-Performance Order Storage (HPOS), run scheduled tasks from a real cron job instead of visitor traffic, and clear out expired sessions and transients regularly. Together they cut database load, especially in the admin.

High-Performance Order Storage (HPOS)

WooCommerce used to store orders in WordPress’s generic tables (wp_posts and wp_postmeta), shared with posts and pages. HPOS moves orders into dedicated tables. The official documentation says it has been on by default for new installs since WooCommerce 8.2 (October 2023), with fewer read and write operations on less crowded tables.

On an older store, check its status under WooCommerce > Settings > Advanced > Features. Take a full backup before switching and make sure your extensions are marked as compatible: WooCommerce shows this on the same screen.

Scheduled tasks and Action Scheduler

WooCommerce hands a lot of work to Action Scheduler: emails, subscription renewals, syncs and clean-up. By default these tasks are triggered by visits (WP-Cron), so they lag on quiet nights and add work to busy days. The Action Scheduler documentation recommends WP-CLI over WP-Cron for large sites, which assumes SSH access. Hosterwise does not offer SSH access, a deliberate security choice: create the cron job in CyberPanel’s Cron Jobs menu with the first command below and, to clear a backlog of actions in one go, ask our 24/7 support team, who will run the WP-CLI command for you.

// wp-config.php: stop running WP-Cron on every visit
define( 'DISABLE_WP_CRON', true );

# Server cron job (for example from CyberPanel), every 5 minutes
*/5 * * * * wget -q -O - "https://www.example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

# If your host gives you SSH access and WP-CLI: process the Action Scheduler queue
wp action-scheduler run --batches=0

Then keep an eye on Tools > Site Health and WooCommerce > Status > Scheduled Actions. A long list of pending or failed actions is often the first sign of a store slowing down.

Payments and security: what should your host guarantee?

Your host should provide a valid SSL certificate across the whole site, maintained PHP and database versions, frequent automatic backups you can actually restore, and file monitoring. Card data, on the other hand, should never touch your server: leave it to your payment provider.

With modern payment integrations, the card form is supplied by the provider (Stripe, PayPal and so on) and card numbers go straight to them. Stripe’s integration security guide explains that these low-risk integrations reduce your PCI DSS obligations, and that payment pages should use TLS 1.2 or later. You are still responsible for your site’s security: a hacked WordPress install can inject code into the checkout page.

A minimum security checklist for a store:

• HTTPS everywhere, no mixed content, automatic redirect from HTTP.
• Daily backups of files and database, with at least one copy off the server.
• Prompt updates to WordPress, WooCommerce and payment extensions.
• Few admin accounts, unique passwords and two-factor authentication.
• Regular malware scans and alerts on suspicious file changes.
• A staging copy to test major updates before they reach production.

How can you test WooCommerce hosting before committing?

Measure the pages that can’t be cached: add a product to the cart, then time the cart and checkout pages. Compare with your current host on the same pages, and use a money-back period to run these tests on your real store.

1. Copy your store to the new host (a free migration makes this easy) without changing your domain yet.
2. Measure server response time (TTFB) on a cached product page, then on the cart with an item in it. The first shows how good the cache is; the second shows the real power available.
3. Place a test order from start to finish using your payment gateway’s test mode.
4. Use the admin: the order list, reports, editing a product. A sluggish admin often means a lack of resources.
5. Check Core Web Vitals on product pages with PageSpeed Insights; our Core Web Vitals guide explains how to read the results.

# Server response time (TTFB) in seconds
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://www.example.com/product/my-product/

If cached pages are fast but the cart is slow, look at resources and plugins: test them one at a time on a copy before changing plans.

Hosting your WooCommerce store with Hosterwise

Every Hosterwise plan runs on LiteSpeed Enterprise servers with WooCommerce-aware LSCache, ESI for the mini cart, a Redis object cache, HTTP/3, the QUIC.cloud CDN, free SSL certificates, daily backups stored off the server that hosts your sites, daily malware scans and 24/7 support. Resources are dedicated to each site, so every store has its own RAM, CPU and concurrent PHP connection limits.

For a first store, we recommend Premium, with 3 GB of RAM, 3 CPU, 40 concurrent PHP connections and 25 GB of NVMe storage per site, from €13.99 per month excl. VAT. Once orders come in regularly or your catalogue grows, move up to Boost: it is our best-resourced plan, with 4 GB of RAM, 4 CPU, 80 concurrent PHP connections and 40 GB of NVMe storage per site, plus priority support, from €24.99 per month excl. VAT. These starting prices are for a 48-month term, renewal is at the same price as your first payment for the period you chose, and Premium and Boost include a free domain name for the first year on a 12-month term or longer. Details are on our WooCommerce hosting page, and every term is on the pricing page.

Already selling elsewhere? Our technicians will move your store for you with a free migration, following the approach in our guide to migrating a WordPress site without downtime. The 30-day money-back guarantee on your first hosting order gives you time to run your own measurements.