WordPress Admin Dashboard Slow: Fix a Sluggish wp-admin (2026)

Key facts at a glance

WordPress admin speed in 2026

Last updated June 30, 2026

Why the front-end fix does not help: Page caching serves visitors finished HTML, but the admin is never page-cached. Every wp-admin click runs the full stack: all autoloaded options, the page queries, every plugin, and background requests.
The signature cause: Autoloaded options bloat. Rows in wp_options marked to load on every request, often left behind by removed plugins. WordPress 6.6 flags the total in Site Health once it passes 800KB.
The highest-leverage fix: A persistent object cache, Redis or Memcached. It serves repeated queries from memory instead of the database, which is exactly what the query-heavy, uncached admin needs.
The editor and multi-user culprit: The Heartbeat API posts to admin-ajax.php as often as every 15 seconds. Uncacheable, one PHP worker each. Many editors saturate the server. Throttle it, do not disable it.
Diagnose with two free tools: Site Health for the structural issues, autoload size, missing object cache, old PHP, low memory. Query Monitor for the slow query or heavy plugin on the exact admin screen.
The rest of the usual suspects: Database bloat from revisions, expired transients, and spam, WP-Cron running tasks on page loads, a low admin memory limit, an old PHP version, and a heavy plugin on every screen.

Source: the WordPress core notes on autoload changes in 6.6, the wp-config.php and Heartbeat API and Transients documentation, the Query Monitor plugin, and our hands-on admin speed work. Get a quote in 60 seconds →

Why the admin is slow when the front end is fast

The first thing to understand is that your public site and your admin are served in completely different ways, so making one fast does nothing for the other. Your front end is almost certainly cached. A page cache, from a plugin or your host, stores the finished HTML of each page and hands it to logged-out visitors directly, skipping most of the PHP and nearly all of the database. That is why a homepage can load in a fraction of a second. The admin cannot work like that. Every wp-admin screen is personal to a logged-in user and changes constantly, so it is deliberately never page-cached. It is generated fresh on every click.

Generated fresh means real work every time. On each admin request WordPress loads all of the autoloaded options into memory, runs the database queries the screen needs, boots every active plugin and lets each one run its admin code, and answers background requests like the Heartbeat. None of that is cached away the way the front end is. So the admin exposes every inefficiency the page cache was hiding: the options table that grew too big, the database that was never cleaned, the plugin that runs an expensive query on every screen, the missing object cache that would have kept results in memory. A slow admin is the site showing you its real, uncached cost.

The upside is that these causes are specific and mostly mechanical to fix, and they are different from the Core Web Vitals work that speeds the public pages. If your front end is also slow, that is a separate job covered on the speed optimization hub and the mobile speed fix. This page is about the backend, the part only you and your team feel, and it starts with the cause that catches the most sites.

The autoload problem and WordPress 6.6

This is the cause worth understanding in detail, because it is the most common and the most fixable. WordPress stores site settings in the wp_options table, and each row has an autoload flag. An autoloaded option is loaded automatically into memory at the very start of every request, admin and front end alike, in one query, so that common settings are ready without a separate lookup. For a handful of small options that is an optimization. The trouble is what happens over years of installing and removing plugins.

Plugins store their data in autoloaded options, and a great many of them do not clean up when you deactivate or delete them, so the data stays, still marked to autoload, doing nothing but adding weight. Some plugins also store large blobs there, caches, logs, serialized settings, that were never meant to load on every page. Multiply that across a site that has tried a dozen plugins over the years and the autoloaded total can reach several megabytes, all of which WordPress reads from the database and unserializes into memory on every single admin click. That is pure, repeated overhead, and it is invisible until you measure it.

What WordPress 6.6 changed, and what it did not

WordPress 6.6, released in 2024, took the autoload problem seriously. It added a Site Health check that flags the total size of your autoloaded options as a performance concern once it passes 800KB, so the problem now surfaces on its own. It also stopped autoloading any single option larger than 150KB by default, on the reasoning that a value that big almost never needs to load on every request, and that threshold is adjustable through the wp_max_autoloaded_option_size filter.

The important caveat is that there is no cleanup of existing data. WordPress 6.6 changed the defaults for new options going forward, but it does not retroactively turn off autoload on the bloat already in your table. Old options keep their original setting, so legacy bloat from plugins you removed years ago is still there and still loading until you clean it by hand. That is why measuring and trimming autoload remains a manual win, covered in the fix section below.

