Slow WordPress admin is often blamed on hosting, but plugin behavior is a common root cause. In particular, unnecessary outbound API calls from active plugins can add seconds of latency on every admin request.

For production WordPress performance work, focus on evidence first: request timing, plugin behavior, outbound calls, object cache, cron, and server limits.

Before chasing a single plugin, review the baseline improvements that affect both security and performance.

Baseline improvements

  • Reduce active plugins
    • Remove plugins used rarely. They remain available in the plugin directory when needed again.
    • Fewer plugins means less code to load, fewer conflicts, and less background work.
  • Update the LAMP/LEMP stack (when you control the server)
    • Take a snapshot or backup first.
    • Review available updates with yum update or apt update && apt upgrade.
    • Prioritize PHP, Apache/Nginx, and MySQL/MariaDB, then apply other updates in stages.
  • Upgrade PHP
    • If you are still on PHP 5.x, plan a supported PHP version migration.
  • Separate the database layer
    • Databases are memory-intensive and can affect security, performance, and availability.
    • A managed database service can reduce operational overhead and simplify HA.

Diagnostic workflow

Start with evidence. Slow admin pages can come from PHP execution, database queries, remote HTTP calls, object-cache misses, cron behavior, or browser-side assets.

1. Measure the slow request

Use browser DevTools or server logs to identify whether the delay is:

  • initial HTML response time
  • AJAX calls such as admin-ajax.php
  • REST API calls
  • static assets
  • third-party scripts

If the HTML response is slow, the bottleneck is usually PHP, database, object cache, or outbound HTTP. If the page renders quickly but later becomes sluggish, inspect JavaScript and AJAX calls.

2. Install Query Monitor temporarily

Query Monitor is useful during diagnosis because it shows:

  • slow database queries
  • duplicate queries
  • remote HTTP calls
  • PHP errors and hooks
  • scripts and styles loaded by each plugin

Disable it after the investigation if you do not need it continuously.

3. Check outbound HTTP calls

Remote calls from plugins can block admin requests while waiting for license checks, update checks, analytics, or API responses.

Look for:

  • repeated calls to the same vendor endpoint
  • long timeout values
  • calls made on every admin page load
  • license verification that should be cached but is not

Prefer fixing plugin behavior, disabling the feature, or asking the vendor for a patch. Host-level blocking is a last resort.

4. Check WordPress Heartbeat

The Heartbeat API can generate frequent admin-ajax.php requests, especially with many open admin tabs or editors.

Use a Heartbeat control plugin or custom code to reduce frequency where appropriate. Do not disable it blindly: post locks, autosaves, and some plugins rely on it.

5. Audit autoloaded options

Large autoloaded options can slow every WordPress request.

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Investigate unusually large rows before deleting anything. Options often belong to plugins, themes, or page builders.

6. Review object cache and cron

For busy or database-heavy sites, Redis or another persistent object cache can reduce repeated database work. For low-traffic sites, WP-Cron can also create uneven admin latency when scheduled jobs run during a request.

For production sites, consider disabling request-driven cron and using real cron:

define('DISABLE_WP_CRON', true);

Then schedule:

*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Plugin inefficiency

Poorly written plugins are a less obvious but frequent cause of admin slowness. You may need a plugin for specific functionality, but not all WordPress plugins are built with production efficiency in mind.

In one case, Modern Events Calendar (MEC) by Webnus was the bottleneck. Using Query Monitor, I found the plugin was responsible for:

  • slow loading in parts of the WordPress admin
  • 28 out of 31 HTTP calls (over 90%)
  • an average of 16s additional load time (over 95% of total load time)

MEC HTTP Calls

Mitigation

The plugin could batch or cache its verification calls instead of hitting remote endpoints on every admin request. After license verification was already complete, I blocked outbound calls to:

  • http://webnus.biz/webnus.net/plugin-api/verify
  • http://webnus.biz/webnus.net/addons-api/verify

See Block outgoing URL calls with iptables for the host-level control I used to stop the calls.

Verification after mitigation

After making changes, re-test the same admin page and compare:

  • total response time
  • number of database queries
  • number and duration of remote HTTP calls
  • admin-ajax.php frequency
  • PHP error logs
  • server CPU, memory, and database load

The goal is not just a faster page once. The fix should remain stable across plugin updates, cache flushes, and ordinary admin usage.

Related work

This performance diagnosis note supports Scaling and load-balancing architecture and editorial platform work in Multilingual news platform.