WordPress Performance: Finding and fixing slow plugins

How to find slow WordPress plugins, measure their impact, load features only where they're used and remove unused scripts without breaking anything.

Updated 5 min read

A slow plugin is usually doing work it doesn’t need to: extra queries, heavy admin screens, large front-end files, or features that run on every request when only one template needs them. Measure which plugin costs the most, then remove it, replace it or load it only where it’s used.

This guide shows how to measure each plugin’s cost and fix the most common problems.

Measure, then narrow it down

Before you delete anything, answer three questions:

  • Which plugin adds the most time to the request?
  • Is the time spent in PHP, the database, remote HTTP calls, or front-end assets?
  • Is the cost on every page, or only specific routes?

The answers usually point to the fix.

1. Identify heavy plugins

Tools

  • Query Monitor: queries, hooks, HTTP calls, enqueued assets, and timing.
  • New Relic APM: time spent in functions, external requests, and database.
  • WP Hive (plugin testing and repo insights): useful for pre-install research rather than profiling your live site.

What to check

  • database queries introduced and duplicated
  • slow remote calls via the WordPress HTTP API
  • memory footprint and peak memory
  • scripts and styles enqueued site-wide
  • scheduled tasks that run too often

Tip: test the same page type repeatedly (home, post, archive, product) so your comparisons are fair.

2. Remove or replace slow plugins

Look for:

  • plugins that haven’t kept up with current WordPress and PHP
  • “all-in-one” plugins that overlap with existing tools
  • plugins you installed for a one-off task years ago
  • plugins that add multiple front-end libraries for small UI features

When you replace them, it often works best to:

  • keep one trusted plugin for a job
  • remove the rest
  • cover gaps with a small custom mu-plugin

A note on lighter alternatives

Treat a lighter alternative as a claim to test. What matters is how the plugin behaves on your site, with your theme, data and traffic.

3. Conditionally load plugin features

Much of the weight comes from plugins that load their files on every page.

Remove front-end files a page doesn’t use

function psy_dequeue_unused_assets(): void {
    if ( ! is_singular( 'product' ) ) {
        wp_dequeue_script( 'some-plugin-script' );
        wp_dequeue_style( 'some-plugin-style' );
    }
}
add_action( 'wp_enqueue_scripts', 'psy_dequeue_unused_assets', 100 );

Run this late (100) so you dequeue after the plugin enqueues.

Switch off heavy behaviour where it isn’t needed

If a plugin adds front-end behaviour via hooks, remove it as early as you can tell which page is loading, which is often the wp action.

add_action( 'wp', function () {
    if ( ! is_page( 'contact' ) ) {
        remove_action( 'wp_footer', 'plugin_injects_widget' );
    }
}, 20 );

That’s simpler and safer than stripping its HTML out afterwards.

4. Profile remote calls

Some plugins call:

  • marketing APIs
  • licence servers
  • font providers
  • CRM endpoints
  • analytics endpoints

If those calls are synchronous, they can add seconds to TTFB.

Fixes:

  • cache responses using transients
  • defer calls to wp_cron (or a real cron) where appropriate
  • make failed calls time out quickly
  • avoid calling remote endpoints on every page load

5. Use mu-plugins for performance controls

A must-use plugin (mu-plugin) is a good home for performance rules. It:

  • loads before normal plugins
  • cannot be deactivated accidentally in the UI
  • gives you a central place for dequeue and remove_action rules

Common mu-plugin tasks:

  • dequeue assets by route
  • disable features by environment (staging vs production)
  • tighten cron schedules
  • add safe caching wrappers around expensive operations

6. Plugins that overlap

The most common overlaps:

  • multiple SEO plugins or overlapping SEO features
  • multiple forms plugins or embedded scripts for the same forms
  • multiple analytics plugins plus manual tracking snippets
  • multiple font loaders
  • multiple security plugins all doing scans and firewall rules

Pick one tool per job unless you have a clear reason not to.

7. When to write a custom plugin instead

If you only need 10 percent of a plugin, and it brings with it:

  • heavy admin UI
  • a front-end framework
  • multiple remote calls
  • constant database writes

a small custom plugin is often the better long-term choice.

A good custom plugin:

  • is namespaced or prefixed
  • uses hooks rather than template hacks
  • loads only on the routes that need it
  • ships with sensible defaults and clear docs

FAQ

Does the number of plugins matter?

Not by itself. One well-written plugin can cost less than three small ones, and one bad plugin can outweigh all the rest. Measure what each one costs.

Should I use legacy profiling plugins like P3?

No. P3 (Plugin Performance Profiler) hasn’t been maintained for years. Query Monitor and an APM such as New Relic give you better, current data.

What is the safest first optimisation?

Dequeuing a plugin’s scripts and styles on pages that don’t use it. You can see and measure the result, and the risk is low once it’s tested.

When I take on a WordPress site someone else built, its plugin list is the first thing I check, before I suggest what WordPress maintenance cover it needs.

Published , updated .

Part 4 of WordPress Performance.

Related posts