Blog · WebJi® India

Speed Up WooCommerce

Quick answer

WooCommerce is usually slow because catalogue pages run uncached PHP, product images are oversized and the database is bloated. Cache pages with cart and checkout excluded, limit cart fragments, serve WebP images, enable High-Performance Order Storage and run PHP 8.3 or newer. Measure before and after each change.

For WooCommerce store owners and developers who want a measured order of fixes rather than another speed plugin.

✓ In business since 2005

✓ INR + GST billing

✓ 24/7 Email Support — avg reply < 60 min

Get Started View Plans

GuideWebJi®
knowledge

Read time: 5 min
Sections: 8
Updated: 14 Nov 2026
Written by: WebJi® team

Last editorial update: 14 November 2026. Prices follow the dated sources on this page; checkout confirms current charges.

What actually slows a WooCommerce store

Four causes explain most slow WooCommerce stores: catalogue pages built with uncached PHP, cart-fragment AJAX requests, product images heavier than they display, and database bloat from old revisions, transients and order data. Fix them in the order below; each fix has a check you can see, so you never have to guess whether a plugin helped.

Uncached PHP: every product and category view builds the page from scratch, often with dozens of database queries.
Cart fragments: the wc-cart-fragments script calls ?wc-ajax=get_refreshed_fragments to keep a mini-cart up to date.
Image weight: a 2,000 px product photo shown at 400 px still downloads at 2,000 px.
Database bloat: revisions, expired transients and orders stored as posts slow every query.

Measure before you change anything

Test your heaviest category page and one product page, not the homepage, and record four numbers before and after every fix. Homepages are usually cached first and flatter the store.

Run PageSpeed Insights in mobile mode on a category page and a product page; note LCP and total bytes.
Open browser DevTools, Network tab, reload a product page and look for a wc-ajax=get_refreshed_fragments request.
Install Query Monitor and note the query count and slowest query on a shop page.
In your hosting panel's resource-usage page, note the 24-hour peak for CPU and entry processes.

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

Fix 1: cache catalogue pages, never cart or checkout

Full-page caching is the biggest single win: product and category pages become static HTML, while cart, checkout, my-account and logged-in sessions must stay dynamic. A cached checkout can show one customer another customer's cart.

In your cache plugin (LiteSpeed Cache, WP Rocket, W3 Total Cache), exclude /cart/, /checkout/ and /my-account/, and bypass the cache when the woocommerce_items_in_cart cookie is set.
Turn on the plugin's WooCommerce preset if it has one.
Purge everything, then open a category page in two browsers. Add a product in one; the other browser's cart must stay empty.
Check the response headers: LiteSpeed returns x-litespeed-cache: hit on a cached page, and other plugins add their own header or HTML comment.

Exclusion steps for the common plugins are in how to clear WordPress cache.

Fix 2: limit cart fragments to shop pages

Since WooCommerce 7.8, the cart-fragments script is loaded only where the classic Cart widget is active, where another script depends on it, or where code enqueues it, so first check whether your store still makes the request. If the Network tab shows no get_refreshed_fragments call, skip this fix.

If your theme's header mini-cart still triggers it on every page, WooCommerce's developer blog recommends replacing the classic Mini-Cart widget with the Mini-Cart block, which does not use the cart-fragments API. Where that is not possible, its published snippet keeps the script from running outside shop, cart and checkout pages:

add_filter( 'woocommerce_get_script_data', function ( $script_data, $handle ) {
    if ( 'wc-cart-fragments' === $handle ) {
        if ( is_woocommerce() || is_cart() || is_checkout() ) {
            return $script_data;
        }
        return null;
    }
    return $script_data;
}, 10, 2 );

Put it in a child theme's functions.php or a small site plugin, never the parent theme. The trade-off: a header mini-cart on blog or content pages stops updating live, so keep a visible cart link.

Fix 3: images, fonts and theme weight

Product images are usually the largest download, so serve WebP or AVIF at the size the page displays and let srcset pick the right file for each device.

