A slow WordPress admin dashboard is a different problem from a slow website. Your front end is fast because caching serves visitors a saved copy of each page. The admin cannot be cached, so every screen runs live PHP and hundreds of database queries. The usual culprit is bloat in your options table.

This catches people out constantly. They run their site through a speed test, get a good score, and cannot understand why saving a post takes eight seconds.

Front-end speed guides will not fix this, because the two problems share almost no causes. Here is how to find yours, ordered by how long each check takes.

Why a fast site can have a slow dashboard

Caching is why, and it only protects visitors.

When someone visits your homepage, your caching plugin usually hands them a pre-built HTML file. No PHP runs, few queries fire, and the page arrives quickly. That is what your speed test measured.

The admin works the opposite way. Every screen has to be current, so nothing gets cached. Each page load runs PHP, queries the database, and loads assets from every active plugin. One practitioner measured admin screens running roughly 200 to 400 database queries per page against 40 to 60 on a cached front end, and that ratio matches what we see on client sites.

So a fast front end tells you nothing about admin performance. It may even hide the problem, because the caching layer is quietly compensating for a database that needs attention. Our guide to fixing a slow WordPress website covers the visitor-facing side, and almost none of it applies here.

Two checks that take under a minute

Do these before installing anything.

Check Site Health. Go to Tools, then Site Health, then Info, and open the Database section. WordPress has flagged excessive autoloaded options since version 6.6, and it warns once the autoloaded data passes 800KB. If yours is measured in megabytes, you have found your problem and the next section explains it.

Reduce items per page. If one specific screen is slow, such as Posts, Products or Orders, click Screen Options at the top right and lower the number of items shown per page. Twenty instead of a hundred can turn a ten-second screen into a fast one immediately.

That second fix is embarrassingly simple and it solves a real share of complaints. It works because each row on those screens can trigger its own queries, especially when plugins add custom columns.

Find out what is actually slow

Install Query Monitor and open the slow screen. It adds a toolbar showing total queries, total load time, and which plugin or theme owns the slowest ones.

Read it in this order. Look at total query count first, then at the slowest individual queries, then at which component they belong to. A single plugin sitting at the top of that list is your answer, and you have found it in two minutes rather than by deactivating things at random.

If Query Monitor shows a reasonable query count and the screen is still slow, the problem sits below WordPress. Skip to the hosting section.

Deactivate the offending plugin temporarily and reload the screen to confirm. Do this on a staging copy if the site is live and busy, since deactivating a plugin on production is not always harmless.

The most common cause: autoloaded options

WordPress stores site settings in the wp_options table. Options marked as autoload get loaded into memory on every single page request, including every admin screen.

That design is fine until plugins abuse it. Some store large serialised arrays, cached API responses, or entire product catalogues as autoloaded options. Nobody removes them when the plugin is deleted. The table grows for years, unnoticed, because it is invisible from the dashboard.

The scale is worth stating. WordPress core treats 800KB as the warning threshold. One practitioner reports sites carrying 45MB of autoloaded data with five-second admin loads. In one WooCommerce case, an inventory plugin stored full catalogues as autoloaded transients at 38MB. Cleaning it dropped admin load time from 8.3 seconds to 1.4 seconds.

How to clean up autoloaded options safely

  1. Take a full backup first. You are editing the table that holds your site’s settings.
  2. Use Site Health’s database view, or a query in phpMyAdmin, to list your largest autoloaded options by size.
  3. Identify what each one belongs to. Names usually carry a plugin prefix.
  4. Delete entries belonging to plugins you no longer have installed. Those are pure leftovers and safe to remove.
  5. For options belonging to active plugins, do not delete them. Set autoload to off instead, so they load only when needed. WordPress 6.4 added a proper function for this, and the core performance team has been building it into Site Health.

Expired transients pile up in the same table. Most database optimisation plugins clear them in one click, and doing that first often removes a surprising amount of weight before you touch anything by hand.

The Heartbeat API

WordPress polls the server while you have the admin open. That is the Heartbeat API, and it powers autosave, post locking and live notifications.

By default it fires every 15 seconds on post edit screens and every 60 seconds on the dashboard, each time hitting admin-ajax.php. On a decent server that is invisible. On shared hosting it is not, especially with several people logged in or a tab left open all day. Those requests accumulate into real CPU load, and some hosts suspend accounts over it.

The fix is to slow it down rather than switch it off. Heartbeat Control lets you set different intervals for the dashboard, the post editor and the front end, and many caching plugins include the same setting already.

Be careful in the post editor specifically. Disabling Heartbeat there removes autosave and post locking. That means lost work in a crash, and two people overwriting each other. Lengthen the interval to 60 seconds instead.

WP-Cron running on your admin visits

WordPress does not have a real scheduler. It runs scheduled tasks when someone loads a page, which on a low-traffic site often means when you load an admin page.