In short: the autoloaded options total is the first number to check on a slow admin, the 6.6 Site Health check makes it easy to see, and trimming it, especially the orphaned options left by removed plugins, is often the single biggest improvement you can make.

Which symptom matches yours

Find the row that matches what you see. Each one points to a specific cause and fix.

Symptom	Most likely root cause
Every wp-admin page takes several seconds while the public site is fast	A backend problem the front-end cache hides. Usually autoloaded options bloat, no persistent object cache, and a bloated database. Start with Site Health.
The post editor is especially laggy and saving feels slow	The Heartbeat API polling admin-ajax for autosave and post locking, plus heavy meta boxes. Throttle the Heartbeat to 60 seconds and profile the editor plugins.
The admin is only slow when several people are logged in at once	Heartbeat requests from many open editors saturating the PHP workers. Throttle the Heartbeat, add an object cache, and raise worker capacity.
Site Health warns that autoloaded options could affect performance	Your autoloaded total has passed the 800KB flag added in WordPress 6.6, often from plugins you removed. Find the biggest autoloaded options and turn off the ones that do not need it.
The admin is slow and the server CPU is high even with no visitors	WP-Cron running a backlog of scheduled tasks on page loads. Disable the on-load behavior and run WP-Cron from a real server cron instead.
One specific screen, like the plugins list or a plugin dashboard, is slow	A single heavy plugin running an expensive query or job on that screen. Query Monitor will name it, then tame or replace it.

The six backend causes

A slow wp-admin is almost always a mix of these six, in roughly this order of how often they are the main offender.

1. Autoloaded options bloat

The most common cause, covered in detail above. Megabytes of autoloaded data in wp_options, much of it orphaned by removed plugins, loaded into memory on every admin request. Measure the total, find the biggest options, and turn off autoload on the ones that do not need it.

2. No persistent object cache

The biggest single speedup on most query-heavy admins. Without a persistent object cache, WordPress rebuilds query results from the database on every uncached admin request. A Redis or Memcached object cache keeps those results in memory between requests, which the admin benefits from more than almost anything else. Covered in its own section below.

3. The Heartbeat API overloading admin-ajax

The cause behind a laggy editor and an admin that slows down when several people are working. The Heartbeat posts to admin-ajax.php as often as every 15 seconds for autosave and post locking, and each request is uncacheable and needs a PHP worker. Throttle it to 60 seconds and disable it where it is not needed, without turning it off entirely.

4. Database bloat

Years of post revisions, auto-drafts, trashed posts, spam and trashed comments, expired transients, and orphaned metadata make every query the admin runs slower. Limiting revisions, clearing expired transients, deleting spam, and optimizing the tables trims the database back down so the admin queries are fast again.

5. WP-Cron running on page loads

WordPress runs scheduled tasks by checking on page loads, so on a quieter site a backlog of jobs, backups, feeds, plugin housekeeping, can land on a single request and hang it, which feels like a slow admin and can spike CPU with no visitors. Disable the on-load behavior and run WP-Cron from a real server cron instead.

6. Low memory, old PHP, or one heavy plugin

The admin runs with a higher memory limit than the front end, WP_MAX_MEMORY_LIMIT, which defaults to 256MB, and a heavy site can hit it. An outdated PHP version is slower across the board. And a single plugin running an expensive query or job on every admin screen can be the whole problem. Raise memory, update PHP after testing, and profile the heavy plugin with Query Monitor. A low memory limit also shows up as the memory exhausted error.

The highest-leverage fix

If you do only one thing for a slow admin on a real, query-heavy site, add a persistent object cache. It is worth a section of its own because it is the fix people most often miss, since it is easy to confuse with the page caching that does not help here.

Page caching, what speeds the front end

Stores the finished HTML of a page for logged-out visitors. Speeds the public site, does nothing for the logged-in admin, which is never page-cached.

Object caching, what speeds the admin

Stores the results of database queries and computed data in memory, Redis or Memcached, so the admin does not rebuild them from the database on every uncached request.

By default WordPress has only a non-persistent object cache, which lasts for a single request and is thrown away at the end, so the same lookups are repeated from scratch on the next click. A persistent object cache keeps them in memory across requests. On the admin, which runs uncached and is full of repeated metadata and option lookups, the effect is dramatic, often turning a multi-second screen into a near-instant one. It also makes non-autoloaded transients fast, since with a persistent cache they live in memory instead of the database.

How to add one

