A slow store loses money in a way a slow brochure site does not: the visitor was ready to buy. The research on this is consistent — every extra second on a product or checkout page costs conversion — and WooCommerce speed optimization is its own discipline because stores are slower than plain WordPress sites for structural reasons that the general speed advice only half addresses.
This is the store-specific list. It assumes you have done, or will do, the general work in the WordPress speed checklist — hosting, page cache, fonts, plugins. Here I cover what is different about a store, in order of impact, and the two fixes that break checkout if you get them wrong.
Why stores are slower
- Cart fragments. WooCommerce checks the cart contents with a request on every page so the mini-cart stays current — even on pages with no cart.
- Uncacheable pages. Cart, checkout, account, and anything for a logged-in customer are generated fresh every time.
- Images. Product galleries, variations, category grids — ten times the images of a service site.
- Plugins. Payment gateways, shipping calculators, reviews, wishlists, upsells — each loads scripts, often on every page.
- Database load. Product queries, variations, sessions, order lookups.
The fixes, in order
-
Product images: the biggest win, every time.
Set WooCommerce’s image sizes to what the theme actually displays (Appearance → Customise → WooCommerce → Product Images), regenerate thumbnails, convert to WebP, and lazy-load gallery images below the fold — but not the main product image, which is your LCP element. A store I optimised recently had 4 MB of images per product page; 300 KB after resizing, with no visible difference.
-
Hosting with an object cache.
Cart, checkout and account pages cannot be page-cached, so their speed comes entirely from the server. A host with NVMe storage, recent PHP and Redis or Memcached object caching makes those pages fast by caching the database queries behind them. For a store this is the second-largest improvement available and usually the first thing I check.
-
Page cache with the right exclusions.
Cache product, category and content pages aggressively. Exclude cart, checkout, my-account, and any page once the visitor has items in the cart (most cache plugins detect the WooCommerce cookies and do this — verify by adding a product and reloading a product page: the mini-cart must be correct). A cache serving a stale cart is worse than no cache.
-
Cart fragments: disable where the cart is not shown.
If your header shows no mini-cart, the fragments request is pure cost — disable it (many optimisation plugins have a switch; LiteSpeed Cache and others handle it). If you do show a mini-cart, keep fragments but make sure the request is not blocking the page; it should run after load.
-
Scripts on the wrong pages.
Payment gateway scripts belong on checkout, not the home page. Stripe, PayPal and others often load everywhere; a “scripts manager” or the gateway’s own setting confines them. Same for reviews sliders, wishlist buttons and upsell popups. Audit the home page’s Network tab — a store home page should not load a checkout library.
-
Category pages: fewer products per page, sensible sizes.
Sixty products per category page means sixty images and sixty price queries. Sixteen to twenty-four with pagination or load-more loads several times faster. Use the smallest image size that looks right in the grid.
-
Database housekeeping.
Stores accumulate expired sessions, transients, orphaned variation data and post revisions. Clean them monthly (after a backup). If the store is a few years old and orders are in the thousands, make sure High-Performance Order Storage (HPOS) is enabled — it moves orders into dedicated tables and speeds up the admin and order queries considerably.
-
Checkout page: lean and fast.
Remove fields you do not use, avoid checkout plugins that inject heavy scripts, and test the page speed while logged in with items in the cart — that is the real condition. A checkout that takes four seconds to paint loses buyers who already decided.
-
Search and filters.
Default WooCommerce search is a slow LIKE query. On a large catalogue, a search plugin with its own index (or a hosted search) is a noticeable improvement; filter plugins with AJAX should be tested for how many queries they fire per click.
-
CDN for images, if customers are far from the server.
Product imagery is where a CDN pays off most. Many hosts include one; enable it and confirm images serve from it.
What breaks checkout if you get it wrong
Two danger zones. First, JavaScript delay/defer applied blindly: checkout scripts (gateways, address validation) that load late or out of order produce “payment failed” errors that only some customers see. Exclude checkout and cart from JS optimisation, or test every payment method after enabling it. Second, page caching the cart or checkout: customers see each other’s carts or stale totals. Verify the exclusions with a real test order after any cache change.
Measuring a store properly
Test four pages, on mobile, and two states:
- Home, a category, a product — logged out, empty cart (cached state).
- A product with an item in the cart, and the checkout — the uncached state.
The uncached numbers are the ones that decide whether a buyer completes. Watch Largest Contentful Paint on the product page and Interaction to Next Paint on checkout (button taps); the Core Web Vitals guide explains both.
Typical results
| Fix | Typical gain |
|---|---|
| Right-sized WebP product images | 1–3 s on product and category pages |
| Object cache (Redis) on good hosting | 0.5–2 s on cart, checkout and logged-in pages |
| Page cache with correct exclusions | 0.5–1.5 s on cached pages |
| Confining gateway and plugin scripts | Large INP improvement; 0.2–0.8 s load |
| Fewer products per category page | 0.5–2 s on category pages |
| Database cleanup + HPOS | Faster admin and order pages; small front-end gain |
If you are choosing a platform because of speed
A well-hosted, well-built WooCommerce store is fast. A neglected one is not, and Shopify’s consistent performance is a fair reason some businesses choose it — the trade-offs are in Shopify vs WooCommerce. If you are staying on WooCommerce, the list above is the difference.
Further reading: WooCommerce documentation · PageSpeed Insights.
FAQ
Why is my WooCommerce store slower than my other WordPress site?
Stores do more per page: cart fragment requests, session handling, more images, more plugins, and pages that cannot be cached for logged-in shoppers or once something is in the cart. Each of those needs its own fix.
Can I use page caching with WooCommerce?
Yes, for product and category pages and the rest of the site. Cart, checkout and account pages must be excluded, and most cache plugins do this automatically when WooCommerce is detected. Check it rather than assume it.
Does Redis object caching help a WooCommerce store?
Usually a great deal, because it speeds up the database queries behind every uncached page — cart, checkout, account, and any page for a logged-in customer. It is one of the most effective store-specific fixes.
What is the single biggest cause of a slow WooCommerce store?
Oversized product images, followed by cheap hosting. Right-sizing images to WebP and moving to a host with NVMe storage and a server cache fixes most stores before anything else is touched.
Store slow and not sure which of these is yours? Request a free store audit — I test the four pages in both states and tell you the three fixes worth doing first, with numbers.
