Most shared hosting plans will technically "run" WooCommerce. The install completes, the storefront loads, and everything looks fine — until you get 40 concurrent shoppers on a product page during a flash sale and your site returns a 502 for the next 20 minutes.
That gap between "runs WooCommerce" and "runs WooCommerce well" is what this article is about. I've migrated enough stores off under-powered hosts to know the failure modes by heart. The good news: the WooCommerce hosting performance requirements aren't mysterious. They're measurable, and once you know what to measure, you can make a defensible hosting decision instead of guessing.
Let's go through every layer — PHP, database, memory, caching, storage I/O — with the actual numbers I use when scoping infrastructure for a new store.
Why WooCommerce Is Harder on Servers Than a Blog
A typical WordPress blog serves mostly cached HTML. A WooCommerce store can't do that for logged-in users — cart state, session data, and stock levels have to be live. That means more uncached PHP execution, more database queries per request, and more write operations (order inserts, stock decrements, session updates).
A product page on a mid-size store can fire 60–120 database queries. A checkout page is worse: it often hits 150+ queries, runs payment gateway API calls, and writes to multiple tables in a single transaction. If your host is running MySQL on the same shared disk as 300 other sites, every one of those writes is contending for I/O.
The performance budget for a checkout page is also less forgiving than a blog post. Research from Baymard Institute consistently shows cart abandonment spikes when checkout takes more than 3 seconds to respond. You don't get the "they'll just wait" grace period that a blog reader might give you.
PHP Version and Memory: The Baseline You Can't Ignore
As of mid-2025, WooCommerce 9.x requires PHP 7.4 minimum, but that's a floor, not a target. PHP 8.2 or 8.3 is where you actually want to be — the OPcache improvements and JIT compilation in PHP 8.x translate directly to faster request execution. In my own benchmarks on a 500-product store, switching from PHP 7.4 to PHP 8.2 dropped average page generation time by roughly 18% with zero code changes.
Memory is the other non-negotiable. WooCommerce's own documentation suggests 256 MB as a minimum memory_limit, but I've seen stores with a dozen active extensions blow past that easily. My personal baseline for any store I'd put into production is 512 MB. If you're running a marketplace plugin, a subscription engine, or a complex shipping calculator on top of WooCommerce, budget for 768 MB.
Check what your host actually allocates — not what they advertise. Add this to a temporary info.php file and check the memory_limit row:
<?php phpinfo(); ?>
Then delete it immediately. You'd be surprised how many "optimized for WordPress" hosts still cap PHP memory at 128 MB.
php.ini Settings Worth Auditing
Beyond memory, three ini values matter for WooCommerce specifically:
max_execution_time: Set to at least300. Bulk order exports and background sync jobs will time out on the default30.upload_max_filesizeandpost_max_size: Both should be64Mor higher if you're importing product CSVs.opcache.memory_consumption: Should be at least128(MB). On a busy store, OPcache thrashing kills performance faster than almost anything else.
Database Performance: MySQL Configuration and Storage Engine
WooCommerce is MySQL-heavy. The wp_posts, wp_postmeta, wp_woocommerce_sessions, and wp_options tables will grow fast, and query performance against them degrades if the database server isn't tuned.
The two MySQL variables I check first on any new host:
innodb_buffer_pool_size: This should be set to 70–80% of available RAM on a dedicated database server, or at least256Mon a shared environment. The default128Mon many shared hosts is too small for a store with 1,000+ orders.query_cache_size: On MySQL 8.0+ this is deprecated and removed. If your host is still on MySQL 5.7 with query cache enabled, that's a red flag — not because the cache is bad, but because 5.7 is approaching end-of-life and a host still running it probably isn't keeping other things current either.
For storage engine, every WooCommerce table should use InnoDB. MyISAM doesn't support row-level locking, which means concurrent checkouts can deadlock. If you're inheriting a store that was set up years ago, run this query to check:
SELECT table_name, engine
FROM information_schema.tables
WHERE table_schema = 'your_db_name'
AND engine != 'InnoDB';
Anything that comes back needs to be converted before you scale traffic.
Caching Architecture: What WooCommerce Actually Needs
Full-page caching is complicated for WooCommerce because of cart fragments. The default WooCommerce cart widget fires an AJAX request (wc-ajax=get_refreshed_fragments) on every page load to keep the cart count current. On a cached page, this is the one dynamic call — but if it's slow, it blocks the perceived load time even though the HTML itself is cached.
The caching stack I'd recommend for a serious store:
Object cache (Redis or Memcached): This is the highest-leverage addition you can make. WordPress's default object cache is non-persistent — it resets on every request. A persistent object cache via Redis means WooCommerce can cache database query results across requests. On a store processing 200+ orders/day, this alone can cut database load by 30–50%. Look for hosts that include Redis in the plan, not as a $20/month add-on.
Full-page cache with cart exclusions: Tools like WP Rocket, LiteSpeed Cache (if your host runs LiteSpeed), or the host's built-in page cache all need to be configured to exclude cart, checkout, my-account, and any page with the [woocommerce_*] shortcode. Caching a checkout page is how you serve stale nonces and break orders.
CDN for static assets: Product images, JS, and CSS should be served from a CDN edge node, not your origin server. This is table stakes in 2025. Cloudflare's free tier handles this adequately for most stores; if you're doing high-volume image-heavy catalogs, a proper CDN with image optimization (Cloudflare Images, Bunny.net) is worth the cost.
CPU and Concurrency: The Number Hosts Don't Advertise
This is where shared hosting falls apart under real WooCommerce load. Shared hosts sell "unlimited" plans but throttle CPU at the process level — typically to 1–2 CPU cores worth of time, shared across all your sites on that account.
For a store that sees traffic spikes, you need to know two things:
-
How many PHP workers does your plan include? A PHP worker handles one request at a time. If you have 4 workers and 10 concurrent visitors hit uncached pages, 6 of them are queuing. On WP Engine's Starter plan (as of early 2025), you get 2 PHP workers — fine for a low-traffic store, a bottleneck for anything doing real volume. Their Growth plan bumps to 4. Know what you're buying.
-
Is CPU throttled? VPS and cloud plans (DigitalOcean Droplets, Cloudways, Kinsta's infrastructure) give you dedicated vCPUs. Shared and entry-level managed plans often don't. Ask directly, or run a CPU-bound benchmark like Geekbench Server and compare against the raw spec.
For a store doing under 5,000 sessions/month, shared managed hosting with 2–4 PHP workers is usually fine. Above 20,000 sessions/month, I'd want at minimum a VPS with 2 dedicated vCPUs, 4 GB RAM, and a separate database server or a managed host's mid-tier plan.
Storage I/O: The Silent Killer on Budget Hosts
NVMe SSD storage is the baseline expectation now, but not every host delivers it even when they claim to. The difference between NVMe and a spinning HDD — or even a SATA SSD on an overloaded SAN — is significant for WooCommerce because of the write-heavy workload.
You can get a rough I/O benchmark by running this from SSH:
dd if=/dev/zero of=/tmp/testfile bs=1M count=512 oflag=direct
A healthy NVMe-backed server should sustain 500+ MB/s. If you're seeing 80–120 MB/s, you're on SATA SSD at best, possibly shared SAN storage. That matters when WooCommerce is writing session data, logging, and updating stock on every order.
Also check where uploads are stored. Some cloud hosts use network-attached storage for the wp-content/uploads directory — latency for large product image reads adds up. Local NVMe for uploads is preferable; if you're on a host that uses NFS-mounted storage for uploads, compensate with aggressive CDN offloading.
Putting It Together: Minimum Viable Spec for a WooCommerce Store
| Tier | Monthly Sessions | PHP Workers | RAM | Database | Storage |
|---|---|---|---|---|---|
| Small store | < 5,000 | 2–4 | 2 GB | Shared MySQL (same server) | SATA SSD |
| Growing store | 5,000–25,000 | 4–8 | 4 GB | Dedicated MySQL or managed DB | NVMe SSD |
| Established store | 25,000–100,000 | 8+ | 8 GB+ | Separate DB server, Redis | NVMe SSD + CDN |
| High-volume | 100,000+ | Horizontal scaling | 16 GB+ | Managed DB cluster | NVMe + full CDN offload |
These are the WooCommerce hosting performance requirements I'd stake my own stores on. They're not conservative — they're what I've seen stores actually need in production, not what a marketing page says is "recommended."
Conclusion: What to Do Tomorrow
WooCommerce hosting performance requirements come down to a short checklist: PHP 8.2+, 512 MB memory minimum, Redis object cache, NVMe storage, and enough PHP workers for your peak concurrent traffic. Everything else is optimization on top of that foundation.
If you're on a host and you're not sure whether it meets these requirements, spend 30 minutes running the audits in this article before your next traffic spike forces the question. Check your PHP memory limit, run the I/O test, ask your host directly how many PHP workers your plan includes.
If the answers come back unsatisfactory, that's useful data. It means you're one busy weekend away from a 502 storm — and now you know it before it happens instead of after.
Ready to compare specific hosts against these benchmarks? Check out our managed WordPress hosting comparison to see how the major players stack up on the metrics that actually matter for stores.