Home › Fix Errors › WordPress › Plugin Slowing Site

Site used to be fast. Now it's not. Suspect a plugin.

Fix: Plugin Slowing Down Site

Find which plugin is actually the problem — with data, not guessing. Then decide: optimize, replace, or remove.

Last updated: October 2026

⚡ The 30-second fix

Install Query Monitor (free plugin). Visit a slow page. Click the Queries tab in the admin bar. Sort by "Time" descending.

The top query usually names the plugin that caused it. That's your culprit. If 5+ queries come from the same plugin, that's the one to investigate.

Step 1: Measure before you change anything

You can't optimize what you haven't measured. Establish a baseline first.

Baseline the current performance

Two free tools. Takes 2 minutes.

PageSpeed Insights — pagespeed.web.dev — measures real user metrics (Core Web Vitals)
GTmetrix — gtmetrix.com — detailed waterfall of every asset

Write down these three numbers:

LCP (Largest Contentful Paint) — should be under 2.5s
TTFB (Time To First Byte) — should be under 600ms
Total Blocking Time — should be under 200ms

Install Query Monitor

The best free tool for WordPress-specific performance analysis. It adds an admin bar menu with these tabs:

Queries — every database query, the plugin that ran it, and how long it took
Hooks — every WordPress hook fired, sorted by priority and duration
Scripts & Styles — what CSS/JS files load on this page
HTTP API — outgoing requests (external API calls)

Warning: Query Monitor significantly slows down your site while active. Deactivate it when you're not measuring.

Find the slowest queries

Visit a slow page (homepage, shop, archive). Click Query Monitor → Queries. Sort by Time descending.

Total Queries:  87
Total Query Time: 1,247ms

Slowest:
1. 480ms — SELECT * FROM wp_postmeta WHERE... (plugin: WooCommerce)
2. 210ms — SELECT * FROM wp_options WHERE... (plugin: Some Slider)
3. 156ms — SELECT * FROM wp_posts WHERE... (core)

Now you know: WooCommerce is legitimately heavy on this page. The slider plugin is being wasteful. The slider is worth investigating first — it's likely replaceable.

Step 2: Isolate the culprit plugin

If Query Monitor doesn't make it obvious, isolate by deactivating plugins in batches. This is faster than one-at-a-time.

The bisect method

Write down all active plugins
Deactivate the bottom half
Measure with PageSpeed / GTmetrix
If performance improved → the culprit is in the bottom half
If not → it's in the top half. Restore the bottom, deactivate the top.
Repeat with the smaller half until one plugin remains

# Bisect math: 32 plugins takes 5 rounds
# Round 1: 16 vs 16
# Round 2: 8 vs 8
# Round 3: 4 vs 4
# Round 4: 2 vs 2
# Round 5: identified

# vs one-at-a-time: up to 32 tests

Pro tip: Do this on staging, not production. Deactivating plugins on a live site is risky, especially if some are business-critical.

Test the specific page

Slowness often only affects one page type. Test the same URL each time so the comparison is fair.

Homepage slow but posts fast? The culprit is on the homepage.
Product pages slow but blog fast? WooCommerce or product-related plugins.
Admin slow but frontend fast? Admin-facing plugins (backup, security, SEO).
Everything slow? Likely a plugin that runs on init or wp_loaded site-wide.

Step 3: Fix the culprit

Once you know the plugin, you have four options. Try them in this order.

Check the plugin's own settings

Many plugins have built-in performance toggles. Check the plugin's settings page for options like:

"Load scripts only on plugin pages"
"Defer non-critical scripts"
"Disable on mobile"
"Lazy load" options

Example: WooCommerce has "Load cart fragments" and "Redirect to cart" settings that impact performance significantly.

Asset optimization (if you must keep the plugin)

If the plugin loads CSS/JS on every page but only needs it on one, use an asset optimization plugin to defer it:

Perfmatters — granular control over script loading (paid)
Asset CleanUp — free, dequeue specific assets per page
WP Rocket — has "Load JavaScript deferred" and file optimization (paid)
Flying Scripts — free, defers scripts until user interaction

Careful: Deferring scripts can break plugin functionality. Always test on staging first.

Object caching (for database-heavy plugins)

If the plugin runs many database queries, an object cache (Redis or Memcached) caches the results in memory.

# Check with your host — most managed WP hosts offer:
# - Redis object cache (Kinsta, WP Engine, SiteGround)
# - Memcached (older but still supported)

# Once enabled, install the Redis Object Cache plugin
# to route WordPress queries through Redis

Pro tip: Object caching typically improves database-heavy WordPress sites by 20–40%. It's the biggest win for plugin-heavy sites.

Replace the plugin (the right answer 60% of the time)

If the plugin is heavy, abandoned, or poorly written, replace it. Common culprits and their leaner alternatives:

Heavy plugin	Leaner alternative
Slider Revolution	MetaSlider, or CSS-only sliders
Jetpack (full)	Enable only the modules you use
Elementor (overused)	Native Gutenberg blocks
Yoast SEO	Rank Math, SEOPress
Wordfence (full scan)	Solid Security Basic, Patchstack

Pro tip: Before replacing a plugin, check its wordpress.org page for "Active installations" and "Last updated." If it's 100K+ active and updated within 3 months, it's likely well-maintained.

🛡️ How to avoid plugin bloat

Audit your plugins quarterly. Deactivate anything you haven't used in 3 months. Plugin count matters less than plugin quality, but bloated counts still slow admin pages.
Prefer fewer, multi-purpose plugins. One well-made plugin is better than five single-purpose ones that overlap.
Check the plugin's performance before installing. Search "[plugin name] performance" on Reddit or the WordPress subreddit. Other users have already tested it.
Monitor TTFB monthly. If TTFB grows by 100ms+ over a few months, something is slowing you down.
Enable object caching. Redis or Memcached should be on every serious WordPress site.
Consider a page cache. For read-heavy sites (blogs, marketing), full-page caching makes most plugin issues invisible to end users.

❓ Frequently asked questions

How do I find which WordPress plugin is slowing down my site?

Install Query Monitor (free) and check the Queries and Hooks tabs on a slow page. It shows which plugin triggered the most database queries and the time each took. Also test by deactivating plugins one at a time.

Do more plugins always mean a slower site?

No. A well-written plugin that only loads on the pages it's needed for adds almost no overhead. A badly-written plugin that loads everywhere and runs 200 database queries on every page load is the problem, not the count.

What is a good number of database queries per page?

Under 50 is good. 50-100 is acceptable. Over 100 usually means a plugin is being inefficient, or you're running WooCommerce or a membership plugin that legitimately needs more.

How do I know if a plugin is slow or my host is slow?

If your TTFB (Time To First Byte) is over 600ms on a mostly cached page, it's usually the host. If TTFB is fast but the full page takes 3+ seconds, plugins and theme are typically the cause.

Can I keep plugins but reduce their impact?

Sometimes. Asset optimization plugins can defer JavaScript and CSS to load them only when needed. But if a plugin runs heavy database queries on every page load, no front-end optimization will fix it. That plugin needs to be replaced or removed.