Your blog and About page load quickly. The shop does not. Category pages take a moment to appear, filters spin, the product page feels heavy on a phone, and checkout makes customers wait just when you most want them to keep going. Is your WooCommerce site slow only in the shop? That is a normal pattern for stores, and it tells you where to look.
What follows is about priorities: which parts of a store to look at first, and why. Choosing a host for a store has its own guide to what WooCommerce asks of a hosting plan, and product images, cart fragments and checkout each get their own posts, linked below.
WooCommerce site slow but the blog is fast? Why stores are heavier
A brochure site can serve nearly every visitor from a saved copy, while a store cannot. Shoppers have carts, so some of their pages are built fresh each time. Product listings involve more database work than a blog. And stores tend to collect extensions for filters, wishlists, reviews, shipping, payments and marketing, each adding its own code to the pages that matter.
The practical consequence is that a store has two kinds of pages, and they need different fixes:
- Pages that can be cached for visitors with no cart: home, category and shop pages, product pages, content pages.
- Pages that cannot: cart, checkout and My Account, and in many setups any page viewed by a shopper who has something in the cart.
Make the first kind as fast as caching allows, and make the second kind do less work.
Step one: map the store journey and time it
Before changing anything, time the path a customer actually takes. On mobile, logged out, in a private window, test and write down:
| Step | What to note | Usually cached? |
|---|---|---|
| Home page | Time until the main content appears | Yes |
| A busy category page | Same, plus how long a filter takes to apply | Yes, filtered views often not |
| A product page with variations | Time to load, time for the variation price to update | Yes |
| Add to cart | Time from click to confirmation | No |
| Cart page | Load time with one item | No |
| Checkout | Load time, and the pause after typing an address | No |
Repeat each step a few times. The slowest step on this list is where you start, not the home page score.
Speed up a WooCommerce store, in this order
1. Make sure cacheable pages are actually cached
Many slow stores have a page cache that is switched on but rarely used. Open a category page with the browser’s developer tools on the Network tab and look at the response headers for the page itself. Caching layers usually label the response as a hit or a miss. Reload once and look again. If it is always a miss for a logged-out visitor with an empty cart, something is bypassing the cache.
Common reasons include a plugin that sets a cookie for every visitor, currency switchers and geolocation features that vary pages per visitor, and some customer location settings that add a parameter to page addresses. Recent versions of WooCommerce offer more than one way to detect a customer’s location; the option designed to work with page caching does this by adding a parameter to URLs, which some caches treat as a separate page. Check your caching plugin’s documentation for how it handles your setup.
2. Trim the work on category and shop pages
- Filters. Product filter plugins can run expensive queries, especially with many attributes and a large catalogue. Filters by price, colour and size combined across thousands of products are a common cause of slow category pages. Look at the filter plugin’s settings for caching or indexing options; some build a lookup index that makes filtering much lighter.
- Products per page. Showing a very large number of products on one page means more queries, more images and more HTML. A reasonable page size with pagination or a load-more button is lighter than an endless list.
- Extras on every product card. Quick view, wishlist hearts, compare buttons, swatches and stock badges each add a little to every card, multiplied by every product on the page.
3. Lighten product pages
Product pages often carry the most extension output: size charts, delivery estimates, reviews, related and upsell products, recently viewed lists, trust badges, sharing buttons. Each may add queries and scripts. Ask which ones customers actually use, and remove or move down the page what they do not.
Products with many variations deserve attention. Beyond a certain number of variations, WooCommerce switches from embedding all variation data in the page to fetching it as the shopper chooses options. Variation swatch plugins sometimes change this behaviour. If choosing a size or colour is slow, test with the swatch plugin off.
Images are a large part of product page weight, and they get their own treatment in our post on slow product images and galleries.
4. Reduce what runs on uncached pages
Cart, checkout and account pages run every active plugin’s code on every load. Here a lean extension list helps most. Two store-specific behaviours deserve their own reading: the background request that keeps the header cart count up to date, explained in what cart fragments do and when to limit them, and the checkout itself, where payment, shipping and tax extensions do their work, covered in why WooCommerce checkout takes long to load.
5. Check store search
WordPress’s built-in search matches words in titles and content and was not designed for large catalogues with SKUs and attributes. On a big store it can be slow and not very accurate. Dedicated search plugins build their own index, which is usually faster and better at finding products. If search is slow, measure it on its own: search for a common term and time the results page.
6. Keep the database in shape
Stores write to the database constantly: orders, customer sessions, scheduled background tasks, logs. Over years this grows. Recent versions of WooCommerce store orders in their own dedicated tables (High-Performance Order Storage), which is the default for new stores; older stores may still be on the earlier storage and can migrate after checking that their extensions support it. Expired sessions and old completed background tasks are normally cleaned up on a schedule, but that cleanup depends on WordPress cron running reliably. Our guide to what database optimisation does and does not help with explains what is safe to clear.
The extension audit, store edition
The general advice on judging plugins applies, and the section guide on plugin weight versus plugin count covers it. For stores, a few types of extension deserve a closer look because they run on the pages customers use most:
- Marketing pop-ups and spin wheels that load on every page.
- Live sales notifications (“someone just bought…”) that fetch data in the background.
- Reviews and loyalty widgets served from outside services.
- Several tracking pixels added by different marketing tools.
- Shipping and delivery estimators that call carrier services on product pages.
- Multiple payment gateway plugins, each loading scripts even when the customer will not use that method.
For each one, ask whether it brings in more orders than it costs in speed. You may not know, and that is a reasonable thing to test: switch it off for a period on a quiet week and compare.
Mistakes stores make chasing speed
Caching the cart or checkout. It makes speed tests look wonderful and shows customers the wrong cart. Store pages that change per shopper must stay uncached.
Delaying or combining every script. Aggressive script optimisation can break add-to-cart buttons, variation selection and payment fields. Test a full order after each change.
Testing only the home page. The home page is rarely where a store loses a sale. Time the category, product and checkout steps.
Making changes during a sale. Tune the store in a quiet week, with a backup, on staging first if possible.
For a broader view of how server time, page weight and scripts combine, our guide on how to make a website load faster places store issues alongside everything else.
Frequently asked questions
Why is my WooCommerce site slow only when the cart has items?
Once a shopper adds something, WooCommerce starts a session, and many caching setups then stop serving cached pages to that shopper so they always see the right cart. Every page they view is built fresh. That is expected behaviour. Keep those uncached pages light by trimming extensions and checking the background cart requests.
Does the number of products slow down a WooCommerce store?
A large catalogue is not slow by itself, but it makes some things heavier: filters across many attributes, the built-in search, category pages with many products per page and admin product lists. A well-indexed filter, a dedicated search plugin and sensible page sizes keep a big catalogue quick on the front end.
Should I switch to High-Performance Order Storage?
For many established stores it is worth considering, because orders get dedicated tables instead of sharing the posts tables. Check that your extensions declare compatibility first; WooCommerce shows warnings for ones that do not. Make a full backup, enable synchronisation, test on a staging copy, and switch only when everything still works end to end.
Are WooCommerce Blocks faster than the older shortcode pages?
They work differently, so the answer depends on the store. Block-based cart and checkout pages talk to WooCommerce through its Store API rather than the older page requests, and they suit many stores well. Some extensions still work better with the older pages. Test both on staging with your own extensions before choosing.
Slow product or checkout pages are one of the situations our speed optimisation service is for. Nothing on a live store is changed until you have agreed to it, and complex WooCommerce setups are priced separately after a review.
Next in this series: WooCommerce Cart Fragments: What the Request Does