Format: convert catalogue images to WebP at around 80–85 quality.
Dimensions: set width and height so the layout does not jump while images load.
Lazy loading: lazy-load below-the-fold images, but keep the main product image eager so LCP is not delayed.
Fonts: one family and two weights; every extra weight is another file to download.
Theme: test a lighter theme on a staging copy; a heavy theme costs more than any plugin saves.

Re-run PageSpeed on the same category page; if total bytes barely change, an image is still served at full size. Plugin options are compared in WordPress image optimisation.

Fix 4: clean the database and use HPOS for orders

Move orders to High-Performance Order Storage (HPOS) and remove old revisions and expired transients; older stores that still keep orders as posts carry that data in the postmeta table, which slows every query. HPOS is the default for new WooCommerce stores; older stores switch it on themselves.

Back up the database first.
Delete old post revisions, spam comments and expired transients with a database clean-up plugin.
Open WooCommerce → Settings → Advanced → Features, enable High-Performance Order Storage, and let the sync finish.
Check WooCommerce → Status for any pending sync, then reload a shop page in Query Monitor and compare query time.

Schedule clean-ups for a quiet hour, never during a sale. The tables involved are explained in the WordPress database explained.

Fix 5: PHP version, memory, object cache and the plan

After the first four fixes, the remaining limit is usually the server: run a supported PHP version, give WordPress enough memory, and add an object cache when the same data is read on every request.

PHP: use 8.3 or newer. PHP 8.2 receives only security fixes and reaches end of life on 31 December 2026, according to php.net. Switch versions with MultiPHP in cPanel.
Memory: add define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php above the “stop editing” line, within the limit your plan allows.
Object cache: enable Redis where the host offers it; the setup is in the Redis object cache guide.

If cached pages are fast but checkout still queues at peak, the constraint is PHP workers, not caching. That is when to compare plans: WebJi® WooCommerce hosting starts at ₹300 a month before 18% GST on LiteSpeed and NVMe, and busier stores get a quoted commerce tier; checkout confirms the price. What a store needs from a host is listed in WooCommerce hosting requirements.

The order to do the work

Work through the five fixes in sequence, checking each result before starting the next.

WooCommerce speed fixes in order, with the check for each
Fix	Typical time	Risk	How you know it worked
Page cache with exclusions	30 minutes	Low, if cart and checkout are excluded	Cache-hit header on category pages; two-browser cart test passes
Limit cart fragments	15 minutes	Header mini-cart stops updating on content pages	No `get_refreshed_fragments` request on content pages
Images and lazy load	1 hour	Low; keep originals	Total bytes drop sharply on a category page
Database clean-up and HPOS	1 hour	Medium; back up first	Fewer queries and lower query time
PHP, memory, Redis	30 minutes	Low	Cart and account pages load with fewer queries

If the numbers still do not move, a theme or plugin is the cause; Query Monitor shows which component adds the queries. The WordPress speed optimisation service handles that pass, and the non-shop half is in the general WordPress speed guide.

FAQ

Frequently asked questions

Should I cache the WooCommerce checkout page?

No. Cart, checkout and my-account must stay dynamic, and logged-in users and visitors with items in the cart should bypass the page cache. A cached checkout can show one shopper another shopper's cart or session.

Does WooCommerce need Redis object caching?

Only when the database is the bottleneck. Redis helps a store that reads the same options and product data on every request and cuts query time on cart and account pages. It does not fix oversized images or an uncached catalogue.

How many products can WooCommerce handle?

WooCommerce has no hard product limit; the ceiling is the database and PHP workers beneath it. Large catalogues run well when orders use HPOS, catalogue pages are cached and the database is indexed and kept clean.

Do payment gateways like Razorpay slow down checkout?

The gateway's script adds some weight to the checkout page only, which is acceptable. Slowness elsewhere usually comes from plugins loading checkout scripts on every page; check Query Monitor and the Network tab to see which plugin loads what.

Checked 15 November 2026 against the WooCommerce developer blog and php.net · Reviewed by the WebJi® team, Jaipur.

WebJi® since 2005

Ready to get started with WebJi®?

Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.

Talk to an Expert Compare Plans