Key Takeaways
- The average WooCommerce store runs 30–50 plugins — each one adds PHP execution time, database queries, and JavaScript to every page load
- 5 plugin categories cause 80% of WooCommerce slowdowns: page builders, social media plugins, analytics/tracking, abandoned cart recovery, and multi-purpose “Swiss army knife” plugins
- Conditional loading (only loading plugin assets on pages where they’re needed) can reduce JavaScript by 40–60% on non-relevant pages
- Payment gateway plugins load 200–500KB of JavaScript on every page by default — restrict them to checkout only for an instant site-wide speed boost
- Replacing 3–4 heavyweight plugins with a single lightweight alternative often improves speed more than any server-side optimisation
The WooCommerce plugin performance problem
Every WordPress plugin adds overhead. Each plugin loads its PHP files, registers hooks, queries the database, and potentially enqueues CSS and JavaScript on every page. For a standard WordPress blog with 10–15 plugins, this overhead is manageable. For a WooCommerce store with 30–50 plugins — which is typical — the accumulated overhead becomes the primary speed bottleneck.
WooCommerce itself is a plugin ecosystem built on a plugin platform. A typical store has WooCommerce core, a payment gateway plugin, a shipping plugin, a tax plugin, an email marketing integration, a reviews plugin, a product customisation plugin, a coupon/loyalty plugin, an SEO plugin, a security plugin, and a caching plugin. That’s 11 plugins before you’ve added any store-specific functionality. Each plugin that touches the WooCommerce speed optimisation chain adds its own database queries, AJAX handlers, and frontend scripts.
The solution isn’t to remove all plugins — most serve legitimate business purposes. The solution is to audit every plugin’s performance impact, replace heavy plugins with lightweight alternatives, conditionally load plugin assets, and eliminate plugins you’re not actually using.
How to audit WooCommerce plugin performance
Before removing or replacing plugins, you need data on which plugins actually impact performance. Guessing leads to removing useful plugins while keeping the real offenders.
The most effective audit tool is the Query Monitor plugin. Install it on your staging site (never on production long-term) and it shows you exactly which plugins add database queries, how long each query takes, which scripts and styles each plugin enqueues, and how many PHP hooks each plugin registers.
Key metrics to check for each plugin:
- Database queries: How many queries does the plugin add per page load? Plugins adding 10+ queries to non-relevant pages are candidates for conditional loading or replacement.
- JavaScript size: Check the plugin’s enqueued scripts in Chrome DevTools. Plugins loading 100KB+ of JavaScript on every page are significant offenders.
- HTTP requests: External API calls (analytics, chat widgets, font services) add latency. Each external request adds 100–500ms depending on the service.
- PHP execution time: Query Monitor shows time spent in each plugin’s hooks. Plugins consuming more than 50ms of PHP time per page load deserve attention.
Run the audit on four page types: homepage, product page, category page, and checkout. A plugin might be lightweight on the homepage but add significant overhead on product pages (or vice versa). The goal is to understand the full performance picture, not just one page.
For a broader perspective on how plugins fit into overall site performance, see our guide on why WordPress sites are slow.
The five worst plugin categories for WooCommerce speed
1. Page builders (Elementor, Divi, WPBakery). Page builders generate bloated HTML with deeply nested divs, inline styles, and heavy JavaScript frameworks. An Elementor-built product page can output 3–5x more HTML than a theme-coded equivalent. The JavaScript framework alone (elementor-frontend.min.js) is 300–500KB. For WooCommerce stores, page builders are the single biggest performance problem — and the hardest to fix because they’re deeply integrated into the site structure.
2. Social media and sharing plugins (AddToAny, Social Warfare, ShareThis). These load JavaScript on every page to render share buttons that fewer than 0.1% of visitors click. A typical sharing plugin adds 80–150KB of JavaScript and makes 2–4 external HTTP requests (to Facebook, Twitter, Pinterest APIs). The conversion value of share buttons on product pages is near zero.
3. Analytics and tracking suites (MonsterInsights, Pixel Your Site, multiple Google Tag Manager implementations). A single Google Analytics implementation adds minimal overhead. But stores often stack MonsterInsights (its own JavaScript wrapper around GA), Facebook Pixel, Pinterest Tag, TikTok Pixel, and conversion tracking for 3 different ad platforms. Each tracking script adds 30–80KB and 1–2 external requests.
4. Abandoned cart recovery plugins (CartFlows, YITH WooCommerce Recover Abandoned Cart). These plugins need to track every customer interaction to detect cart abandonment. They add JavaScript to every page, make AJAX calls to record customer activity, and run background processes to send emails. The JavaScript tracking alone adds 50–100KB to every page load.
5. Multi-purpose “Swiss army knife” plugins (Jetpack, All-in-One WP Security, Wordfence). These plugins bundle 20+ features, most of which you don’t use. Jetpack alone loads modules for stats, social sharing, related posts, image CDN, markdown, custom CSS, and more — each module adds hooks and database queries even if you don’t use the feature. Use specific, lightweight plugins for each feature you actually need.
Conditional loading: load assets only where needed
Most WooCommerce plugins load their CSS and JavaScript on every page of your site, regardless of whether the plugin’s functionality is used on that page. Your contact form plugin’s JavaScript loads on product pages. Your product review plugin’s CSS loads on your blog posts. Your checkout-specific scripts load on your homepage.
Conditional loading (also called asset cleanup or selective loading) dequeues plugin assets on pages where they’re not needed. This is the highest-impact performance fix that doesn’t require removing any plugins.
Manual conditional loading via your theme’s functions.php:
add_action('wp_enqueue_scripts', function() {
// Contact Form 7 — only load on contact page
if (!is_page('contact')) {
wp_dequeue_script('contact-form-7');
wp_dequeue_style('contact-form-7');
}
// WooCommerce scripts — don't load on blog posts
if (is_singular('post')) {
wp_dequeue_script('wc-cart-fragments');
wp_dequeue_style('woocommerce-general');
wp_dequeue_style('woocommerce-layout');
wp_dequeue_style('woocommerce-smallscreen');
}
}, 99);
For more granular control, use the Asset CleanUp (Pro) or Perfmatters plugin. These provide a per-page interface where you can toggle individual scripts and styles on or off. The visual interface makes it easy to identify which plugin loads what, and to disable assets page by page.
The result is dramatic. A typical WooCommerce store loading 25 JavaScript files on every page can often reduce that to 10–12 on non-shop pages, saving 40–60% of JavaScript weight and significantly improving AJAX and interaction performance.
Payment gateway plugin optimisation
Payment gateway plugins are among the worst offenders for loading unnecessary scripts site-wide. Stripe’s JavaScript library weighs 150–250KB. PayPal’s SDK is 200–400KB. Square’s payment form adds another 200KB+. Most gateway plugins enqueue these scripts on every page by default.
The fix is straightforward — restrict payment scripts to the checkout page:
add_action('wp_enqueue_scripts', function() {
if (!is_checkout()) {
// Stripe
wp_dequeue_script('stripe_v3');
wp_dequeue_script('wc-stripe-payment-request');
wp_dequeue_style('stripe_styles');
// PayPal
wp_dequeue_script('ppcp-smart-button');
wp_dequeue_script('ppcp-oxxo');
// Square
wp_dequeue_script('square-credit-card');
}
}, 99);
If you offer PayPal or Apple Pay express checkout buttons on product pages, you’ll need to keep those specific scripts loaded on product pages while still removing them from blog posts and non-shop pages. Adjust the conditional logic accordingly:
add_action('wp_enqueue_scripts', function() {
// Only load payment scripts on WooCommerce pages
if (!is_woocommerce() && !is_cart() && !is_checkout()) {
wp_dequeue_script('stripe_v3');
wp_dequeue_script('ppcp-smart-button');
}
}, 99);
This single optimisation typically saves 200–500KB of JavaScript on every non-checkout page — one of the easiest and highest-impact fixes available. We covered this in detail in our checkout speed guide.
Lightweight plugin alternatives
Sometimes the best optimisation is replacing a heavyweight plugin with a lightweight alternative that does the same job with a fraction of the overhead.
SEO: Rank Math vs Yoast SEO. Both are feature-rich, but Rank Math is consistently lighter on database queries and JavaScript. Yoast’s frontend output includes 200+ lines of HTML comments and schema markup. Rank Math’s output is cleaner and configurable.
Security: Wordfence vs simple security headers. Wordfence runs a PHP-based firewall that adds 20–50ms to every page load and makes 10–15 database queries per request. For most WooCommerce stores, server-level security (Cloudflare WAF, fail2ban, proper file permissions) provides better protection with zero PHP overhead. If you need a WordPress security plugin, use a lightweight option like BBQ Firewall (2KB, no database queries).
Analytics: MonsterInsights vs direct GA4. MonsterInsights wraps Google Analytics in a WordPress plugin that adds its own JavaScript, PHP hooks, and admin interface. The same tracking can be achieved with a 4-line script tag or a single GTM container — no plugin needed, no PHP overhead.
Sharing: Social plugins vs static share links. Replace a 150KB sharing plugin with static HTML links that use native browser sharing APIs. Zero JavaScript, zero external requests, and share buttons still work:
<a href="https://twitter.com/intent/tweet?url={permalink}" target="_blank" rel="noopener">Share on X</a>
<a href="https://www.facebook.com/sharer/sharer.php?u={permalink}" target="_blank" rel="noopener">Share on Facebook</a>
Live chat: Tawk.to/Intercom vs Tidio or delayed loading. Live chat widgets typically load 200–400KB of JavaScript on every page. If chat isn’t critical for immediate sales, load the chat widget only after 5 seconds of user interaction or when the customer scrolls 50% down the page. This eliminates the performance impact for visitors who never use chat (95%+ of visitors).
The essential WooCommerce plugin stack
After auditing hundreds of WooCommerce stores, here’s the minimal plugin stack that covers core functionality without significant performance overhead:
- WooCommerce core — unavoidable, obviously
- One payment gateway (Stripe recommended) — conditionally loaded on checkout only
- One SEO plugin (Rank Math) — lightweight, replaces sitemap and schema plugins too
- One caching plugin (WP Super Cache, W3 Total Cache, or host-provided) — page caching and browser caching
- Redis Object Cache — if your host provides Redis
- One image optimisation (ShortPixel or CDN-based) — WebP conversion and compression
- One email service (WP Mail SMTP) — reliable transactional email delivery
- One backup solution (UpdraftPlus or host-provided) — not performance-impacting if scheduled during off-hours
That’s 8 plugins. Compare this to the 30–50 plugins most stores run. Every additional plugin beyond this core stack should justify its existence with measurable business value that outweighs its performance cost. If a plugin adds 200ms to every page load but generates £50/month in value, that’s a poor trade-off for a store where 200ms of delay costs £200/month in lost conversions.
The principle is simple: fewer plugins means faster pages, fewer conflicts, fewer security vulnerabilities, and easier maintenance. Apply this ruthlessly and your store will outperform competitors who run 40+ plugins on every page. For a comprehensive list of optimisation steps, see our WooCommerce speed checklist.
How many plugins is too many for WooCommerce?
There’s no absolute limit — a well-coded plugin adds minimal overhead while a poorly coded one can slow your entire site. However, most WooCommerce stores can operate with 8–15 essential plugins. If you’re running 30+, you almost certainly have redundant plugins, plugins you installed once and forgot about, and plugins whose functionality can be replaced with a few lines of code. Audit each plugin’s database queries, JavaScript size, and PHP execution time before deciding what to keep.
Which WooCommerce plugins slow down my site most?
The five worst categories are: page builders (Elementor, Divi — 300–500KB JavaScript), social sharing plugins (80–150KB JavaScript on every page), analytics suites (MonsterInsights + tracking pixels — multiple external requests), abandoned cart plugins (50–100KB JavaScript + AJAX tracking), and multi-purpose plugins (Jetpack, Wordfence — bundle features you don’t use). Install Query Monitor on your staging site to measure each plugin’s actual impact.
What is conditional plugin loading in WooCommerce?
Conditional loading means only loading a plugin’s CSS and JavaScript on pages where they’re actually needed. For example, your contact form plugin’s scripts only load on the contact page, and payment gateway scripts only load on checkout. Use Asset CleanUp Pro, Perfmatters, or manual wp_dequeue_script() calls in your theme’s functions.php. This typically reduces JavaScript by 40–60% on non-relevant pages without removing any functionality.
Does Elementor slow down WooCommerce?
Yes. Elementor’s frontend framework adds 300–500KB of JavaScript and generates HTML that’s 3–5x larger than theme-coded pages. For WooCommerce stores, this means slower product pages, larger DOM sizes that affect INP scores, and more CSS to parse. If you’re already using Elementor, mitigate the impact by disabling unused widgets, using Elementor’s built-in performance features (reduced CSS, deferred JavaScript), and never using Elementor on checkout pages.
Should I replace WooCommerce plugins with custom code?
For simple functionality, yes. Social share buttons, Google Analytics tracking, basic schema markup, and simple conditional logic can all be achieved with a few lines of code in your theme’s functions.php — replacing plugins that add 50–200KB of JavaScript each. For complex functionality (payment processing, shipping calculations, email marketing integration), keep the plugin — custom code would be harder to maintain and update. Focus custom code on replacing the lightweight plugins that add disproportionate overhead.
Too many plugins slowing your store?
Get your free WooCommerce speed audit
We’ll audit every plugin on your store, identify the performance offenders, and show you exactly which to keep, replace, or remove — with guaranteed speed improvements.
