A slow WooCommerce store doesn't just frustrate shoppers, it costs sales on every page. The tricky part is that the usual WordPress speed advice only gets you halfway, because a store has moving parts a brochure site doesn't: live carts, checkout, customer sessions and a database that grows with every order. This guide walks through the fixes in the order that delivers the biggest wins first, with the WooCommerce-specific traps, object caching and cart fragments, explained so you don't break the shopping flow while you speed it up.
Why is WooCommerce slower than normal WordPress?
WooCommerce is slower because cart, checkout and account pages can't be fully cached, the AJAX cart-fragments script runs site-wide, and product galleries add weight. Every order also grows the database, slowing queries over time. So a store needs dynamic-page caching and database care, not just page caching.
On a normal site, caching saves a finished copy of each page and serves it to everyone. A store can't do that for cart or checkout, because those pages are different for every shopper. That's the core challenge: you're speeding up pages that have to stay dynamic. Get the approach right and a WooCommerce store can be just as fast as any other site.
Does your hosting hold WooCommerce back?
Often, yes. Stores lean hard on the database and PHP, so cheap shared hosting struggles once traffic and orders climb. Time to First Byte (TTFB) climbs with it. For Australian shoppers, AU-based hosting with enough resources usually returns a lower TTFB, and no front-end tuning fully makes up for a slow server.
How do you speed up WooCommerce step by step?
Optimise product images first (cuts LCP), page-cache the safe pages while excluding cart and checkout, add Redis object caching for dynamic pages, control the cart-fragments script, then clean and index the database. Do them in that order and re-test on real product and checkout pages after each step.
- Optimise product images. Convert to WebP or AVIF, compress, and serve scaled sizes. Product galleries are usually the heaviest thing on a store, so this moves LCP the most.
- Page-cache the right pages. Cache shop, category and product pages, but exclude cart, checkout and my-account so customers never see each other's sessions.
- Add object caching. Enable Redis so repeated database queries are served from memory, cutting server response time on the dynamic pages.
- Control cart fragments. Stop the AJAX cart-fragments script running on pages that don't need a live cart.
- Clean and index the database. Clear expired transients and old sessions, and index key tables so checkout stays fast as orders pile up.
- Re-test on real pages. Measure product and checkout pages, not just the homepage, so your numbers reflect what shoppers feel.
See our WooCommerce speed optimization service: 90+ PageSpeed on real store pages or your money back.
What is object caching and why does WooCommerce need it?
Object caching stores the results of repeated database queries in memory, usually with Redis, so dynamic pages like cart and checkout stop querying the database from scratch every time. Because those pages can't be page-cached, object caching is the main way to make them fast on a busy store.
Picture your database answering the same handful of questions thousands of times a day. Object caching writes down the answers and hands them back instantly. On a store with steady traffic, that's often the single biggest server-side win, and it's exactly the kind of tuning we set up and monitor under our higher care tiers.
How do cart fragments slow WooCommerce down?
Cart fragments are an AJAX request WooCommerce fires to keep the cart count live, and by default it can run on every page, even ones with no cart in sight. That extra request adds load and inflates TTFB site-wide. Limiting it to pages that actually need a live cart removes a common hidden drag.
It's a classic case of a feature doing more than it needs to. A blog post or an About page doesn't need a constantly refreshing cart counter, yet the script runs there anyway. We trim it back to where it belongs, which often shaves a chunk off load time on content pages with no downside to the shopping experience.
How do images and the database affect store speed?
Oversized product images bloat LCP, and a growing, uncleaned database slows every query, especially on cart and checkout. Convert and compress images to WebP or AVIF, lazy-load below the fold, then clear expired transients and old sessions and index key tables to keep the store responsive as it scales.
Images and the database are the two things that quietly get worse as a store succeeds. More products means more images, more orders means a bigger database. Both need ongoing attention, not a one-time fix. That's why our care plans include this housekeeping on the Ecommerce tier, so speed doesn't erode the moment you stop watching.
Which WooCommerce pages should you actually test?
Test real product and checkout pages, not just the homepage. The homepage is usually the lightest page on a store, so it flatters your score. Run PageSpeed Insights on a product page and a cart or checkout page to see what shoppers really experience, and watch both field and lab data.
This is the mistake that fools a lot of store owners. They optimise the homepage to 95, celebrate, and never notice the product pages sitting at 50. Customers spend their time on products and checkout, so those are the pages that move money. Measure where the buying happens. If you want help reading the numbers, our WordPress speed guide covers the testing tools in detail.
How much does store speed affect sales?
More than most owners expect. Studies have repeatedly found that each extra second of load time can cut conversions by around 7 percent, and on a store that compounds across every product page and the checkout. A shopper who's ready to buy will still abandon a cart that hangs, because the friction feels like risk. So speed isn't a vanity metric on a store, it's revenue. A page that loads a second faster doesn't just score better, it sells more, which is why we tie our work to a measurable result rather than a vague "we'll make it faster".
Do too many plugins slow a WooCommerce store?
Often, yes. Stores tend to accumulate plugins for shipping, payments, reviews, marketing and more, and each one can add scripts, styles and database queries to every page. The fix isn't to strip your store bare, it's to audit honestly: keep what earns its place, remove what you don't use, and replace heavy plugins with lighter alternatives where you can. We go through this on every store we optimise, because a leaner plugin stack makes every other speed fix work harder.
Key takeaways
- WooCommerce needs dynamic-page caching and database care, not just page caching.
- Object caching with Redis is the biggest win for cart and checkout speed.
- Control cart fragments so the script isn't running on pages with no cart.
- Test product and checkout pages, not the homepage, where shoppers actually buy.