Skip to content

How to Find Which WordPress Plugin Is Slowing Down Your Site

Find the WordPress slower with baseline, Query Monitor, log, HTTP call and controlled testing in staging; without breaking the live site.

Author Bipida Editorial Team Published
Share this article

A large number of plugins does not necessarily slow down the site, and a small number does not guarantee speed. A plugin may sound on any external API request, run an indexless query, or just be heavy in checkout. The goal is to convert suspicious increment to validated factor in a specific scenario.

Quick answer:First, enter the URL or operation and enter the baseline metric. Make a clone or staging copy, keep the cache the same in each test, and isolate controlled plugins. Then use Query Monitor, PHP slowlog, or APM to determine which plugin is spending time on hook, query, or HTTP call.

Before you disable, define the scenario.

  • Opening the product page for an unknown user
  • Add to the box and check out.
  • Save the product in wp-admin
  • Search or filter.
  • Running cron, import or webhook

A plugin may not change the homepage but it does save the order. Each test must keep the URL, login status, input data, hit/miss cache, and runtime constant.

Why don't we turn off all the plugins on production?

This can stop payment, security, forms, SEO and background jobs, and simultaneously clear the cache, resulting in contaminated comparison data. Use a new clone of the database and files to protect sensitive information in the test environment. If staging is connected to real services, secure email, payment, and webhook.

The way to group and halve.

  1. Specify the necessary add-ons for the test path.
  2. Divide the rest into two groups in staging.
  3. Run a group inactively and repeat the same scenario.
  4. If the delay is resolved, the factor is in the inactive group; otherwise, check the active group.
  5. Repeat the division to get to a few limited options.
  6. Confirm the final plug-in to be active/inactive and to have an effect.

This is faster than the test of a single tensor, but the dependence between the addons can change the result.The WordPress plugin interference guideSee also.

What does Query Monitor show?

In a controlled environment, it can display slow or repetitive queries, caller, hooks, HTTP API call and errors. The number of queries alone is not a metric; duration, frequency, and rows involved are important. An external request with a five-second timeout may have more impact than a hundred small queries.

Query Monitor has its own overhead and displays technical information; limit its access and disable it after the production test. If the query is just under load, the profiler is not a single request and requires APM or controlled load test.

Additional signals in log and network

In DevTools, see initiator and endpoint request. In PHP log and stack trace, the first path belowwp-content/pluginsIt's a clue, but the last file doesn't necessarily have to be root cause. Match the timestamp request with the access log and PHP-FPM slowlog.

For preview, separate the admin-ajax and REST requests.The slowdown wp-adminIt explains the specific directions of management.

HTTP calls from outside

License check, font, statistics, CRM, text or security service may respond or have an uncertain DNS. Record host, timeout and fallback behavior. Disabling TLS verification or hard-coding IP is not a secure and stable solution.

Query and database

A plugin that stores a lot of meta or plays unlimited on each query page can be a bottleneck. Check the slow query log and plan.

Cron and background operations

Some plugins only take up CPU cron when running. Check the hook name, interval, duration, and overlap. Disabling the plugin may leave recorded events; otherwise, deleting the event may stop the necessary work.

How does the cache distort the result?

The first request after the purge is not the same as the hot request. Record the runtime and cache status for each variant. If the plugin is only active for the logged-in user, the anonymous test will not show anything. The page cache may also completely remove the plugin code and hide the backend.

What if the add-on was to blame?

  1. Document the replica, adjustment and reproducible scenario.
  2. Check the changelog and issues of the same version.
  3. Adjust the unnecessary function or frequency job by setting the official setting.
  4. Test the modified version in staging.
  5. If you replace it, measure the data compatibility and migration.
  6. Measure before and after with the same baseline.

Direct editing of the add-on file will be deleted with the next update. The patch must be maintainable or upstream. Rollback is not just a file replacement if database migration is performed.

Common Mistakes

  • Judging by reputation or number of plugins.
  • Testing different pages before and after.
  • Ignoring the cold and warm cache
  • Remove plugins and tables without backup
  • Activating the profiler on the production.
  • Guilty of knowing the last caller without seeing the full stack.

When is a specialist examination necessary?

If a slowdown occurs just below concurrency, at checkout or in alternate jobs, a simple manual test is not enough.WordPress speed boost serviceIt can attribute request, hook, query and resource consumption to specific plugins and provide a correction metric.

Common Questions

Does the passive plugin slow down the site?

The passive add-on code is usually not executed, but cron, data, drop-in or remaining settings should be checked separately.

Does the Query Monitor slow down?

It has an overhead; its use and access are limited for controlled detection.

Is removing and reinstalling the plug-in enough?

If the query, data, or settings are left behind, no. First, specify the scenario and the cause.

Why Does WordPress Use So Much RAM? From Linux Cache to PHP-FPM and MySQL
Divide the RAM usage of WordPress between Linux, PHP-FPM, MySQL, Redis, and job caches and measure the capacity and cause of memory growth before OOM.