Why Is My WooCommerce Store Slow? Causes and Fixes

WooCommerce is not slow by default. Stores become slow over time: more products, more orders, more extensions, and a theme that loads everything everywhere. The good news is that the causes are remarkably consistent. These are the ones I find most often, roughly in order of how frequently they are the real problem.

1. Bloated autoloaded options

WordPress loads all autoloaded rows from wp_options on every single request. Plugins — including ones you deleted long ago — leave large values there. A few megabytes of autoloaded data slows every page and every admin screen. Check it:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY size DESC
LIMIT 20;

Remove leftovers from uninstalled plugins and switch large, rarely used options to not autoload — on a backup and staging first.

2. Orders not on HPOS

High-Performance Order Storage moves orders out of the generic posts tables into dedicated tables. It is the default for new stores, but older stores often still run on the legacy storage, which makes order screens and order queries slower as order counts grow. Migrating requires checking that every extension declares HPOS compatibility:

add_action( 'before_woocommerce_init', function () {
    if ( class_exists( \Automattic\WooCommerce\Utilities\FeaturesUtil::class ) ) {
        \Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility( 'custom_order_tables', __FILE__, true );
    }
} );

3. Action Scheduler backlog

WooCommerce and many extensions queue background jobs in Action Scheduler. If WP-Cron does not run reliably — common on low-traffic sites or hosts that disable it — jobs pile up, and the actions tables can grow to millions of rows. Check Tools → Scheduled Actions for thousands of pending or failed jobs, run cron from a real server cron job, and clean up old completed actions.

4. Cart fragments on every page

Older themes enqueue the cart fragments script everywhere, triggering an uncached AJAX request on every page view just to update the mini cart. Load it only where a mini cart is actually displayed, or replace it with a lighter approach.

5. Heavy product filters and search

Attribute filters on large catalogues produce expensive taxonomy queries, and default WordPress search does LIKE scans across post content. For big catalogues, use filtering that relies on lookup tables or a dedicated search index instead of stacking more filter plugins.

6. Too many extensions loading everywhere

Each extension adds hooks, queries and often scripts on every page — even pages where it does nothing. Audit the list: remove what is unused, replace overlapping plugins, and dequeue assets on pages that do not need them. Sometimes several plugins can be replaced by one small custom plugin.

7. No object cache

Page caching cannot help cart, checkout and account pages, because they are personal. A persistent object cache such as Redis caches database results between requests and is one of the most effective improvements for dynamic WooCommerce pages and the admin.

8. Images and the front-end basics

Category pages show dozens of product images. Serve them at the right size, in modern formats, lazy-loaded below the fold, with the first visible image prioritized. This is often the single biggest win for LCP on mobile — see web performance optimization for how I approach Core Web Vitals generally.

Where to start

In my experience two or three of these account for most of the slowdown on any given store. Measure, fix the biggest one, measure again. If you would like a second pair of eyes, WooCommerce performance work is a large part of what I do.