WooCommerce Server Playbook

What is the Server Playbook?

The WooCommerce Server Playbook is our reference guide for configuring production servers that run WooCommerce stores at scale. It covers PHP workers, database tuning, object caching, CDN architecture, and server sizing based on real traffic patterns.

Most WooCommerce performance problems are not code problems. They are infrastructure problems. A well-built theme on a misconfigured server will still be slow. This playbook fixes the foundation.

PHP-FPM Workers

Worker configuration is the single most impactful server-side setting for WooCommerce. Too few workers and requests queue up during traffic spikes. Too many and the server runs out of memory.

Calculating Worker Count - Each PHP-FPM worker consumes 30-80MB of memory depending on your plugins. The formula is simple: (Available Memory - System Overhead) / Memory Per Worker = Max Workers. A 4GB server with 512MB reserved for the OS and MySQL can safely run 40-50 workers.

Process Manager - Use pm = dynamic for most stores. Set pm.max_children to your calculated max, pm.start_servers to 25% of max, and pm.min_spare_servers / pm.max_spare_servers to maintain a ready pool without wasting idle memory.

OPcache - Enable OPcache with opcache.memory_consumption=256 and opcache.max_accelerated_files=20000. This caches compiled PHP bytecode so workers do not recompile WordPress on every request. Validate timestamps in production should be off, with cache clearing handled by your deployment pipeline.

Redis and Object Cache Pro

WordPress makes hundreds of database queries per uncached page load. Object caching stores these query results in memory so they are served instantly on subsequent requests.

Why Redis over Memcached - Redis supports data structures (sorted sets, hashes) that map naturally to WordPress transients and options. It also supports persistence, so your cache survives server restarts.

Object Cache Pro - The free Redis Object Cache plugin works, but Object Cache Pro is worth every dollar for production stores. It adds connection pooling, async flushing, per-key analytics, and a Relay integration that keeps cache data in PHP’s shared memory for near-zero latency.

Configuration Essentials:

• Set maxmemory to 256-512MB depending on store size
• Use allkeys-lru eviction policy so stale keys are automatically pruned
• Enable save "" (disable RDB persistence) if your store can tolerate cold cache after restarts
• Configure Object Cache Pro’s prefetch setting to warm frequently accessed keys

Database Optimization

WooCommerce is database-heavy. Orders, products, variations, and metadata all live in MySQL/MariaDB and are queried on nearly every page.

InnoDB Buffer Pool - Set innodb_buffer_pool_size to 50-70% of available RAM on dedicated database servers. This is the single most important MySQL setting. The entire working dataset should fit in memory.

Query Cache - Disable it. MySQL’s built-in query cache is deprecated and causes lock contention under concurrent writes. Object Cache Pro handles result caching far more effectively at the application layer.

Slow Query Log - Enable it with long_query_time=1. Review weekly. WooCommerce’s wp_postmeta joins are the usual suspects. The fix is almost always adding a proper index or switching to WooCommerce’s HPOS (High-Performance Order Storage).

HPOS Migration - If you are still on the legacy wp_posts order storage, migrate to HPOS. It moves orders into dedicated tables with proper indexes, reducing query complexity and eliminating the worst wp_postmeta bottlenecks.

Server Sizing by Traffic

Up to 50K monthly visitors - A 2-core, 4GB VPS handles this comfortably with proper caching. Run Nginx, PHP-FPM, MySQL, and Redis on a single server. Full-page caching (Nginx FastCGI Cache or a plugin like FlyingPress) makes most requests bypass PHP entirely.

50K to 250K monthly visitors - Move to a 4-core, 8GB server or split the database onto its own instance. At this level, add a CDN (Cloudflare or Bunny) for static assets and consider full-page edge caching for logged-out visitors.

250K to 500K monthly visitors - Separate application and database servers. 8GB+ for the app server, 8GB+ for MySQL with a large InnoDB buffer pool. Redis on the app server. Full-page cache is mandatory. Monitor PHP-FPM worker saturation and scale horizontally if workers are consistently maxed.

500K to 1M+ monthly visitors - Horizontal scaling with multiple application servers behind a load balancer. Centralized Redis instance. Read replicas for the database if query load demands it. At this scale, you should also evaluate whether WooCommerce is the right tool, or if a headless architecture with the WooCommerce REST API makes more sense.

Full-Page Caching

For logged-out visitors (the vast majority of traffic), the entire HTML page should be served from cache without touching PHP or MySQL.

Nginx FastCGI Cache - The fastest option. Nginx serves cached HTML directly from disk. Cache bypass rules handle logged-in users, cart contents, and checkout pages. Typical response times: 5-15ms.

CDN Edge Caching - Cloudflare APO or a similar edge cache stores your pages on global points of presence. Response times drop to single-digit milliseconds worldwide. Pair with proper cache-busting headers so product and price updates propagate quickly.

What to Exclude - Never cache the cart, checkout, or my-account pages. Use Cache-Control: no-store headers for any page that displays user-specific content.

Monitoring

A fast server today can be a slow server tomorrow. Monitor these metrics continuously:

• PHP-FPM active processes vs max children (saturation warning at 80%)
• MySQL slow queries per hour (should trend toward zero)
• Redis hit rate (should be 95%+ after warmup)
• TTFB at the origin (target under 200ms for uncached, under 20ms for cached)
• Disk I/O wait (the silent killer on cheap VPS hosts)

Set alerts on worker saturation and TTFB regression. By the time your customers notice, you have already lost sales.