WooCommerce Performance Tuning for High-Traffic Stores

A content site can hide almost any inefficiency behind full-page caching. A store cannot: carts, checkouts, stock levels and logged-in customers all bypass the page cache, which means WooCommerce performance is really PHP and MySQL performance under concurrency. That changes where the tuning effort should go, and it is why advice written for blogs so often disappoints when applied to a busy shop.

Measure before you touch anything

Install Query Monitor on staging and look at the slowest real pages: a product page, the cart, and checkout. On stores with performance complaints we almost always find one of three culprits: an expensive query from a plugin running on every page, a bloated autoloaded options set, or an external HTTP call sitting in the request path. Fixing the top offender usually does more than every generic optimisation combined, so identify it before spending money on hardware. Repeat the measurement after every change you make; without a before-and-after number, tuning is indistinguishable from ritual.

Cache aggressively, exclude precisely

Page caching still matters, because most sessions start on the home page, category pages and product pages, and all of those are cacheable for guests. The discipline is in the exclusions: cart, checkout, account pages, and anything rendered per-customer must bypass the cache. The other classic drag is cart fragments, the ajax call WooCommerce uses to refresh the mini-cart, which fires on pages that have nothing to do with shopping. Dequeue it where no cart is displayed.

add_action( 'wp_enqueue_scripts', function () {
    if ( is_front_page() || is_singular( 'post' ) ) {
        wp_dequeue_script( 'wc-cart-fragments' );
    }
}, 20 );

A persistent object cache backed by Redis is not optional at scale. It is the layer that serves the uncacheable pages, keeping repeated queries for products, sessions and settings out of MySQL while checkout traffic spikes.

Product imagery is the other heavyweight. Serve it from a CDN, generate the sizes your templates actually use, and let the browser lazy-load below-the-fold grids. None of that touches PHP, which is exactly why it is worth doing early: every request the CDN absorbs is one your workers never see.

The database is usually the real bottleneck

• Move to High-Performance Order Storage: dedicated order tables query far better than orders stored as posts and meta.
• Audit autoloaded options; years of installed-then-removed plugins leave megabytes loading on every single request.
• Prune expired sessions and transients on a schedule rather than letting the tables grow without bound.
• Watch product attribute and variation counts; layered navigation across tens of thousands of variations needs a search backend, not more meta queries.

Search deserves its own mention. Default WordPress search runs broad pattern-matching queries across post content, which collapses under a large catalogue; handing search and filtered navigation to Elasticsearch or a hosted equivalent both speeds the feature up and removes a whole class of expensive queries from MySQL at exactly the busiest moments.

Concurrency: PHP workers and the checkout path

When a sale lands, the store's real capacity is the number of PHP workers times how fast each request completes. If a checkout takes two seconds of PHP time and you have ten workers, you can complete five checkouts a second and no more; everything beyond that queues. That gives you two levers: make requests faster, which is everything above, and add workers, which is a hosting conversation. Move email sending and webhook delivery to background jobs so the customer is never waiting on your transactional email provider mid-checkout. And load-test the full checkout path with realistic carts before peak season arrives, not during it.

Tune in that order: measure, fix the worst query, cache correctly, sort the database, then scale workers. Stores that follow the sequence usually find they need less hardware than they feared.

Running a store that slows down when it matters most? Performance work on WooCommerce is one of the things STRCLI does week in, week out.