WooCommerce Hosting: Best Hosting for Fast WooCommerce Stores

Your hosting determines your speed ceiling

You can optimise every line of code, compress every image, and cache every cacheable page — but if your hosting can’t serve PHP requests fast enough, your WooCommerce store will still be slow where it matters most. Checkout pages, cart updates, account pages, and AJAX operations all bypass page caching and hit your server directly. These dynamic requests are bounded by your server’s PHP processing power, database speed, and memory.

This is the fundamental difference between hosting a WordPress blog and hosting a WooCommerce store. A blog can run fast on cheap shared hosting because 95% of requests are served from page cache. A WooCommerce store has dozens of dynamic operations that must be processed in real time — every add-to-cart, every checkout submission, every AJAX cart update, every order processing webhook. These operations define your actual store speed, and they’re entirely dependent on server resources.

The question isn’t whether to invest in proper hosting — it’s how to invest efficiently. Not every store needs a £200/month dedicated server. But every store processing real orders needs more than the £5/month shared hosting plan.

PHP workers: the resource that actually matters

PHP workers are the single most important hosting metric for WooCommerce performance. A PHP worker is a process that handles one PHP request at a time. When all workers are busy, new requests wait in a queue. On a busy WooCommerce store, that queue directly translates to customers staring at loading spinners during checkout.

Here’s the maths: your checkout page takes 800ms of server processing time. During a sale, 10 customers hit checkout simultaneously. With 4 PHP workers, 4 customers are served immediately (800ms each), 4 wait for the first batch to finish (1,600ms total), and 2 wait for the second batch (2,400ms). Those last 2 customers experience a 2.4-second server response time — not because your code is slow, but because they’re queued behind other requests.

Estimating PHP worker requirements:

• 1–2 workers: Suitable for stores with under 10 orders/day and minimal concurrent traffic. Adequate for development and staging.
• 4 workers: Handles 20–50 orders/day with moderate concurrent traffic. This is the minimum for any production store.
• 8 workers: Handles 50–200 orders/day, traffic spikes from email campaigns, and background operations (imports, exports).
• 16+ workers: High-volume stores processing 200+ orders/day, running subscription renewals, or handling heavy API traffic.

Monitor PHP worker utilisation to know when you need more. Most managed hosts provide this data in their dashboard. On self-managed servers, track the PHP-FPM status page:

# Check PHP-FPM worker status
curl -s http://localhost/php-fpm-status | grep -E 'active|idle|total'

If active processes consistently equal total processes during business hours, you’re running out of workers and need to scale up. This is the server-side equivalent of the checkout speed problems we covered earlier — insufficient workers create queueing delays that no code optimisation can fix.

Redis object caching for WooCommerce

Redis is an in-memory data store that caches database query results. WordPress and WooCommerce make hundreds of database queries per uncached page load — product data, option values, user sessions, transients, cart contents, tax rates, shipping zones. Redis caches these query results in RAM, serving them in microseconds instead of the milliseconds required for MySQL disk reads.

The impact on WooCommerce is dramatic. Checkout pages typically make 200–400 database queries per load. With Redis object caching, 40–60% of these queries are served from cache, reducing database load and page generation time by 30–50%. Cart pages, my-account pages, and admin pages see similar improvements.

Redis configuration for WooCommerce:

# wp-config.php — Redis connection settings
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_MAXTTL', 86400); // 24-hour max cache lifetime

// Optional: prefix for multi-site or shared Redis instances
define('WP_REDIS_PREFIX', 'vp_');

Install the Redis Object Cache plugin (by Till Kruss) and enable it from Settings → Redis. Verify it’s working by checking the Redis hit rate — a healthy WooCommerce store should see 85–95% cache hit rates after the cache is warm.

WooCommerce session data is particularly important to cache in Redis. By default, WooCommerce stores sessions in the wp_woocommerce_sessions database table. Under load, session reads and writes become a bottleneck because every cart and checkout interaction requires a session lookup. Moving sessions to Redis eliminates this bottleneck entirely. The Redis Object Cache plugin handles this automatically when configured correctly.

For detailed database optimisation techniques that complement Redis caching, see our WordPress database optimisation guide.

Hosting tiers for WooCommerce stores

Not every WooCommerce store needs the same hosting tier. Match your hosting investment to your store’s actual traffic and revenue.

Tier 1 — Shared hosting (£5–15/month): GoDaddy, Bluehost, SiteGround StartUp. Shared CPU and RAM with hundreds of other sites. Typically 1–2 PHP workers, no Redis, limited OPcache. Suitable only for stores with under 5 orders/day and minimal traffic. Expect checkout TTFB of 1–3 seconds.

Tier 2 — Managed WordPress hosting (£20–50/month): SiteGround GoGeek, Cloudways (1GB Vultr/DO), A2 Hosting Turbo. Dedicated resources, 2–4 PHP workers, OPcache enabled, optional Redis. Suitable for stores with 5–50 orders/day. Expect checkout TTFB of 400–800ms.

