Why Your WooCommerce Store Is Slow (and How I Fix It)

A slow WooCommerce store usually gets the same treatment: install a caching plugin, run PageSpeed Insights, feel better about the score, and wonder why the checkout still takes forever.

Caching helps, but it mostly hides the slowness from logged out visitors looking at simple pages. Your cart, checkout and account pages can't be served from a page cache, and those are the pages where people pay you.

This post covers what actually makes WooCommerce stores slow, how I find the real cause, and what I fix, in the order I fix it.

Why WooCommerce Is Harder to Speed Up Than a Normal WordPress Site

A blog can serve almost every visitor the same saved copy of a page. A store can't.

Carts, stock levels, prices, shipping and taxes change from one customer to the next, so a lot of pages have to be built fresh by PHP and the database on every request. On a busy store with a large catalog, that means many database queries before the page even starts to load.

That's why the first question I ask isn't "what is your PageSpeed score?" It's "which pages are slow, and for whom?"

Step 1: Measure Before Touching Anything

If you don't measure first, you can't prove anything got better. You also can't tell which change helped and which one did nothing.

I check these numbers on the home page, the shop page, a product page, the cart and the checkout:

These are the targets Google publishes for Core Web Vitals and TTFB. A quick way to check TTFB is from the command line:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://yourstore.com/cart/

The cart page is a useful test because it should never be cached. It shows what PHP and the database are really doing.

That one number splits the problem in two:

• TTFB is high: the problem is on the server. Think hosting, PHP, the database and plugins.
• TTFB is fine but the page is still slow: the problem is in the browser. Think images, JavaScript, CSS and fonts.

Most wasted effort comes from fixing the wrong half. Compressing images won't help a checkout that spends its time waiting on the database.

Step 2: Find What Is Slow With Query Monitor

On a staging copy, I install Query Monitor and load the slow pages. It shows the number of database queries, the slowest queries, and which plugin or theme ran each one.

This replaces guesswork. Instead of turning plugins off one at a time, you can see that one plugin runs a heavy query on every page load, or that a filter is scanning the whole postmeta table.

Deleting plugins at random isn't a strategy. The number of plugins matters far less than what each one does.

Cause 1: Too Much Autoloaded Data

WordPress loads every autoloaded row from the options table on every request. Plugins add rows here, and many leave them behind even after being removed. Here is how to see the largest ones:

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;

The list of values covers the newer autoload settings added in WordPress 6.6. Your table prefix may differ from wp_.

I look for leftovers from removed plugins and large rows that don't need to load on every page. Always take a backup first, and never delete a row unless you know what it belongs to.

Cause 2: A Database Full of Old Data

WooCommerce stores collect data quietly for years. The usual places I check:

• Action Scheduler tables. WooCommerce and many extensions run background jobs through these. Failed or stuck jobs are a sign that something else is wrong.
• Expired transients and old customer sessions. WooCommerce has tools for both under WooCommerce, Status, Tools.
• Old orders and huge postmeta. On stores that still keep orders in the posts tables, order data competes with everything else.
• Orphaned data from plugins that are long gone.

You can check the state of the background jobs with one query:

SELECT status, COUNT(*)
FROM wp_actionscheduler_actions
GROUP BY status;

A large pile of pending or failed actions tells you to find out why before clearing anything. Deleting them removes the symptom and the jobs just pile up again.

For stores with many orders, I also look at High Performance Order Storage (HPOS). It moves orders into dedicated tables, and it's the default on new stores. Older stores often never switched. Check that your extensions are compatible, and do the move on staging first.

Cause 3: Slow Shop and Filter Pages

Category pages with filters are often the slowest pages in a store. Sorting and filtering by price, attribute or stock can get expensive on a big catalog, especially if a filter plugin queries product meta directly.

What I check here:

