PerformanceRetail

Improving WooCommerce Store Performance

WooCommerce is slow for reasons a brochure site is not. Here is the diagnosis order that fits.

This is an implementation example, not a client case study. It describes how this work is actually carried out — the method, the sequence and the reasoning. No client is named and no result is claimed, because inventing either would make it worthless as evidence.

WooCommerce performance diagnosis from images through to hosting

Standard WordPress speed advice tells you to install a caching plugin. On WooCommerce that fixes the catalogue and does nothing for the cart, the checkout or the account pages — which are the ones where slowness costs money directly.

Project type
Performance work on an existing WooCommerce store
Sector
Retail

The challenge

Stores accumulate weight: product images uploaded at camera resolution, plugins for reviews and wishlists and currency switching, and a database that grows with every order and every session. The pages that cannot be cached are the ones under the most load.

The objective

Faster catalogue browsing and, more importantly, a checkout that stays responsive under load — because that is where slowness converts directly into lost orders.

Approach

Diagnose in order of typical impact rather than working through a generic list. On a store that order is: images, then uncacheable page load, then plugin weight, then database, then hosting.

Implementation

1. Images

Almost always the largest single win on a store, because product photography arrives at full camera resolution and nobody resizes it.

  • Serve at rendered size, with correct srcset for the grid and the product page
  • Modern formats with a fallback
  • Explicit dimensions so the grid does not reflow as images arrive
  • Lazy-load below the fold, never the main product image

2. The pages that cannot be cached

Cart, checkout and my-account are per-user. Page caching cannot touch them, so the work is different:

  • Object caching so repeated database queries are not repeated
  • Reduce the queries themselves — plugins that hook into cart calculation are expensive on every request
  • Cut AJAX cart fragments, which fire on every page load in many themes and are a frequent cause of a slow-feeling site
  • Make sure the cart is not being loaded on pages that have no cart

3. Plugin audit

Stores collect plugins faster than any other kind of WordPress site. For each one: what does it do, where is it used, and does it load everywhere or only where needed?

A currency switcher loading its scripts on the checkout is a cost with no benefit.

4. Database

Orders, sessions, transients and abandoned carts all accumulate. Expired transients and stale sessions are worth clearing on a schedule. Large stores need index review.

5. Hosting

At some point the site is simply bigger than its plan. Uncacheable pages mean PHP and MySQL do real work on every request, and shared hosting is not built for that.

Measuring it properly

Test the actual journey, not just the homepage:

  • Category page
  • Product page
  • Cart
  • Checkout

Test under something resembling real conditions, and use field data from Search Console rather than only lab scores.

Technology

  • WooCommerce
  • Redis / object cache
  • CDN
  • WebP / AVIF
  • Query Monitor

Decisions worth explaining

Object caching prioritised over more aggressive page caching

Page caching cannot touch the pages that matter most on a store. Object caching reduces the work those pages do on every request.

AJAX cart fragments disabled where the theme did not need them

They fire on every page load and are a common cause of a store that feels sluggish even when measured speed looks acceptable.

Performance measured on the full purchase journey

A fast homepage and a slow checkout is the worst possible combination, and homepage-only testing hides it completely.

What it produces

A store where the catalogue is cached and light, the uncacheable pages do less work per request, and the purchase journey has been measured end to end rather than at the homepage. No percentage improvements are quoted, because improvement depends entirely on the starting state.

What it teaches

  • Caching plugins do not help the pages where store slowness costs the most.
  • Product images are the default largest problem and the default last thing checked.
  • Cart fragments are a frequent, invisible tax on every page load.
  • A homepage-only speed test will tell you a store is fine when its checkout is not.

Related services

Related guides

Worked examples

All case studies