Speed Up WooCommerce: What Really Counts in a Shop

A WooCommerce shop isn’t a normal WordPress blog – which is exactly why many generic performance tips fall short. Shops have dynamic, user-specific areas that can’t simply be cached statically. If you know where WooCommerce typically slows down, you optimise in a targeted way instead of with a watering can. This post shows the shop-specific bottlenecks, how to fix them – and in what order.

Why a Shop Is Different from a Blog

With a blog, you can pre-build almost every page once and serve it as finished HTML. A shop can’t: cart, checkout and “My account” look different for every visitor and change in real time. These dynamic areas are exactly why a simple page cache isn’t enough in a shop – and why WooCommerce needs its own optimisations.

The WooCommerce-Specific Bottlenecks

1. Cart Fragments (AJAX Cart)

WooCommerce reloads the cart status via AJAX on every page request – even on pages that show no cart at all. Each of these calls bypasses the page cache and hits the server directly. On high-traffic shops, that adds up to noticeable load.

The solution isn’t to kill the script outright (then the cart counter stops updating), but to load it only where a cart is visible:

// In the child theme's functions.php or a small plugin
add_action( 'wp_enqueue_scripts', function () {
    // Keep it active on cart, checkout and account
    if ( is_cart() || is_checkout() || is_account_page() ) {
        return;
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}, 99 );

On pure content pages – blog, about, contact – nobody needs the live cart. Disabling it there saves one server request per view.

2. Uncacheable Pages

Cart, checkout and “My account” differ per user and must not be statically cached – otherwise customer B sees customer A’s cart. A good cache deliberately excludes these pages. To keep them fast anyway, the object cache steps in (more on that shortly).

3. Query Load from Products and Filters

Large catalogues with attributes, variations and filters generate heavy database queries. A layered-nav filter that re-searches the entire catalogue on every click makes even fast servers sweat. A clean object cache, lean filter solutions, and avoiding plugins that query the entire catalogue on every page all help here.

Object Cache: The Biggest Lever for Shops

The object cache is the ingredient that makes the biggest difference in a shop – and the one that’s often missing on cheap hosting. It stores the results of database queries in memory (via Redis or Memcached), so WooCommerce doesn’t send the same query to the database on every request. Especially on the dynamic pages that no page cache catches, it’s the most noticeable accelerator.

In practice that means: install Redis on the server (or choose hosting that ships it), activate the matching plugin and connect it in wp-config.php. Many good managed WordPress hosts deliver Redis pre-configured – a criterion worth watching when choosing a host. We’ve covered how page and object cache work together in set up caching properly.

The Basics That Apply Here Too

• Server caching for all non-dynamic pages (home, categories, product pages without personalised content).
• Images in WebP or AVIF, correctly sized – product images are often the biggest LCP drivers in a shop.
• A tidy database – shops accumulate especially many transients and orphaned metadata → optimise the database.
• A lean plugin selection – every shop plugin that loads on the front end costs INP.

Hosting: The Foundation Decides

No optimisation trick saves a shop on hosting that’s too weak. WooCommerce needs more than a blog: enough memory (PHP memory_limit realistically 256 MB or more), a current PHP version, object-cache support, and a database that responds under load too. Cheap shared hosting shared among ten neighbours is the wrong place to save money in commerce – a slow checkout costs more than the better hosting does in a year.

An Order for Optimising

1. Measure the field data – especially INP, because shops are interactive and slip here most easily.
2. Disable cart fragments where no cart is needed.
3. Set up the object cache for cart, checkout and account.
4. Server caching for static shop pages.
5. Tackle product images and the database.
6. Measure again after each change – don’t rebuild everything at once.

The goal is the same Core Web Vitals as for any WordPress site – just with respect for the dynamic shop areas.

---

Your shop is slow but you don’t want to risk cart and checkout? Drop us a line – we’ll speed up WooCommerce in a targeted way, without disrupting the purchase flow.