Tier 3 — WooCommerce-optimised hosting (£50–150/month): Cloudways (2–4GB), Kinsta Business, WP Engine Professional. Dedicated PHP workers (4–8), Redis included, CDN included, staging environments. Suitable for stores with 50–200 orders/day. Expect checkout TTFB of 200–500ms.

Tier 4 — High-performance hosting (£150–500/month): Cloudways (8GB+), Kinsta Enterprise, dedicated servers. 8–16+ PHP workers, dedicated Redis, autoscaling capability, multi-region CDN. Suitable for stores with 200+ orders/day or significant traffic spikes. Expect checkout TTFB under 200ms.

The transition from Tier 1 to Tier 2 has the biggest performance impact per pound spent. Moving from shared hosting to a 1GB Cloudways server typically reduces checkout load time from 3–5 seconds to 1–2 seconds — a 2–3x improvement for an extra £15/month. For a store processing even 20 orders/day, the increased conversion rate more than covers the hosting cost. For a broader comparison, see our WordPress hosting speed comparison.

Managed WooCommerce hosts compared

Cloudways offers the best price-to-performance ratio for WooCommerce. You get dedicated resources on your choice of infrastructure (DigitalOcean, Vultr, AWS, Google Cloud), full server access, Redis and Memcached included, and the ability to scale CPU and RAM independently. The tradeoff is that you manage more configuration than a fully managed host. Cloudways is our standard recommendation for stores in the £30–100/month hosting budget range.

Kinsta provides premium managed WordPress hosting on Google Cloud Platform. PHP workers are clearly allocated per plan, Redis is included at Business tier and above, and their caching layer (built on Nginx) is excellent. Kinsta’s dashboard and support are the best in the industry. The downside is price — Kinsta Business starts at £77/month and you pay per site, which adds up for agencies or multi-site businesses.

WP Engine is the largest managed WordPress host and offers WooCommerce-specific plans. Their EverCache system provides page caching, object caching, and CDN delivery. PHP worker allocation is less transparent than Kinsta’s, and some WP Engine plans restrict certain plugins. WP Engine is a solid choice for stores that need enterprise support and uptime SLAs.

All three hosts handle server configuration (PHP versions, MySQL tuning, SSL certificates) so you can focus on store optimisation rather than server administration. However, none of them optimise your WooCommerce code for you — the application-level optimisations covered in our speed checklist are still essential regardless of your hosting provider.

Server configuration for WooCommerce

Whether you manage your own server or use a managed host, certain server configurations are critical for WooCommerce performance.

PHP version: Always use the latest stable PHP version. PHP 8.2/8.3 is 15–25% faster than PHP 7.4 for WordPress workloads. WooCommerce 8.0+ supports PHP 8.2 fully. Update your PHP version — it’s free performance.

OPcache settings: OPcache caches compiled PHP bytecode so PHP doesn’t need to recompile files on every request. For WooCommerce, ensure OPcache has enough memory and file slots:

# php.ini — OPcache for WooCommerce
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.save_comments=1        # Required for some WooCommerce features
opcache.enable_file_override=1

MySQL/MariaDB tuning: WooCommerce is database-heavy. Key settings to optimise:

# my.cnf — MySQL tuning for WooCommerce
innodb_buffer_pool_size = 1G        # 50–70% of available RAM
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2  # Better performance, slight durability trade-off
query_cache_type = 0                # Disabled in MySQL 8.0+, use Redis instead
max_connections = 100
tmp_table_size = 64M
max_heap_table_size = 64M

PHP memory limit: WooCommerce recommends a minimum of 256MB. Set it in wp-config.php:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M'); // Admin operations

Handling traffic spikes and sales events

The worst time for your store to be slow is during a sale — when traffic is highest and every visitor is primed to buy. Flash sales, Black Friday, email campaigns, and social media promotions can drive 5–20x normal traffic within minutes.

Static page caching handles traffic spikes for product and category pages. Your homepage, landing pages, and product pages can be served from cache even under extreme load. The bottleneck is dynamic operations: add-to-cart, checkout, payment processing, and order creation.

Prepare for traffic spikes:

• Scale PHP workers before the event. If you normally run 4 workers, scale to 8–12 before a sale launch. On Cloudways, this means upgrading your server temporarily. On Kinsta, you can request temporary worker increases.
• Pre-warm your caches. Visit key pages (homepage, sale category, top products) to populate page cache and Redis object cache before the traffic arrives.
• Disable non-essential features. Related products, recently viewed widgets, and live chat widgets all consume server resources. During peak traffic, disable anything that isn’t directly contributing to sales.
• Monitor in real time. Watch PHP worker utilisation, database connections, and error logs during the first 30 minutes of a sale. If workers are maxed out, scale up immediately — every minute of checkout queueing costs sales.

Cloudways and AWS-based hosts offer autoscaling — automatically adding PHP workers when load increases. This is the most reliable approach for unpredictable traffic spikes, though it costs more than manual scaling. If your store’s revenue justifies it (most stores processing £50,000+/month during peaks), autoscaling pays for itself by preventing lost sales.