Performance / Jul 9, 2026 / 4 min read / By Marcin Dudek

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

A broken object cache makes WordPress fire blocking update checks - to api.wordpress.org and your premium plugins' servers - on every admin page load. Here is the fix.

Short version: if your WordPress dashboard is slow but the public site is fast, WordPress is probably re-checking for updates on every single admin click instead of twice a day. It happens when a broken object cache keeps losing the timer that's meant to hold those checks back. Each check is a blocking call to an outside server, so every screen hangs for a few seconds. Speed plugins never catch it, because it's a backend problem. WP Multitool's External Call Optimizer (Pro) stops the repeat checks immediately. Here's the whole thing in plain terms.

A WordPress dashboard firing a storm of repeated outbound update, license and telemetry calls to many external servers.
Every admin page load fans out into a storm of blocking calls to outside servers. That's the tax the External Call Optimizer removes.

The symptom: a slow dashboard, and nothing else

You know this one if you've lived it:

  • The public site is fast. Homepage, posts, product pages - all quick.
  • wp-admin drags. Every screen takes a few seconds - the dashboard, the plugins list, editing a post, all of it.
  • Every speed plugin you've got swears the site is healthy. Site Health is green. Redis says "connected."

That last point is the maddening part: everything that's supposed to catch a problem tells you there isn't one. If this is your life right now, it's worth reading why your WordPress admin is slow - this update-check trap is one of the most common causes, and one of the hardest to spot.

The hidden cause: WordPress phoning home on every click

WordPress constantly checks outside servers for updates - wordpress.org for core, and every premium plugin and theme checks its own vendor's server too, plus the license and telemetry pings some of them fire on the side. That's normal. It's supposed to happen about twice a day, held back by a simple 12-hour timer.

Here's the catch. That timer lives in your site's cache. When the cache is broken or misconfigured, it keeps losing the timer. WordPress looks for it, can't find it, assumes a check is overdue, and fires off all those external calls again - right now, holding your page open while it waits for the answers. Do that on every admin page load and you get the multi-second hang.

And because it all happens on the backend, your caching plugins can't see it. Their entire job is the public-facing pages. This is a different layer of the site entirely - nothing your WP Rocket or LiteSpeed setup can touch.

A tail of wp-content/debug.log showing seven consecutive blocking phone-home requests, one per admin page load, fanning out beyond api.wordpress.org to premium plugin, theme, license and telemetry servers - each taking 2.9 to 5.1 seconds.
One blocking external call per admin page load, spread across core, premium plugins, themes, license and telemetry servers. That's every click paying the tax.

The fix: the External Call Optimizer stops the repeat

This is a Pro module I shipped in WP Multitool 1.6.0, and its job is exactly this problem. It keeps that 12-hour timer reliable by stashing a copy somewhere the broken cache can't lose it - a permanent spot in your database. So even when the cache drops the timer, WordPress still finds it, sees the check isn't due yet, and skips the redundant calls. The checks fall back to about twice a day, and the per-click hang on your dashboard disappears.

It's careful about it. It only ever restores a timer WordPress itself actually set, never one older than 12 hours, so real updates are never delayed or hidden. Security releases run exactly as before. It also quietly trims the repeated license and telemetry pings from chatty plugins, so a slow or dead endpoint can't hang an admin page. And it's silent - one status card, one toggle. You switch it on and forget it exists.

It covers the whole spread of these calls: WordPress core, your premium plugins and themes, and the chatty third-party servers alike. api.wordpress.org itself is always protected - it's your security lifeline, so the optimizer never gets in its way.

The honest part: this is a safety net, not a cure

The optimizer stops the pain today, but it's not fixing the real problem - and I won't pretend otherwise. The real culprit is the broken object cache underneath, dropping writes it should be keeping. That cache is dropping a lot more than an update timer; it's dropping the query and object caching you installed Redis for in the first place. You want that fixed at the source.

That's what WP Multitool's Site Doctor is for - it finds the misconfigurations Site Health misses, precisely because the thing reporting "all healthy" is the thing that's broken. It spots a dead cache backend, an orphaned cache file, over-aggressive flushing, and tells you in plain language what it found. You can run a first pass free at wpmultitool.com/scan.

So: let the optimizer stop the hang now, and fix the cache to make it permanent - in that order. The optimizer holds the line the whole time you're sorting the cache out, and quietly stands down once it's healthy again. (If you're curious which plugins are the worst phone-home offenders to begin with, I benchmark real plugin overhead over at MakeWPFast.)

Get it

The External Call Optimizer ships in WP Multitool 1.6.0 as a Pro module - $79/year for a single site. If your wp-admin has been mysteriously slow while every plugin swears the site is fine, this is very likely what you're looking at. Start with the slow WordPress admin guide if you want the full picture first.

See pricing and grab Pro →

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

Find what is slowing your WordPress

WP Multitool - 19 modules, from $79/year, zero bloat.

Get WP Multitool

Built by Marcin Dudek.