Your host needs Redis or Memcached available, which most good hosts offer. Then a drop-in connects WordPress to it, usually installed by a plugin such as the Redis Object Cache plugin, which adds the object-cache.php drop-in and manages the connection. WordPress Site Health will tell you whether a persistent object cache is in use and will recommend one once your site is large enough to benefit.

DIY vs hand it off

Reading Site Health and throttling the Heartbeat is reasonable to do yourself. Editing the database, installing an object cache, and chasing a heavy plugin is where handing it off saves time and risk. If the left column matches you can likely do this. If the right column matches, get help.

✓

Realistic on your own

✓You can read Tools then Site Health and act on the warnings
✓You can install a Heartbeat control plugin and set a 60-second interval
✓You can install a reputable database cleanup plugin and run it
✓Your host has a one-click Redis or object cache toggle
✓You can add a constant to wp-config for memory or WP-Cron
✓The slow screen points clearly at one plugin you can replace

✗

Hand it off, save the time

✗Editing wp_options autoload values directly makes you nervous
✗Site Health flags autoload but you cannot tell which options are safe to trim
✗Your host has Redis but it needs configuring, not just a toggle
✗Query Monitor shows a slow query and you cannot tell which plugin owns it
✗The admin is slow for a whole team and downtime is costly
✗You want it diagnosed and fixed in order of impact, without trial and error

How to diagnose it

Work in this order. The first two steps surface most slow-admin causes with no guessing.

Open Site Health

Go to Tools then Site Health then Info and Status. It flags the structural causes: an oversized autoloaded options total, no persistent object cache, an outdated PHP version, and a low memory limit. Note every warning before changing anything.

Measure the autoloaded options total

Either from the Site Health autoload check, or with a SQL query in phpMyAdmin that sums the size of all autoloaded options. Several megabytes is a clear problem; under 800KB is fine.

Install Query Monitor and load a slow screen

The Query Monitor plugin adds a toolbar showing the slowest database queries, the time each plugin used, and the expensive hooks, for the exact admin page you are on. It usually names the culprit directly.

Watch the network tab for admin-ajax

Open the browser developer tools network tab in the post editor and look for repeated POSTs to admin-ajax.php with the heartbeat action. Frequent ones point at the Heartbeat as the editor and multi-user cause.

Check for a WP-Cron backlog

If the admin is slow and CPU is high with no visitors, look at scheduled events. A long queue of overdue tasks running on page loads is a sign to move WP-Cron to a real server cron.

Confirm PHP version and admin memory

Site Health shows both. An old PHP version or an admin memory limit being hit are quick ceilings to remove before deeper work.

How to fix it

Each branch stands alone. Back up the database before any SQL, and use your real table prefix in place of wp_.

Trim the autoloaded options

First measure the total and find the biggest offenders. These queries cover the old yes and the WordPress 6.6 on and auto values.

-- Total autoloaded size in KB
SELECT ROUND(SUM(LENGTH(option_value))/1024) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');

-- The 20 biggest autoloaded options
SELECT option_name, ROUND(LENGTH(option_value)/1024) AS kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

For a large option that does not need to load every request, turn off autoload. With WP-CLI you can flip the flag, and orphaned options from removed plugins can be deleted.

# Turn off autoload for an option (WP-CLI)
wp option set my_big_option "$(wp option get my_big_option)" --autoload=no

# Delete an option left behind by a removed plugin
wp option delete orphaned_plugin_data

On WordPress 6.6 and later, the canonical way to flip autoload without changing the value is wp_set_option_autoload_values(). Identify orphaned options carefully, and back up first.

Add a persistent object cache

If your host offers Redis or Memcached, connect WordPress to it with an object cache plugin that installs the drop-in. This is usually the biggest single admin speedup.

1. Enable Redis or Memcached in your host control panel
2. Install the Redis Object Cache plugin (or your host's)
3. Click Enable Object Cache, which adds wp-content/object-cache.php
4. Confirm in Tools -> Site Health that a persistent object cache is in use

Throttle the Heartbeat API

Slow the Heartbeat to 60 seconds rather than disabling it, so autosave and post locking still work. A small snippet in a must-use plugin does it, or the Heartbeat Control plugin.

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 60; // seconds, max 120
    return $settings;
} );

// Optional: stop the Heartbeat on the front end, where it is rarely needed
add_action( 'init', function () {
    wp_deregister_script( 'heartbeat' );
}, 1 );

Clean the database and fix WP-Cron

