Most advice on how to speed up a WooCommerce store starts by telling you to buy something. A caching plugin, an image optimiser, a CDN, a “performance suite”. We build and maintain WooCommerce stores for a living, and in our experience the first 60–70% of the speed problem on a typical store is free to fix. The plugins are worth buying — but they’re worth buying after the free work, not instead of it, because a caching plugin bolted onto a badly configured store just caches the mess faster.
Here’s the order we actually work in.
1. Find out what’s slow before you change anything
Two free tools, ten minutes. Run the store’s homepage and a product page through PageSpeed Insights, and look at the field data (real Chrome users) rather than the lab score. Then open Chrome DevTools → Network on a product page and sort by size and by time.
What you’re looking for is which of three things is actually hurting you: a slow server response (TTFB above ~600ms), too much weight on the page (images, fonts, scripts), or blocking requests firing on every single page view. The fixes are completely different, and most people guess wrong. We regularly see stores where the owner has spent €300 on optimisation plugins for a problem that was one badly behaved AJAX call.
2. Kill cart fragments where you don’t need them
This is still the single most common WooCommerce-specific drag we find, and it costs nothing to fix.
WooCommerce’s wc-cart-fragments script fires an uncached AJAX request (wc-ajax=get_refreshed_fragments) to keep the mini-cart widget current. That request bypasses page caching by design and hits PHP and the database. Since WooCommerce 7.8, core no longer enqueues the script on every route — it only loads where the Cart widget is actually rendered. The catch, as WooCommerce documents, is that plenty of themes hard-code the cart widget into the header, and some plugins register cart-fragments as a dependency. So it comes back anyway on a lot of real stores.
Check for it: load a category page, open DevTools → Network, filter for fragments. If you see the request, you’re paying for it on every page view.
WooCommerce’s own recommended fix is to limit where the script executes:
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 );The better long-term answer is to replace the legacy mini-cart widget with the Mini-Cart block, which doesn’t use the fragments API at all. If you’re on a block theme, that’s a header template edit and nothing more.
One caveat we’ve been burned by: if you show a live mini-cart on every page and run full-page caching, the cart count will go stale on cached pages. Pick one. Most small stores are better off with a plain cart link and no live count.
3. Use the caching you’re already paying for
Every decent host gives you server-level caching, and it is faster than any PHP plugin can be, because it answers the request before WordPress boots. Varnish, NGINX FastCGI cache, LiteSpeed — whichever your host runs, turn it on and configure the exclusions properly.
The exclusions matter more than the caching. Cart, checkout, my-account and any wc-ajax endpoint must never be cached. Get that wrong and customers see each other’s carts — which is exactly the kind of failure that lands on our desk as “checkout is broken”. If that’s where you are right now, start with our guide to WooCommerce checkout not working before you touch performance settings.
Also worth knowing: WordPress 6.8 shipped speculative loading in core, on by default for logged-out visitors on sites with pretty permalinks. It prefetches with “conservative” eagerness, which is deliberately safe, and URLs with query parameters are excluded automatically. If your store uses path-based action URLs (add-to-cart, wishlist toggles), exclude them explicitly:
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths ) {
$paths[] = '/cart/*';
return $paths;
} );Free, in core, and it measurably improved Largest Contentful Paint pass rates across the sites that adopted it early.
4. Add a persistent object cache
WooCommerce is query-heavy. Without a persistent object cache, WordPress rebuilds the same option and term queries on every request. Redis or Memcached with the free Redis Object Cache plugin is usually the biggest single TTFB improvement available to a store on decent hosting, and it costs nothing beyond having the service enabled on your server.
Most managed hosts include Redis. If yours doesn’t, that’s a real signal about the hosting — more on that below.
5. Fix image weight properly, not with a plugin
Product images are where store weight comes from, and the free fix is unglamorous: stop uploading 4000px JPEGs. Resize before upload, serve WebP, and make sure your thumbnail sizes in Appearance → Customize → WooCommerce → Product Images match what your theme actually displays. A catalogue page loading 24 full-size images scaled down in CSS is a self-inflicted wound no plugin fully repairs.
WordPress has handled lazy loading natively for years, so you don’t need a plugin for that either. What you do need is to audit the images you already have — that’s a one-off job, and a free bulk optimiser handles it fine.
6. Audit your plugin list — honestly
Deactivate everything non-essential on a staging copy and re-measure. Every store we inherit has 3–5 plugins nobody remembers installing, and typically at least one page builder addon pack loading its entire CSS and JS bundle on every page including checkout. Removing dead weight is free and permanent. Buying a caching plugin to compensate is neither.
While you’re in there: update WooCommerce. WooCommerce 11.0, released 4 August 2026, ships a product object caching experiment enabled by default for new stores that makes variable product pages load roughly 9–12% faster and bundle products process 6–12% faster at checkout, plus an Orders-screen query optimisation for large stores. Free performance you get by keeping current. (Checked August 2026.)
Where paid tools genuinely earn their money
Do all of the above and most small stores land somewhere respectable. Two things are then worth paying for, and only two.
Hosting. If your TTFB is still poor after an object cache and server caching, the server is the problem and no plugin will fix it. Cheap shared hosting oversells CPU, and WooCommerce’s uncacheable pages are exactly where that shows. Cloudways starts around $11/month for a 1GB DigitalOcean server with Varnish, Redis and staging included (checked August 2026) — that is genuinely cheaper than most “performance plugin” bundles and fixes a cause rather than a symptom. We compare the realistic options in Cloudways vs SiteGround for WooCommerce. Cloudways is here if you want to look.
A caching plugin — if your host doesn’t cache. WP Rocket is $59/year for a single site (checked August 2026) and its value is that its WooCommerce defaults are correct out of the box: it excludes cart, checkout and account pages automatically, so you’re paying to not make the mistake in section 3. If your host already runs Varnish or LiteSpeed properly, you don’t need it and layering both usually causes conflicts. WP Rocket is here if your host doesn’t cache.
The short version
Measure first, then remove work rather than adding tools: cart fragments off where they’re not needed, server caching on with correct exclusions, object cache enabled, images sized sanely, plugin list cut back, WooCommerce current. Then, if the numbers still aren’t good, spend money on the server — not on another plugin. That order is what we follow on client stores, and it’s the order that produces results you can still see six months later.
Once the store is fast, the next thing that usually needs attention is payments. If you’re setting up a Dutch store, our Mollie WooCommerce setup guide covers that end to end.
Need this done properly? Intec Infosys handles WooCommerce performance work, plugin configuration and custom development. Get in touch at intecinfosys.com.
