WordPress admin was loading in over 16 seconds on a production site. The server had headroom, PHP was current, no slow queries in the logs. The culprit was a plugin firing outbound HTTP calls on every single admin page load, including pages it had nothing to do with.
This is the investigation, what was found, and how it was stopped.
For a full breakdown of all common causes of slow WordPress admin, see Why Is My WordPress Admin Slow? A Technical Diagnosis Guide.
The symptom
Every WordPress admin page was slow - not just one section, not just the editor. Dashboard, posts list, settings pages. All of them. The delay was consistent: roughly 16 extra seconds added to every request, regardless of what the page was doing.
The usual suspects were ruled out quickly:
- Server load was normal
- PHP-FPM was healthy
- No slow queries in MySQL logs
- Page cache was working on the public-facing site
The problem was only in the admin.
Finding it with Query Monitor
Query Monitor was installed temporarily. Its HTTP API calls panel showed something immediate: 28 out of 31 outbound HTTP calls on a typical admin page were coming from a single plugin.
Modern Events Calendar (MEC) by Webnus was responsible for:
- 28 out of 31 HTTP calls (over 90%) on every admin page load
- 16 seconds of additional load time (over 95% of total load time)
- Calls hitting remote Webnus endpoints on every page, not just MEC-specific admin screens
The calls were license verification and addon API checks. They were not cached. They were not batched. They ran on every admin request whether MEC's screens were being used or not.
Why this happens
Plugin vendors commonly implement license verification by calling a remote endpoint to confirm the license on each load. Done correctly, that result is cached locally for hours or days. Done poorly, it fires on every request, blocking the admin until the remote endpoint responds.
In this case, the timeout was long enough that every admin page waited for Webnus servers before it could finish loading. On a fast connection to a responsive vendor server this might add milliseconds. On a server where the outbound call had to traverse further network hops, it added 16 seconds.
Mitigation
The correct fix is for the plugin vendor to cache the verification result. The vendor was contacted. While waiting, and after confirming license verification had already succeeded, outbound calls to the Webnus verification endpoints were blocked at the host level:
http://webnus.biz/webnus.net/plugin-api/verifyhttp://webnus.biz/webnus.net/addons-api/verify
See Block outgoing URL calls with iptables for the exact iptables approach used to stop the calls without touching plugin code.
Result
Admin load time dropped from 16+ seconds to under 1 second after blocking the outbound calls. No plugin functionality was lost - the plugin continued to work normally because the license verification calls were redundant once verification had already completed.
What to check before blaming hosting
If your WordPress admin is slow and server resources look fine, check outbound HTTP calls first. Query Monitor's HTTP API panel takes minutes to install and immediately shows you which plugin is responsible and how many calls it is making. Most hosting companies cannot help with this because the problem is in the application layer, not the infrastructure.
The diagnostic steps for this and other causes of slow WordPress admin are covered in Why Is My WordPress Admin Slow? A Technical Diagnosis Guide.
Had a similar experience?
If plugin performance or WordPress admin latency is affecting your site, this is the kind of issue I diagnose and resolve through SwissWebsites.com.
Related work
This performance diagnosis note supports Scaling and load-balancing architecture and editorial platform work in Multilingual news platform.