Why Is My WordPress Admin So Slow? A Diagnostic Guide

Why is my WordPress admin so slow? Most slow-admin reports land in my inbox sounding the same. One wordpress.org poster put it perfectly: pages "are taking 20-30 Seconds to load any page only in /wp-admin/. The frontend of site is running smoothly without any issue."

The short answer is hiding in the question. Your homepage is cached. Your dashboard never is. Page cache hands saved HTML to logged-out visitors and steps aside the moment it sees a login cookie, so every wp-admin click runs the whole stack: PHP boots, every active plugin loads its admin code, the database answers whatever that screen asks for. A slow admin is your site's real, uncached speed, with nothing hiding it.

The causes are a short list, and you can find yours in about fifteen minutes. Here's the order I check them on client sites, cheapest test first.

Step 0: Prove it's the server, not the browser

Before touching anything, open the slow admin page, hit F12, go to the Network tab and reload. Click the first request (the HTML document) and open its Timing panel. "Waiting for server response" is your TTFB: everything the server did before the browser received a single byte.

If TTFB is fine but the editor still lags, that's a different problem (browser JS, metaboxes, autosave). This post is about server-side slowness.

Once you've confirmed it's the server, match your symptom to a starting point:

What Site Health already knows about your admin

Go to Tools → Site Health. Two of its checks are aimed straight at this problem.

"Autoloaded options could affect performance" - since WordPress 6.6, Site Health measures the total size of your autoloaded options and flags the site once it passes 800,000 bytes. If you see this warning, that's very likely your answer. Skip to the next section.

"Page cache is detected but the server response time is still slow" - people paste this exact string into Google. Two things worth knowing about it. First, the test requests your homepage three times and takes the median; under 600ms is "good" (that threshold lives in core as site_status_good_response_time_threshold, filterable if you disagree with it). Second, the message means even your cached front end is slow to produce, a bigger problem than a slow admin. If Site Health is green while wp-admin drags, don't be surprised. Site Health can only measure the public side; admin slowness is invisible to it.

Weigh your autoloaded options

Every row in wp_options has an autoload flag. Rows marked for autoload get pulled into PHP memory in a single query at the start of every request: front end, admin, admin-ajax, REST, everything. It's a good optimization for a handful of small settings. Over years of installing and removing plugins it stops being small.

Check the total (via WP-CLI, wp db query, or phpMyAdmin):

SELECT ROUND(SUM(LENGTH(option_value))/1024) AS autoload_kb,
       COUNT(*) AS rows_n
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');

Then see who the weight belongs to:

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY bytes DESC
LIMIT 10;

I ran both on a test site of mine (WP 7.1, WooCommerce, a normal plugin stack). Result: 997KB across 355 rows. The top offenders:

Yoast isn't even installed on that site anymore. It left about 445KB of autoloaded settings behind, and WordPress happily loads them on every request. The WooCommerce and Stripe entries are cached data that never needed autoload in the first place.

You'd think WordPress 6.6 fixed this. Partly. Since 6.6, an option saved without an explicit autoload flag gets stored as auto-off once it exceeds 150KB, and Site Health reports the total. But nothing is cleaned retroactively, and plugins that explicitly ask for autoload keep it, which is why my 293KB wpseo_taxonomy_meta still says on. The details are in the 6.6 dev note if you want the mechanics.

The fix: delete options left by plugins you removed, and flip autoload off for big options the site still needs but not on every request. I wrote the full procedure, including how to tell a leftover from a live option, in the autoload bloat guide. If you'd rather not run SQL by hand, the Autoloader Optimizer module in WP Multitool does this analysis and the cleanup.

Make sure your object cache is actually caching

A persistent object cache (Redis or Memcached) is the biggest admin speedup available on a query-bound site, because wp-admin runs everything uncached and every repeated lookup hits MySQL without one. If your host offers Redis, use it. One caveat worth knowing: it won't rescue a bloated autoload set. The alloptions blob still lands in PHP memory on every request, it just arrives from Redis instead of MySQL.

The catch: "Redis: Connected" in a plugin's settings page proves the socket opened. It says nothing about whether your data is being cached. I've seen Redis connected with maxmemory-policy set to noeviction: once memory fills, every write fails silently and you're paying the Redis latency for zero benefit. Or the options group sitting on the ignore list, so the one table that matters most bypasses the cache on every request.

