Fix the Server Bottlenecks Slowing Your WooCommerce Store

PHP-FPM runs a pool of worker processes, and each one handles a single request at a time. When all your workers are busy, new requests queue, and to a shopper that looks like a store that has simply stopped responding. Set the worker count too low and you choke under load. Set it too high and the workers exhaust your RAM and the server starts swapping, which is slower still.

We size the pool to your actual server resources and WooCommerce's per-request memory footprint, which is heavier than plain WordPress. That means setting a sensible max_children, choosing the right process manager mode, tuning request timeouts so a slow third-party API call does not tie up a worker indefinitely, and setting memory limits that leave headroom for MySQL and Redis rather than starving them.

The result is a store that degrades gracefully under a traffic spike instead of hitting a wall and returning 502 errors at the worst possible moment.

By default, WooCommerce leans hard on the wp_options table for transients and stores a lot of session and cart data in the database. Under load that turns into a flood of repetitive queries, many of them writing to autoloaded options, and the database becomes the bottleneck for the whole site.

We install and configure Redis as a persistent object cache so that transients, session data, product lookups and expensive query results are served from memory instead of round-tripping to disk. WooCommerce session handling in particular benefits, because carts and logged-in state stop thrashing the database on every page view. We set a sensible maxmemory and eviction policy so Redis stays within bounds rather than growing unchecked.

This pairs closely with front-end work. If you also need the application layer and asset delivery tuned, our WordPress speed optimisation service covers that side, and the two together usually deliver more than either alone.

WooCommerce is database-heavy, and the default MySQL or MariaDB configuration on most hosts is a generic one that assumes nothing about your workload. The single most important setting is usually the InnoDB buffer pool, which holds your working data set in memory. If it is too small, the database reads from disk constantly, and no amount of PHP tuning will hide that.

We size the buffer pool to your data and available RAM, tune connection limits so concurrent shoppers do not exhaust available connections, adjust InnoDB flush and log settings for a good balance of durability and speed, and enable slow query logging so we can see exactly which queries are hurting. Often a handful of poorly indexed queries, from WooCommerce itself or a reporting plugin, are responsible for most of the pain.

Where the underlying host simply cannot give the database the resources it needs, we will say so plainly rather than tune around a hardware ceiling.

Caching is where most well-meaning WooCommerce setups go wrong. Aggressive full-page caching makes the homepage fly, then serves one shopper another shopper's cart, or caches the checkout page and breaks payment entirely. The problem is not caching, it is caching the wrong pages.

We configure exclusion rules so cart, checkout, my-account and any other personalised pages are always served fresh, while product and category pages, which are the same for everyone, are cached as hard as possible. We also make sure WooCommerce cart fragments and the cookies that signal a non-empty cart are respected, so the mini-cart updates correctly without disabling caching site-wide.

Done properly, you get the speed of a fully cached catalogue and a checkout that behaves correctly every single time. If your store runs on an OpenLiteSpeed stack, our OpenLiteSpeed WordPress setup work covers LSCache configuration in the same detail.

Product images, CSS and JavaScript make up most of the bytes on a WooCommerce page, and serving them from your origin server on every request wastes resources that should be handling carts and checkout. We put a CDN in front of your static assets so they are served from an edge network close to the visitor, which cuts origin load and speeds up page loads for shoppers across the UK and abroad.

Just as important, we benchmark before we touch anything. We record server response times and full page load times at the start, then again after each change, so the improvement is a measured number rather than a claim. You see exactly what PHP-FPM tuning bought you, what Redis bought you, and what the CDN bought you.

If the real problem turns out to be the host itself, we will tell you before spending your budget tuning around it. Our guidance on a WordPress site that is slow on shared hosting covers when a move genuinely is the right call, and a migration to DigitalOcean is often where that ends up.