Your visitors say the website is quick. Your speed test agrees. But every time you log in, the dashboard drags. Clicking “Posts” takes several seconds, saving a page feels like waiting for a kettle, and the WooCommerce orders screen is so sluggish that staff have started avoiding it. The front end is fine, and the back end is miserable.
That split is a useful clue, not a mystery. The public site and the dashboard are built in very different ways, and the things that make the public site fast do almost nothing for wp-admin. Understanding why tells you where to look.
Why the dashboard is slow when the site is not
Most WordPress sites serve visitors from a cache. The first visitor’s page is built by PHP and the database, then saved as a ready-made copy, and everyone after them gets that copy. It is quick because almost no work happens.
The dashboard cannot be cached that way. Every admin screen is personal to the logged-in user and has to reflect the latest data, so WordPress builds it fresh on every click. Every active plugin loads, every database query runs, and any plugin that wants to phone home does so. A site can hide a lot of inefficiency behind its cache; the dashboard shows it all.
So a slow dashboard means each uncached page load is doing too much work, or waiting on something. The question is what.
The usual reasons, roughly in order
1. A plugin waiting on an outside server
Many plugins contact their developer’s servers from the dashboard: licence checks, update checks, news feeds, notices and usage statistics. If that remote server is slow or unreachable, your dashboard waits for it, sometimes on every page. This is the single most common cause we see of a dashboard that is slow on some screens and fine on others.
2. Too much data loaded on every request
WordPress stores settings in the wp_options table, and options marked as “autoload” are loaded on every single page. Plugins you deleted years ago can leave large autoloaded entries behind. Recent versions of Site Health warn when the total gets large. Expired transients, an oversized post revisions table and leftover plugin tables add to the load. Our guide to tidying the WordPress database explains what is safe to clear.
3. Heavy admin screens
Some screens are simply expensive. Order lists in a busy WooCommerce store, an analytics dashboard widget, a page builder’s editor or a list of thousands of posts with several custom columns each do a lot of work per click. If the slowness is limited to one screen, the plugin that builds that screen is the place to look.
4. The Heartbeat and background requests
While you are in the dashboard, WordPress sends small background requests to admin-ajax.php through what it calls the Heartbeat API. It is used for things like post locking and autosave. Normally it is harmless, but on a small hosting plan with several editors logged in, these requests plus plugin AJAX calls can tie up the server’s limited PHP processes and make everything else wait.
5. Hosting resources
Shared plans often limit how many PHP processes can run at once and how much CPU each account gets. The cached front end hardly uses either, so you never notice. The dashboard uses both, so it hits the ceiling. An old PHP version makes this worse, because newer versions generally run WordPress code more efficiently.
6. A recent change
If the dashboard was fine last month and slow now, look at what was installed or updated in between. Our post on sites that slow down after an update covers that pattern in more depth.
Finding the cause
None of the first checks below change anything. Before you deactivate plugins or touch the database, take a backup you could restore if something unexpected happens.
Measure, do not guess
The free Query Monitor plugin is the standard tool for this. Once active, it adds a panel to the admin toolbar showing, for the page you are on, how long it took to generate, how many database queries ran, which plugin each slow query came from, and every outside HTTP request made during the load, with how long each took. A single remote request taking several seconds stands out immediately. Deactivate it when you are done; it is a diagnostic tool, not something to leave running.
Check Site Health
Under Tools, then Site Health, look at the Status tab for warnings about PHP version, autoloaded options, a missing persistent object cache, or failing scheduled events. The Info tab shows your PHP memory limit and server details, which you will want if you end up talking to your host.
Compare screens
Is it every page, including the bare dashboard? Or only Orders, or only the editor? Every page points to something loading globally, such as a plugin’s remote call or autoloaded data. One screen points to the plugin that owns it.
Test with plugins off
Use the Health Check & Troubleshooting plugin’s troubleshooting mode, or a staging copy, and turn plugins off. If the dashboard becomes quick, turn them back on in small groups until it slows down again. The plugin you just switched on, or the combination, is your answer. When it is a combination, our plugin conflict service works through exactly that kind of puzzle.
Fixes that usually help
- Replace or reconfigure the slow plugin. Many plugins have settings to turn off dashboard widgets, usage tracking or notices. If a plugin is slow because its developer’s server no longer answers and nobody maintains it, replacing it is usually kinder than working around it.
- Clean the options table and old data. Remove leftovers from deleted plugins, clear expired transients and limit post revisions with
define( 'WP_POST_REVISIONS', 10 );inwp-config.php, or a number that suits you. - Remove dashboard widgets you never read. Screen Options at the top of the dashboard lets you hide them, but a widget that fetches remote data may still need its plugin setting changed.
- Calm the Heartbeat if it is the issue. Some performance plugins let you lengthen the interval in the dashboard. Do not switch it off entirely without understanding what relies on it, such as autosave and post locking.
- Add a persistent object cache. If your host offers Redis or Memcached, a persistent object cache stores database results between requests and often helps the dashboard more than the front end.
- Move to a current PHP version, after checking your plugins and theme support it. Our post on the PHP version change most hosts eventually force covers how to do that safely.
- Raise the hosting limits. If everything above is clean and the dashboard is still slow under normal use, the plan may simply be too small for the site’s admin workload.
What to collect before asking anyone for help
Whether you go to your host, a developer or us, a little evidence turns a vague complaint into something that can be investigated. Before getting in touch, note down:
- Which screens are slow, and roughly how many seconds each takes. “Orders takes about eight seconds, Posts is fine” is far more useful than “the admin is slow.”
- When it started, and anything installed, updated or changed around that time.
- Whether it is slow at all hours or mainly at busy times of day. Busy-hour slowness points towards the server; constant slowness points towards the site.
- Your PHP version and memory limit from the Site Health Info tab.
- If you ran Query Monitor, a screenshot of its summary on the slowest screen, especially the HTTP requests and slow queries panels.
Hosts in particular respond better to specifics. If you can show that the database is fine and the time is spent waiting on CPU, they can check whether your account is being throttled.
Where this ends and front-end speed begins
A slow dashboard and a slow website overlap less than people expect. Image compression, page caching and CDN settings make the public site faster but barely touch wp-admin. If visitors are also waiting, that is a separate job, and our website speed optimization service is built for the public side of the site. This post is only about the screens you see after logging in.
Keeping the dashboard responsive
- Remove plugins you are not using, rather than leaving them deactivated for years. Some still leave settings loading on every page.
- Glance at Site Health every month or two. Its warnings are short and often point straight at the cause.
- When adding a plugin, notice whether the dashboard feels different the next day. It is much easier to connect cause and effect when only one thing changed.
- Ask your host what PHP processes and CPU your plan allows, so you know when you are close to the edge.
A slow dashboard is one of the gentler items in our guide to WordPress errors, but it costs real time every working day. If you would like someone to measure where the time is going and fix it carefully, our ongoing WordPress support includes this kind of investigation. We profile on a copy where possible and tell you which plugin or setting was responsible.
Background requests from the editor are a common culprit; we explain them in what the WordPress Heartbeat API does.
Next in this series: Cannot Modify Header Information in WordPress: The Fix
