A WooCommerce store is usually slow for six store-specific reasons: cart and checkout pages that can't be cached, the cart fragments script making an extra AJAX call, product filters hammering the database, payment scripts loading on every page, heavy product photos, and hosting sized for a brochure site. Test each page type separately, find out which of these is hurting your store, then fix them in order of impact. Most stores can get a lot faster without a rebuild.
I build and maintain WooCommerce stores for clients in the UK and India, including the Wow Vastra boutique store, which loads in 1.5 seconds, and Nortek LED. This post sticks to the WooCommerce-specific problems. For general WordPress speed work, read my guide to fixing Core Web Vitals on WordPress.
Why is WooCommerce slower than a normal WordPress site?
Because cart, checkout and My Account pages are personal to each shopper. They can't be page-cached, so they run PHP and database queries on every single load. A blog post looks the same to everyone, so a page cache keeps a ready-made copy and serves it instantly. A store can't do that everywhere, and WooCommerce's own developer docs tell you to leave cart and checkout pages uncached.
That means the pages where money changes hands do the most work: sessions, stock checks, tax, shipping rates, coupons, plus whatever each plugin bolts on. A caching plugin will speed up your homepage and category pages. It won't touch a slow checkout.
How do I find out what is slowing my WooCommerce store down?
Measure five page types in PageSpeed Insights before you change anything. Fixing a slow checkout is a completely different job from fixing a slow category page. And please don't start by installing yet another speed plugin.
- 1
Test five page types
Run your homepage, a category page, a product page, the cart and the checkout through PageSpeed Insights on mobile. Stores are rarely slow everywhere.
- 2
Compare cached and uncached pages
If product pages are quick but cart and checkout crawl, look at the server, database and plugins. If everything is slow, look at page weight and hosting.
- 3
Find the plugin causing it
On a staging copy, use Query Monitor to see slow database queries and which plugin runs them.
- 4
Turn the report into a plan
Paste your PageSpeed or Lighthouse report into my free Page Speed Fix Planner to get fixes ranked by impact and effort.
- 5
Fix one thing, retest
Change one thing at a time and test again, so you know what actually helped and what broke.
The Page Speed Fix Planner is free and needs no sign-up. It explains each problem in plain English, which makes it easier to decide what you'll fix yourself and what you'll hand over.
Are cart fragments slowing down my WooCommerce store?
Often, yes. If your theme loads the classic WooCommerce Cart widget on every page, the cart fragments script fires an extra AJAX request to your server on every page view. Cart fragments is the script that refreshes the mini cart in your header after someone adds a product. Before WooCommerce 7.8 it loaded on every page, mini cart or not, and WooCommerce admits this caused unnecessary AJAX requests that could put heavy load on busy stores.
Since 7.8 it only loads where the classic Cart widget appears. The catch is in the same announcement: some themes hard-code that widget into the header, and some plugins list cart fragments as a dependency. So plenty of stores still run it everywhere, including blog posts that will never sell a thing.
How to check and fix it:
- Open your browser's developer tools, go to the Network tab and load a blog post. If you see a request containing
get_refreshed_fragments, cart fragments is running on every page. - Swap the classic mini-cart widget for WooCommerce's Mini-Cart block, which doesn't use cart fragments at all.
- If you have to keep the widget, WooCommerce publishes a snippet that limits cart fragments to shop, cart and checkout pages. The trade-off is that the mini cart won't update on other pages, so test it first.
Why are my WooCommerce product filters so slow?
Every combination of colour, size, price and brand runs a fresh database query that usually isn't cached, and many filter plugins push it through admin-ajax. On catalogue stores, filters are often the slowest thing on the whole site. A filter plugin that feels instant with 200 products can grind with 20,000.
In one Business Bloomer Club discussion, a store owner with 50,000 products found a popular filter plugin too slow. Other members suggested ElasticPress with Elasticsearch, FacetWP or Algolia, depending on budget and technical skill.
| Catalogue size | Filter setup that holds up | Downside |
|---|---|---|
| Small (hundreds of products) | WooCommerce's built-in filter blocks or one well-built filter plugin | Fine until the catalogue grows |
| Mid-size (thousands) | An indexed filter plugin such as FacetWP | Needs decent hosting and an index that stays in sync |
| Large (tens of thousands) | Elasticsearch through ElasticPress, or Algolia | An extra service to pay for and a developer to set it up |
A few habits help at any size. Show only the filters shoppers actually use. Drop live product counts on each option if they drag the page down. Keep the endless filter combinations out of Google's index so crawlers don't waste time on them. I built Nortek LED's store with advanced product filters on a custom Oxygen Builder theme rather than a heavy multipurpose theme. On a build like that I plan the filters and the speed together from the start, because retrofitting either one later is painful. My WooCommerce store build checklist covers what else to plan before launch.
Why is my WooCommerce checkout slow?
It usually comes down to three things: payment scripts loading where they aren't needed, too many checkout plugins, and old order storage.
Payment scripts loading where they aren't needed. The WooCommerce Stripe plugin can load Stripe's scripts on product and cart pages to power Apple Pay and Google Pay buttons. In an older version of the plugin, one GitHub issue showed those scripts loading synchronously on product and cart pages. As a reply in a WordPress.org support thread points out, the express checkout settings let you choose which pages the payment buttons load on. If your shoppers don't use express buttons on product pages, turn them off there.
Too many checkout plugins. Field editors, upsell pop-ups, address lookup, trackers and chat widgets all add JavaScript to the one page where you most need speed. List every script on your checkout and ask whether you'd miss it.
Old order storage. High-Performance Order Storage (HPOS) moves orders out of the WordPress posts tables into their own tables. WooCommerce says HPOS gives up to 1.5x faster checkout and up to 5x faster order creation. New stores get HPOS by default, but older ones may still be on the old storage. Check your extensions are compatible, then switch on a staging copy first.
Test a real order after every change
Never cache the cart, checkout or My Account pages, and place a real test order after any speed change. A fast checkout that fails to take payment is the most expensive bug a store can have.
How heavy should WooCommerce product images be?
Resize them to the size your theme actually displays and serve them as WebP or AVIF. Full-size camera or phone photos are usually the biggest front-end problem on a store. Add an eight-image gallery and a zoom plugin that loads the original file, and a single product page gets very heavy very quickly.
- Resize before upload. Match your WooCommerce image sizes to your theme, so a 400-pixel grid isn't being sent a 2,000-pixel photo.
- Use modern formats. WebP or AVIF with sensible compression usually looks the same and weighs far less. I built Under1MB, a free converter that compresses images in your browser without uploading them anywhere.
- Lazy load the right images. Lazy load gallery thumbnails and anything below the fold, but never the main product image or the first row of a category grid. Those are usually your Largest Contentful Paint element.
- Set width and height on every image so the page doesn't jump around while it loads.
My guide to optimising images without losing quality goes through the settings in more detail.
Is my hosting the reason my WooCommerce store is slow?
Probably, if uncached pages like the cart, the checkout and the wp-admin orders screen stay slow after you've cut plugins and shrunk images. Slowdowns or errors during a sale point the same way. Budget shared hosting is built for brochure sites, so once a store has steady traffic, managed WooCommerce or cloud hosting is usually the safer choice.
| Hosting tier | Typical monthly price | Good for |
|---|---|---|
| Shared or entry WooCommerce plan | Hostinger's WooCommerce plans start from $3.49 a month on offer | New stores with low traffic and a small catalogue |
| Managed WooCommerce or managed cloud | $30 to $100 a month, according to Cloudways | Stores with steady traffic, big catalogues or regular sales |
The setup matters more than the price tag. Look for a current PHP 8 version, server-level page caching that understands WooCommerce's cart cookies, a Redis object cache, enough PHP workers for busy periods, a CDN, and servers close to your customers. If you need to move, I handle hosting migrations with no downtime, with DNS and email moved carefully so nothing goes dark.
What did speed-first builds achieve for my clients?
1.5s
Wow Vastra store load time
35%
Faster load times Nortek LED reported
20%
Conversion rate uplift Nortek LED reported
Wow Vastra is a UK Indian fashion boutique. I built them a new homepage, a currency switcher and worldwide checkout. For Nortek LED, I built the store from Figma on a custom Oxygen Builder theme with product filters and an optimised checkout, and their analytics later showed 30% longer sessions on top of the load time and conversion numbers above.
These were full builds, not one-off speed fixes, so speed wasn't the only thing that changed. What they do show is the difference between speed you plan for and speed you try to bolt on later with plugins.
Should I fix my WooCommerce store myself or hire a developer?
Do the images, unused plugins and settings yourself. Hire a developer for database queries, filters, theme clean-up, cache rules and hosting moves.
You can safely compress and resize images, delete plugins you don't use, switch off express payment buttons on product pages, and run the HPOS compatibility check. The developer jobs are the ones where a mistake breaks things quietly. A cache rule that ignores cart cookies, for example, can show one shopper someone else's cart, and you might not hear about it until the complaints arrive.
Before you hire anyone, ask:
- Will you work on a staging copy, not my live store?
- Which pages will you measure before and after, and will you check real-user data in Search Console as well as lab scores?
- How will you confirm checkout, payments and emails still work?
- Will the fixes survive plugin and theme updates?
- Will you write down what you changed?
What should I do next?
Run your slowest product page and your checkout through PageSpeed Insights, then paste the report into the Page Speed Fix Planner for a ranked list of fixes. If you'd rather hand it over, my technical SEO and Core Web Vitals service covers WooCommerce speed work from diagnosis to retest. Book a 20-minute call and send me your store URL.