Cap revisions, clear expired transients and spam, and move WP-Cron off page loads onto a real server cron so scheduled tasks never block an admin click.

// In wp-config.php
define( 'WP_POST_REVISIONS', 5 );      // cap stored revisions
define( 'WP_MEMORY_LIMIT', '256M' );   // front end
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // admin
define( 'DISABLE_WP_CRON', true );     // stop running cron on page loads

# Then add a real server cron every few minutes
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Clear expired transients and optimize the tables with WP-CLI or a reputable cleanup plugin, after a backup.

wp transient delete --expired
wp db optimize

Not sure which cause is yours, or nervous about editing wp_options and the database?

Let us speed up your admin in 2 hours →

A real slow-admin session

A composite from the admin speed work we do most weeks, with identifying details removed.

Scenario

A multi-author publication had a front end that loaded fast for readers but a wp-admin that took six to eight seconds a page, worse in the editor, and the team had started writing in a separate app and pasting in because the editor was painful. The site had been running for years and had been through many plugins.

Diagnosis

Site Health flagged about four megabytes of autoloaded options, most of it traced to three plugins that had been deleted long ago but left their data behind, still autoloading on every request. There was no persistent object cache despite the host offering Redis, and with five editors working at once the Heartbeat was generating a constant stream of admin-ajax.php requests that the PHP workers struggled to keep up with.

Resolution

We removed the orphaned autoloaded options, bringing the autoload total under 500KB, enabled the host Redis with an object cache drop-in, and throttled the Heartbeat to 60 seconds while disabling it on screens that did not need it. We also capped revisions and cleared a large backlog of expired transients. The admin dropped to under a second a page and the editor became usable again, so the team went back to writing in WordPress.

⏱

Total elapsed

Admin responsive again inside the 2-hour window, once autoload, object cache, and the Heartbeat were all addressed.

When to stop and hand it off

Reading Site Health and slowing the Heartbeat is a fine self-fix. Hand it off when the work moves into the database. First, Site Health flags autoloaded options but you cannot safely tell which are orphaned and which a live plugin still needs. Second, your host has Redis but it needs configuring rather than a one-click toggle. Third, Query Monitor shows a slow query and you cannot trace it to the plugin that owns it. Fourth, the admin is slow for a whole team and the lost time is adding up. We diagnose with Site Health and Query Monitor, then fix in order of impact, trim autoload safely, add and verify an object cache, throttle the Heartbeat, clean the database, move WP-Cron to a real cron, and raise the limits that are holding you back, all reversible and none touching your content. Flat $49 to $149, done in two hours when scope fits, money back if we cannot improve your measured admin speed.

Get a quote in 60 seconds

Slow WordPress admin FAQ

Why is my WordPress admin slow when the front end of my site is fast?

Because they are two different systems with different bottlenecks, and the thing that makes the front end fast does not touch the admin. Your public pages are almost always served from a page cache, which hands visitors finished HTML without running much PHP or hitting the database. The admin cannot work that way. Every wp-admin page is generated fresh, logged in, uncacheable, so it runs the full stack on every click: it loads all autoloaded options into memory, runs the database queries the screen needs, executes every active plugin, and answers background requests like the Heartbeat. None of that is cached. So a site can serve a cached homepage in milliseconds while the admin grinds, because the admin is doing real work the front end skips. The fixes are backend fixes: trim what loads on every request, add a persistent object cache, calm the background requests, and clean the database.

What are autoloaded options and why do they slow the admin so much?

Autoloaded options are rows in the wp_options table marked to load automatically on every single request, so WordPress pulls all of them into memory at the start of every page, admin and front end alike. They exist so common settings are available without a separate query, which is fine when there are a reasonable number of them. The problem is bloat. Plugins store data there, and many leave large autoloaded options behind even after you deactivate or delete them, so the pile grows. When the total autoloaded data reaches several megabytes, WordPress is loading and unserializing all of it on every admin click, which is pure overhead. WordPress 6.6 added a Site Health check that flags the total autoloaded size as a problem when it passes 800KB, and it stopped autoloading any single option larger than 150KB by default. But it does not retroactively fix old options, so legacy bloat from past plugins stays until you clean it. Finding the biggest autoloaded options and turning autoload off for the ones that do not need it is often the single biggest admin speed win.

What is the Heartbeat API and how does it slow down wp-admin?

