WooCommerce performance optimisation: what actually works

Standard WordPress performance advice, install a caching plugin, compress images, use a CDN, is a reasonable starting point for a brochure site. On a WooCommerce store, it is only part of the picture. WooCommerce introduces a category of problems that static caching does not solve.

Caching works differently on WooCommerce

A standard caching plugin serves a saved copy of a page to every visitor. That works well for blog posts and static pages. It does not work the same way for cart pages, account pages or the checkout. These pages are personalised per session and must be generated dynamically on each request.

The practical consequence is that caching rules for WooCommerce need to exclude certain pages and URL patterns. Many caching plugins have WooCommerce-specific modes that handle this. Using a generic caching configuration on a WooCommerce store can serve cached cart data to the wrong user, which is both a performance and a correctness problem.

Fragment caching, where only the static parts of a page are cached and the dynamic parts are generated per request, is a more accurate approach for stores. This is available on managed hosting platforms that support it natively, or through specific plugin configurations.

Database queries are often the real bottleneck

WooCommerce generates a significant number of database queries, particularly on product catalogue pages. Stores with large product catalogues, many product attributes or complex variable products can generate dozens of queries per page. On an unoptimised database, this adds up quickly.

• The wp_options table grows large over time with transients, plugin data and session information. Clearing it regularly improves query performance.

• Post revisions accumulate in the wp_posts table. Limiting or clearing these reduces table size.

• Object caching stores the results of database queries in memory rather than running the same query again. On managed hosting platforms like WP Engine, Kinsta and Cloudways, this is typically available through Redis or Memcached. It has a measurable effect on query-heavy pages.

Plugin count has a direct effect on performance

Every active plugin adds code that runs on every page load. On a WooCommerce store, this compounds with the overhead that WooCommerce itself adds. A store with 60 plugins, several of which are doing similar things, is adding significant processing time before any content is even rendered.

Reducing plugin count on a store requires knowing what each plugin does and whether it is genuinely needed. Some plugins installed years ago are no longer used. Others duplicate functionality that WooCommerce now handles natively. Removing them reduces page load time and reduces the number of things that can conflict or break during an update.

Hosting makes a larger difference than most people expect

Shared hosting puts multiple sites on the same server and shares resources between them. During busy periods, those resources are constrained. For a brochure site, this is often acceptable. For a WooCommerce store processing orders, it is a significant limitation.

WP Engine, Kinsta and Cloudways handle WooCommerce better than shared hosting for several reasons. They allocate dedicated PHP workers, which means multiple requests can be processed simultaneously without queuing. They provide object caching through Redis. Their database infrastructure is tuned for performance rather than shared. The difference in time-to-first-byte between shared hosting and a well-configured managed platform can be several seconds on a WooCommerce store.

Image optimisation still matters, but it is not enough on its own

Large product images are a common and straightforward problem to fix. Serving images at the correct dimensions, compressing them appropriately and using modern formats like WebP reduces page weight. On a store with hundreds of products, unoptimised images can add megabytes to catalogue pages.

Image optimisation alone will not fix a slow WooCommerce store if the database is bloated and the server is underpowered, but it is part of a complete approach.

Real results from a WooCommerce optimisation project

A WooCommerce store came in with a 14-second load time. The site had accumulated over 40 unnecessary plugins, the database had not been optimised in years and the hosting configuration had no object caching in place. After addressing database bloat, removing redundant plugins and configuring server-side caching with WooCommerce-aware rules, the load time dropped to under one second. The Lighthouse performance score went above 90. Sales increased by 24% in the period following the work. You can read the full case study.

That result required addressing several problems at once. No single change would have produced it. WooCommerce performance optimisation is an assessment of the whole system, not a single setting.

If you are looking for more detail on WooCommerce-specific development work, the WooCommerce developer page covers the type of work involved.