Speed Up WooCommerce

What actually slows a WooCommerce store

WooCommerce is slow because catalog pages run uncached PHP and cart fragments fire an admin-ajax request on every page. Cache pages with cart and checkout excluded, dequeue wc-cart-fragments outside those pages, compress images to WebP, and clean expired transients. Measure TTFB and Query Monitor before and after each change.

Four causes explain most slow stores. Fix them in the order below and each one has a check you can see, so you are never guessing whether a plugin helped.

• Uncached PHP: every product and category view builds the page from scratch, including dozens of database queries.
• Cart fragments: wc-cart-fragments calls admin-ajax.php?wc-ajax=get_refreshed_fragments on every page, even pages with no cart.
• Image weight: a 2,000 px product photo shown at 400 px still downloads at 2,000 px.
• Database bloat: post revisions, expired transients and order data stored in postmeta slow every query.

Measure before you change anything

Test the heaviest category page, not the homepage. Homepages are cached first and flatter the store. Record four numbers, then repeat the same test after each fix.

1. Run PageSpeed Insights in mobile mode on one category page and one product page. Note LCP and total bytes.
2. Open DevTools, Network tab, reload a product page, and sort by size. Look for a request to admin-ajax.php with wc-ajax=get_refreshed_fragments.
3. Install Query Monitor and open a shop page. Note the query count and the slowest query.
4. In cPanel open Metrics, then Resource Usage, and note the 24-hour peak for CPU and entry processes.

Write the numbers down. A fix that does not move one of them did not work, whatever the plugin's dashboard says.

Fix 1: cache pages, never cart or checkout

Page caching is the biggest single win. Product and category pages become static HTML, so PHP and MySQL are skipped for most visitors. Cart, checkout, my-account and logged-in sessions must stay dynamic.

1. In LiteSpeed Cache open Cache, then Excludes, and add /cart/, /checkout/ and /my-account/ to the Do Not Cache URIs.
2. Turn on the WooCommerce preset if the plugin offers one; it adds the cart cookie bypass and ESI blocks for the mini-cart.
3. Purge all, then load a category page in two different browsers. Add a product in one; the other cart must stay empty.
4. Check the response header. A cached page returns x-litespeed-cache: hit; a miss means the exclusion list or the cookie rule is wrong.

On a non-LiteSpeed stack, WP Rocket and W3 Total Cache do the same job with their own exclusion fields. The rule is identical: static pages cached, commerce pages and cart cookies bypassed.

Fix 2: stop cart fragments on every page

WooCommerce loads the cart-fragments script everywhere so the header cart total can refresh without a reload. On a content page that request is wasted work. Dequeue it outside cart and checkout.

add_action( 'wp_enqueue_scripts',
  function () {
    if ( ! is_cart() &&
         ! is_checkout() ) {
      wp_dequeue_script(
        'wc-cart-fragments' );
    }
  }, 20 );

Put that in the child theme's functions.php or a site-specific plugin, never in the parent theme. The trade-off: a mini-cart in the header stops updating live on product pages, so keep a cart link visible. Reload the product page and confirm the wc-ajax request is gone from the Network tab.

Fix 3: images, fonts and theme weight

Product images are usually the largest download on the page. Serve WebP at the size the page displays, and let the browser pick from srcset instead of shipping one giant file to every device.

• Convert catalog images to WebP at 80–85 quality; keep the original as a fallback only if you still support very old browsers.
• Set explicit width and height so the layout does not jump while images load.
• Lazy-load everything below the fold, but keep the first product image eager so LCP is not delayed.
• Load one font family and two weights; every extra weight is another file render-blocking the page.
• Test a lighter theme on a staging copy. A bloated theme costs more than any plugin saves.

Re-run PageSpeed on the same category page. Total bytes should drop by roughly half on an image-heavy catalog; if it does not, an image is still being served at full size.

Fix 4: database bloat and order storage

WooCommerce stores orders as a post type by default, which means order data lives in postmeta and grows with every order, note and status change. High-Performance Order Storage (HPOS) moves orders into their own tables.

1. Back up the database before any cleanup. A cPanel backup or a plugin export is enough.
2. Delete post revisions older than the last month, spam comments and expired transients with WP-Optimize or WP-Sweep.
3. Open WooCommerce, Settings, Advanced, Features, and enable High-Performance Order Storage. Run the sync when prompted.
4. Check the status report under WooCommerce, Status, and confirm there is no pending sync or orphaned order data.
5. Reload the shop page in Query Monitor. Query time on category pages should fall, especially on stores with thousands of orders.

Do not run a blanket "delete all transients" during a sale; it clears caches mid-campaign. Schedule cleanup for a quiet hour.

Fix 5: PHP memory, object cache and the plan

After the four fixes, the remaining limit is usually the server. Raise the PHP memory limit, run a current PHP version, and add an object cache when the same options and products are read on every request.

• Set define( 'WP_MEMORY_LIMIT', '256M' ); in wp-config.php above the "stop editing" line.
• Run PHP 8.2 or newer; older versions are slower and no longer receive security fixes.
• Enable Redis object cache from the host panel where it is offered, then load a cart page twice and compare query time.

If cached pages are fast but checkout still queues at peak, the constraint is PHP workers, not caching. That is the point to compare plans: WebJi WordPress plans are ₹400 and ₹500 a month before 18% GST, and a shop that has outgrown them belongs on a WooCommerce hosting or cloud tier. The Redis object cache guide covers the setup in detail.

The order to do the work

Do the fixes in this order. Each one takes under an hour on a normal store, and each has a check you can see before moving on.

If the numbers still do not move after all five, the theme or a plugin is the cause. Query Monitor's plugin list shows which one adds the queries. The WordPress speed optimisation service exists for that pass, and the general WordPress speed guide covers the non-commerce half.