WooCommerce Site Slow? The 5 Plugins Usually Causing It

WooCommerce sites slow down for the same general reasons any WordPress site does (see how to fix Core Web Vitals on WordPress for that base list), plus five plugin categories that show up disproportionately often on stores specifically: page builders, all-in-one SEO and marketing suites, related-product and upsell plugins, reviews and UGC widgets, and security or backup plugins running constant background scans. There is also a WooCommerce-specific culprit almost every generic WordPress speed guide misses entirely.

The five plugin categories

• Page builders and visual editors (Elementor, Divi, Beaver Builder, and similar). These generate deeply nested markup and per-page CSS and JavaScript that frequently duplicates what the theme already ships, and it compounds fast across a full product catalogue.
• All-in-one SEO and marketing suites. Some bundle an SEO plugin with analytics, a redirect manager, a schema generator, and social sharing bloat, all firing on every page load. If you only need on-page SEO and schema, a lean single-purpose plugin does less damage.
• Related-products and upsell plugins. "Frequently bought together" and cross-sell widgets run extra database queries per product page and often add their own sitewide script, even on pages where no recommendation ever shows.
• Reviews and UGC widgets. Star ratings, review carousels, and photo-review plugins tend to re-render on every single product page rather than caching their output, adding both server and front-end cost per view.
• Security, firewall, and backup plugins. These do not touch your front-end JavaScript, but constant background scanning competes for server CPU and memory, which inflates Time to First Byte, exactly the TTFB problem that also plagues plain WordPress on shared hosting.

The WooCommerce-specific culprit: cart fragments

Here is the one most generic WordPress speed guides skip because it is not a WordPress problem, it is a WooCommerce one. By default, WooCommerce fires an AJAX request (wc-ajax=get_refreshed_fragments) on nearly every page load to keep the mini-cart in sync with the server-side cart session. That request runs whether or not anything in the cart has actually changed, and it is notoriously awkward to reconcile with full-page caching, since a cached page still needs that request to show accurate cart contents.

The fix is not to rip it out blindly (your mini-cart will go stale), it is to scope it: only fire fragments refresh on pages where the cart indicator is actually visible and after an action that could plausibly change it (add to cart, quantity update), rather than on every page load by default.

What to actually do about it

1. Audit plugins and uninstall, don't just deactivate. A deactivated plugin can still leave scheduled cron tasks, cached data, or database bloat behind. Uninstall what you do not use.
2. Check for overlap. It is common to find two plugins both generating schema markup, or an SEO suite duplicating a feature your page builder already handles. Pick one.
3. Scope cart fragments to where they are needed. Limit the refresh request to cart-relevant pages and cart-changing actions instead of every page load.
4. Then work the general WordPress list. Theme weight, image optimisation, and render-blocking CSS and JavaScript still apply exactly as they do on any WordPress site; see the WordPress Core Web Vitals fix guide for the priority order.

The takeaway

WooCommerce inherits every WordPress performance problem and adds a few of its own, mostly around plugins built specifically for stores and the cart fragments request baked into WooCommerce core. Fixing it usually means an honest plugin audit plus scoping that one AJAX call properly, not another plugin promising to fix the previous six.

Not sure which of your plugins is actually the drag? That is exactly the kind of question a Core Web Vitals audit answers with evidence instead of guesswork.