So your backup plugin, email queue, import jobs and cleanup routines can all fire while you open the Posts screen. That is why the dashboard feels fine some days and takes ten seconds on others.

Check your scheduled events with a cron manager plugin. Look for jobs that are stuck, failing repeatedly, or scheduled far more often than they need to be. Deleting orphaned events left behind by uninstalled plugins is usually the quickest win.

For a busy site or a store, the better fix is to disable WordPress’s built-in cron and run a real server cron every five minutes instead. Add define(‘DISABLE_WP_CRON’, true); to wp-config.php, then set up the server-side job through your hosting panel. Do not do the first half without the second, or your scheduled tasks simply stop running.

Big tables and heavy screens

Some admin screens are slow because of how much data they are asked to display.

Posts and Pages lists slow down at thousands of entries. It gets worse when plugins add custom columns, since each column can run its own query per row. WooCommerce Orders is the well-known example, and our guide to speeding up a WooCommerce store covers the store side of this.

The Media Library struggles at tens of thousands of files, and every uploaded image multiplies into several generated sizes. Cleaning up unused media and controlling generated sizes helps both the library and your disk usage, which our guide to optimising images in WordPress covers.

Post revisions are the quiet one. WordPress keeps every draft of every post forever unless you tell it not to. Cap them by adding define(‘WP_POST_REVISIONS’, 10); to wp-config.php, then clear the existing backlog with a database optimisation plugin after a backup.

When it is the host, not your site

At some point optimisation stops helping, and continuing to optimise is how people waste weekends.

Three signs point at the host. Query Monitor shows a normal query count on a slow screen. The admin is slow on a fresh install with no plugins. Or the slowness arrives in waves that match your traffic. Shared hosting caps CPU, memory and PHP workers, and the admin competes with visitors for all three.

Ask your host two direct questions: how many PHP workers does this plan allow, and am I hitting CPU limits? Those get a clearer answer than a ticket saying the dashboard feels slow.

The honest tradeoff: a better plan costs money every month, and a database cleanup is free. Do the free work first. But if a clean site on adequate PHP still crawls, no further optimisation will fix a server that is out of capacity. Our guide to what a WordPress repair costs covers how to weigh that decision.

Key takeaways

A slow WordPress admin dashboard is not the same problem as a slow website, and front-end speed guides do not address it. Caching protects your visitors and does nothing for the admin, which runs live PHP and hundreds of queries on every screen.

Start with the two checks that take a minute. Look at Site Health’s autoloaded options figure, then at Screen Options on whichever screen is slow. Autoload bloat past a few megabytes is the most common cause, and it stays invisible until you look for it.

After that, use Query Monitor to name the guilty plugin rather than deactivating things at random. Slow the Heartbeat API rather than disabling it in the editor. Replace WP-Cron with a real server cron on busy sites. And when a clean site on a clean install is still slow, stop optimising and talk to your host.

Frequently asked questions

Why is my WordPress site fast but the admin slow?

Because caching only covers the front end. Visitors receive a pre-built HTML copy of your pages, while every admin screen runs live PHP and queries the database. A good speed test score measures the cached version and says nothing about admin performance, which is why the two problems need different fixes.

What are autoloaded options and why do they slow the dashboard?

Autoloaded options are settings WordPress loads into memory on every page request. Plugins sometimes store large arrays or cached data there and leave it behind after uninstall. WordPress warns once autoloaded data passes 800KB. Sites carrying several megabytes commonly see multi-second admin loads until it is cleaned up.

Should I disable the WordPress Heartbeat API?

Reduce it rather than disable it. Heartbeat powers autosave and post locking in the editor, so switching it off there risks lost work and two people overwriting each other. Lengthening the interval to 60 seconds cuts the server load while keeping those protections, and most caching plugins offer that setting.

How do I find which plugin is slowing my dashboard?

Install Query Monitor and open the slow screen. Its toolbar shows total queries, the slowest individual queries, and which plugin or theme is responsible. That identifies the culprit in minutes. Confirm by deactivating that plugin temporarily, ideally on a staging copy rather than on a live site.

Will deleting post revisions speed up my admin?

It helps on sites with thousands of posts, since revisions inflate the posts table that admin screens query constantly. Cap future revisions with WP_POST_REVISIONS in wp-config.php, then clear the backlog using a database optimisation plugin after taking a backup. On a small site the gain is modest.

Dashboard still crawling after all that?

Some of this is a ten-minute fix and some of it turns into an afternoon of database work you would rather not do on a live site. Survyc is an AI-first digital agency that diagnoses and fixes WordPress performance for agencies and businesses, admin side as well as front end, and we work white label so your own client sees your name on the result. Tell us which screens are slow and how long they take, and we will tell you where the time is going. Get in touch or email info@survyc.com. If you would rather it never got this bad, our WordPress care plans keep the database tidy on a schedule.