The Heartbeat API is a built-in WordPress feature that lets the browser and server talk in the background while you work in the admin. It powers autosave, post locking so two people do not overwrite each other, session expiry warnings, and live dashboard updates. It does this by sending a POST request to admin-ajax.php on a timer, as often as every 15 seconds in the post editor. Each of those requests is uncacheable and needs a dedicated PHP worker to answer it, so the cost adds up fast. One person editing a post is fine. Several editors with the dashboard and post screens open at once can generate a steady stream of admin-ajax requests that saturate the available PHP workers, and the whole admin feels slow for everyone, sometimes with the server CPU spiking. The fix is to slow the Heartbeat down, to 60 seconds, and disable it on screens that do not need it, rather than turning it off entirely, which would break autosave and post locking.

Will a caching plugin speed up my admin?

A page caching plugin will not, because the admin is deliberately never page-cached, but a persistent object cache will, and that is the one that helps. These are two different kinds of caching that get confused. Page caching stores finished HTML for logged-out visitors, which is why it speeds the front end and does nothing for the logged-in admin. A persistent object cache, backed by Redis or Memcached, is different: it stores the results of database queries and computed data in memory so WordPress does not rebuild them from the database on every request. The admin benefits enormously because it is query-heavy and runs uncached on every click. With a persistent object cache, repeated lookups that used to hit the database are served from memory, and the admin often goes from sluggish to instant. WordPress Site Health will even recommend a persistent object cache once your site is large enough to need one. So the right caching for a slow admin is object caching, not page caching.

How do I find what is making my admin slow?

Two free tools tell you almost everything. The first is Site Health, under Tools then Site Health, which flags the big structural problems: an oversized autoloaded options total, the absence of a persistent object cache, an outdated PHP version, and a low memory limit. Start there because it surfaces the common causes without any digging. The second is the Query Monitor plugin, which adds a toolbar showing, for the exact admin page you are on, the slowest database queries, how much time each plugin consumed, and which hooks were expensive. Load a slow admin screen with Query Monitor active and it usually points straight at the culprit, often a single plugin running a heavy query on every admin page or a query with no index. Between Site Health for the structural issues and Query Monitor for the per-screen offender, you can diagnose a slow admin without guessing.

Could WP-Cron be making my admin slow?

Yes, and it is a common hidden cause, especially on a site that feels slow even with no visitors. WordPress does not use a real system scheduler by default. Instead it runs scheduled tasks, called WP-Cron, by checking on page loads whether anything is due and running it then. On a busy site that is fine, but on a quieter site the tasks pile up, and then a single unlucky page load, sometimes an admin page, gets stuck running a backlog of jobs: backups, feed fetches, plugin housekeeping, email sends. That request hangs while it works through the queue, which feels like a slow admin. The fix is to disable the on-page-load behavior with a constant in wp-config.php and instead trigger WP-Cron from a real server cron job every few minutes, so scheduled tasks run on their own schedule in the background and never block someone clicking around the admin.

Does the PHP version or memory limit affect admin speed?

Both do, and they are quick to check. The admin is heavier than the front end, so it benefits more from a current PHP version and enough memory. Newer PHP, 8.2 or 8.3, runs WordPress noticeably faster than the older versions many sites are still on, so if your host is serving an old PHP version, upgrading it after testing for compatibility is one of the cheapest speedups available. Memory matters because the admin runs with a separate, higher limit than the front end, controlled by WP_MAX_MEMORY_LIMIT, which defaults to 256 megabytes. If a heavy plugin or a big site pushes past that, the admin slows or errors. Raising the admin memory limit and confirming you are on a modern PHP version removes two common ceilings, and together with trimming autoload, adding object caching, and calming the Heartbeat, they account for most slow-admin recoveries.

Can you make my WordPress admin fast without breaking anything?

Yes, and that is most of what we do here. We diagnose with Site Health and Query Monitor, then apply the fixes in order of impact: find and trim the autoloaded options bloat, including the orphaned data left by plugins you removed, add a persistent object cache if your host supports Redis or Memcached, throttle the Heartbeat API and disable it where it is not needed, clean the database of revisions, expired transients, and spam, move WP-Cron to a real server cron, and raise the admin memory limit or PHP version where they are holding you back. Each of these is reversible and none touch your content or design. We also identify any single plugin that is the real culprit and recommend a lighter alternative if it cannot be tamed. Flat $49 to $149, done in two hours when scope fits, money back if we cannot improve your measured admin speed.

Sources and further reading

Every technical claim on this page traces back to the WordPress core development notes, the WordPress developer documentation, or the named plugin.