• That the product lookup tables are healthy. You can regenerate them under WooCommerce, Status, Tools.
• Whether the filter plugin is doing the heavy query, and if it can use an index or a better method.
• Whether related products, "best sellers" and similar blocks are running expensive queries on every product page.
• Whether product variations are being loaded all at once for products with a very large number of them.

Cause 4: Hosting and PHP Limits

Some stores have nothing wrong with the code. They simply run on a server too small for the job.

Before recommending an upgrade, I check the basics:

• A current, supported PHP version with OPcache turned on.
• Persistent object caching with Redis or Memcached, so repeated database lookups come from memory. It's one of the most useful changes for pages that can't be page cached.
• Real server cron instead of WP-Cron, which runs on visitor page loads.
• PHP workers. If there are too few, checkout requests queue up during busy periods even when a single test looks fast.

A hosting upgrade is sometimes the right answer. It's just rarely the first answer, because a bigger server running a bad query is still running a bad query.

Cause 5: Heavy Pages in the Browser

If the TTFB is fine, the time is going into the browser. The usual suspects:

• Oversized images. Serve WebP or AVIF at the size actually displayed.
• The wrong lazy loading. The main product image is usually the LCP element. It should load right away, not lazily.
• Scripts on every page. Sliders, popups, chat, tracking tags and page builder assets often load on pages that don't use them.
• Cart fragments. The get_refreshed_fragments request keeps the mini cart updated, but it can add an uncached request to every page on stores that load it everywhere. Current WooCommerce versions limit it by default, but themes and mini cart widgets can bring it back.

Loading a script only where it's needed is usually a small change. Replace the handles below with the real ones from your site, and test it on staging:

add_action( 'wp_enqueue_scripts', function () {
    if ( is_woocommerce() || is_cart() || is_checkout() ) {
        return;
    }
    wp_dequeue_style( 'example-plugin-style' );
    wp_dequeue_script( 'example-plugin-script' );
}, 100 );

Cause 6: Caching Set Up Wrong

Caching belongs near the end of the work, and it has to be configured for a store. A wrong setup is worse than a slow site, because it can show one customer's cart to another.

• Exclude cart, checkout and my account from the page cache.
• Bypass the cache for visitors with the woocommerce_items_in_cart, woocommerce_cart_hash and wp_woocommerce_session_ cookies.
• If you show prices by location, use the "Geolocate (with page caching support)" option rather than plain geolocation.
• Only run one page caching plugin at a time.
• Test a full order as a logged out customer after every change.

A Real Example: Why You Measure Before You Clean

While writing this post, I profiled the cart page of a small WooCommerce test store on my own computer. It has 43 products and runs the WoodMart theme with Elementor. This isn't a client result, and a local machine isn't a production server, so the total time isn't a benchmark. The breakdown is the useful part:

The database took about 2% of the load time. A database cleanup, usually the first thing people try, would have been wasted effort on this page. Most of the time went on PHP loading WordPress, the theme and the plugins.

The autoload row taught a second lesson. That 483 KB row looked like an easy win, so I removed it. It was back on its own within minutes. Deleting a row doesn't fix anything if something keeps writing it, so find out what creates the data before you remove it.

How I Check the Fix Holds

A speed fix that breaks the checkout isn't a fix. Before anything goes live, I do the work on staging, then test the things that make the store money:

• Add to cart, coupon, shipping and tax calculations.
• A complete order with each payment gateway.
• Order emails and stock changes.
• Product and category pages on a real phone, not just a desktop.

Then I measure the same pages the same way as before. Same pages and same tools are the only way the comparison means anything.

Final Thoughts

A slow store usually doesn't have one big problem. It has a few specific ones, and finding them is most of the job. Measure first, split server problems from browser problems, fix the biggest cause, and measure again.

If your store is slow and you're not sure why, this is the kind of work I do through my Bug Fixing & Performance service. I send you the actual cause first, then a delivery time, before starting. If a bloated Media Library is part of the problem, this guide on deleting unused WordPress images safely will help too.