Why WordPress hammers api.wordpress.org (and your plugins' servers) on every admin page load

The admin is slow. Not the front end - the front end is cached and fine. It's wp-admin that drags, a couple of seconds on every screen, and every performance plugin you've installed swears the site is healthy. You open Query Monitor, and there it is: a request to api.wordpress.org taking three, four, five seconds. You click to the next page. There it is again. And again.

You didn't install anything that phones home that often. So what is?

It's WordPress itself, checking for updates. On every single admin page load. And it's not supposed to do that - it's supposed to check about twice a day. Something knocked the timer out, and now every click pays a 3-5 second tax that no cache plugin can see, because the thing that broke lives in a backend transient the cache was never touching.

api.wordpress.org is the famous face of this, but it's not the only server getting hammered. That same broken timer re-fires the update checks for every premium plugin and theme you run - each one hitting its own vendor's server - plus the license and telemetry pings some of them fire on the side. One dropped timestamp, and your admin turns into a phone-home storm.

I hit this on a real site a few weeks ago. Took me a while to believe what I was looking at. Here's the mechanism, why it's so hard to catch, and the module I shipped in WP Multitool 1.6.0 to make it stop.

The symptom: slow wp-admin, healthy everything else

The tell is very specific:

• The front end is fast. Homepage, posts, product pages - all quick.
• wp-admin is slow, and it's slow everywhere - dashboard, plugins screen, editing a post, doesn't matter.
• The slowness is a flat tax. Not "the DB is grinding", not "PHP is maxed". Just a consistent few seconds added to every admin request.
• Site Health is green. Redis says "connected". Your object cache reports as working.

That last point is what makes it so evil. Everything that's supposed to catch this says the site is fine.

How the update gate is supposed to work

WordPress checks api.wordpress.org for plugin, theme and core updates roughly twice a day. That "twice a day" isn't a cron schedule you can open and inspect. It's a 12-hour gate held by a single timestamp - last_checked - and that timestamp lives inside the update transients WordPress keeps for plugins, themes and core.

The idea is simple. Before WordPress phones home, it looks at that timestamp. Is it fresher than 12 hours? Then skip - nothing to do. Missing, or older than 12 hours? Do a real check: a blocking call to api.wordpress.org, right there on the page-load path, holding the request open while it waits for the answer.

So the entire system rests on one quiet assumption: that the timestamp survives from one request to the next. When it does, you get two checks a day and a fast admin. When it doesn't, you get a check on every load.

Where it breaks: an object cache that drops writes

Those update transients get stored in your object cache when you have a persistent one (Redis, Memcached). And a persistent object cache can silently drop them. Common ways I've seen it happen:

• A Redis backend that has died or is unreachable, but whose object-cache.php drop-in is still sitting in wp-content/, so WordPress keeps trying to use it.
• A cache that flushes far too aggressively - on every request, or on a timer measured in seconds.
• An orphaned object-cache.php left behind by a caching plugin you uninstalled, now pointing at nothing.

When the write doesn't persist, the timestamp is gone by the next request. WordPress reads it, finds nothing, decides a check is overdue, and makes the blocking call. Every load. That's your 3-5 second tax, firing on every admin page.

And it's invisible to your caching plugins because a page-cache plugin's entire job is the front end. This is a backend transient that was never persisting in the first place. Different layer, different problem, nothing your WP Rocket or LiteSpeed config can touch.

The cruel part: the object cache reports as healthy the whole time. Site Health is green. Redis "connected". It's just not holding these particular writes - and nothing surfaces that.

How do you know it's happening to you?

You don't have to go spelunking through your object cache to find out. If your wp-admin is slow across the board while the front end flies, and every green light says the site is fine, this is one of the first things I'd suspect.

That's exactly the kind of invisible misconfiguration WP Multitool's Site Doctor exists to catch - the problems that don't show up in Site Health because the thing reporting on them is the thing that's broken. It scans for an object-cache drop-in pointing at a backend that isn't answering, aggressive flushing, and the rest of this class, and tells you in plain language what it found. You can run a first pass free at wpmultitool.com/scan.

What the External Call Optimizer does

This is the new module I shipped in WP Multitool 1.6.0. It's a Pro module, and between its two halves it keeps every repeated external update and phone-home call in check - whatever server it's headed to, not just wordpress.org. Both halves are silent: no logging, no tables, no scan button to press. One status card, one pause toggle, that's the whole UI. You turn it on and forget it exists.

It keeps the update-check gate reliable

When your cache loses that 12-hour timestamp, the optimizer puts it back - it re-injects the freshness your cache dropped, so WordPress sees the gate is still closed and doesn't make the redundant call. And that one gate governs every update check WordPress makes - core, and every plugin and theme that registers updates the standard way, including the premium ones that check their own vendor's server. Restore the timestamp and the whole fan-out settles back to twice a day, not just the wordpress.org call. The per-click tax on wp-admin disappears.

The part I care about most is that it does this faithfully. It never invents freshness:

• It only ever restores a timestamp WordPress itself actually wrote. It doesn't make one up.
• If the real timestamp is genuinely older than 12 hours, it steps aside and lets a real check run. Update discovery never slips past the normal schedule.
• A manual "check for updates" still forces a real check.
• It never touches api.wordpress.org connectivity. Your security updates run exactly as before.

So it stops the repeat without ever delaying or hiding an update. That line was non-negotiable for me. A performance fix that could sit on a security release for an extra day is not a fix I'm willing to ship. The status card just tells you the truth: is the gate holding, is it at risk, and how many redundant checks it's prevented so far. If it's at risk and you're on a persistent object cache, it says so plainly and points you at the root cause.

It trims chatty third-party phone-homes

Update checks aren't the only things that call out on a loop. Plenty of premium plugins also ping their own license servers and telemetry endpoints on nearly every page load, outside the update system entirely, often badly cached or not cached at all. One dead license server on a long timeout can hang an admin page for many seconds at a stretch.

The optimizer watches for hosts that get hit over and over, and once one proves chatty it quietly does two things: it clamps the timeout so a slow or dead endpoint costs a couple of seconds instead of hanging the page, and it serves the last good answer for a short window so the redundant round-trip just doesn't happen. No per-host config, nothing to set up. If you want to know which plugins are the heavy phone-home offenders in the first place, I benchmark real plugin overhead over at MakeWPFast.

And the safety rails are hard-coded, not settings you can fumble:

• api.wordpress.org is never touched. It's the security lifeline - it stays protected, always.
• WP Multitool's own updater is never optimized.
• Package installs, exports and other streamed downloads bypass it entirely.
• Anything carrying cookies or an authorization header is never cached, so a per-user or authenticated response is never shared with anyone else.
• Only plain reads and successful responses are ever cached.

The honest caveat

I'm not going to pretend this module fixes the real problem, because it doesn't. The real problem is your object cache dropping writes. A dead Redis drop-in, a backend that flushes on every load - that's the disease. The runaway update checks are just the most visible symptom.

The External Call Optimizer holds the gate so the symptom stops hurting today, while you're still figuring out the cache. But it's a compensating layer, not a licence to leave a broken cache in place. A cache that's silently dropping writes is dropping a lot more than update transients - it's dropping the query and object caching you installed Redis for in the first place. You want that fixed at the source, and Site Doctor is what points you at it.

So: let the optimizer stop the pain now, and fix the cache to make it permanent. Both, in that order. The nice part is the optimizer keeps holding the line the whole time you're doing it, and quietly stands down once the cache is healthy again.

Get it

The External Call Optimizer ships in WP Multitool 1.6.0. It's a Pro module - $79/year for a single site - and it turns itself on the moment a persistent object cache starts misbehaving, keeping WordPress's whole spread of external update and phone-home calls in check: core, your premium plugins and themes, and the chatty license servers alike. If your wp-admin has been mysteriously slow and every plugin swears the site is fine, this is very likely what you're looking at.

See pricing and grab Pro →

And if you've hit this exact "slow admin, healthy front end" thing before - I'd genuinely like to hear how you tracked it down. It took me longer than I'd like to admit.

Originally published at wpmultitool.com.