Checks that matter: the object-cache.php drop-in actually exists in wp-content, the hit rate is healthy, there's headroom under maxmemory, and the eviction policy isn't noeviction. I wrote a whole post on this failure mode: Redis: Connected Is Not Working. WP Multitool's Site Doctor runs these checks against the live server, and it's in the Lite edition ($9 one-time), no Pro license needed.

Watch admin-ajax.php while you're doing nothing

Open wp-admin, filter the Network tab to admin-ajax, and just sit there. You'll likely see requests firing on a timer while you touch nothing.

That's the Heartbeat API. It ticks somewhere between every 15 and 120 seconds per open admin screen, depending on the screen, powering autosave, post locks and session warnings. Every tick is a POST to admin-ajax.php, and every one boots the entire WordPress stack. The official AJAX docs put it plainly: all WordPress AJAX requests must be sent to admin-ajax.php. So every AJAX call goes through one file, with a full bootstrap and no page cache.

On a solo admin session it's minor. With three editors holding post edit screens open, you get a steady stream of uncached full-boot requests competing for PHP workers with your real clicks. Throttle it to 60 seconds (Heartbeat Control is free), but keep it enabled in the editor, because that's what autosave and post locking run on.

If you see admin-ajax requests that aren't the heartbeat, repeating every few seconds with plugin-specific action names, some plugin is polling your server while you work. Worth finding out which.

Catch the plugin doing the damage

When the checks above come back clean and admin is still slow, it's usually one plugin loading something heavy on every admin screen. The tool is Query Monitor (free, by John Blackbourn). Install it, open the slow screen, and read:

• Queries by component - which plugin owns the query time. A plugin running 200 queries on a dashboard it has no business touching shows up immediately.
• HTTP API calls - external requests blocking the page render. One wordpress.org thread I keep coming back to had a 13-second wp-admin caused entirely by outbound HTTP calls: update checks, license pings, notification feeds, each taking 0.3 to 0.8s.
• Scripts and styles enqueued - plugins that load their entire UI on every admin page.

The toggle test works too (deactivate half, test, bisect), but do it on staging. I covered the full isolation method in how to find which plugin is slowing WordPress.

The api.wordpress.org tax, briefly

WordPress checks api.wordpress.org for core, plugin and theme updates roughly twice a day, gated by a last_checked timestamp inside the update transients. If your object cache drops those transients (dead Redis, aggressive flushing, an orphaned drop-in), the gate falls through and WordPress fires a blocking update check on admin page loads. I measured this and wrote it up separately: why WordPress hammers api.wordpress.org on every admin page load. If your admin is intermittently slow, fine for hours then suddenly 10 seconds, this is the first thing to suspect.

WooCommerce adds its own layer

Everything above applies double to WooCommerce admin. On top of it, WooCommerce queues background work through Action Scheduler, and the wp_actionscheduler_actions table quietly accumulates completed and failed rows. On a busy store that table can grow to hundreds of thousands of rows, and admin screens that scan the queue get slower with it. Worth a look if the Orders and Products screens are your slow ones specifically.

The order I actually run this in

1. TTFB in the Network tab - is it the server at all?
2. Site Health - autoload warning? Page-cache-but-slow warning?
3. Autoload size SQL - over ~800KB, trim it before anything else.
4. Object cache verified working - connected and actually caching.
5. admin-ajax in the Network tab - heartbeat flood or a polling plugin.
6. Query Monitor on the slowest screen - queries by component, HTTP calls.
7. Fix the thing you measured. Retest. Stop when it's fast.

Every slow admin I've fixed had one dominant cause, and it was almost never the one the site owner suspected going in. That's the argument for measuring first.

FAQ

Why is my WordPress admin slow but the website is fast?
Because the public site is served from page cache and wp-admin never is. Every admin click runs the full PHP/database/plugin stack, so the dashboard exposes your site's real backend speed.

What is a good wp-admin load time?
Core's Site Health uses 600ms median server response as its "good" threshold. For wp-admin, under a second TTFB feels normal, 1 to 3 seconds means something wants attention, and over 3 seconds means something is broken.

Does Redis object cache speed up wp-admin?
Usually, yes. wp-admin is query-heavy and uncached, so serving repeated lookups from memory helps more there than on the cached front end. Verify it's actually caching, not just connected: hit rate, memory headroom, and a sane eviction policy all matter.