Your website loads fine for visitors, but every click inside WordPress takes forever. The dashboard crawls, saving a post takes ten seconds, and opening the plugin page feels like wading through mud.
This is one of the most common WordPress frustrations, and it is also one of the most fixable. A slow admin area almost always has one specific cause, and once you find it, the fix usually takes less than an hour. This guide shows you how to find that cause in about five minutes, then walks through the seven fixes that solve it for most sites.
The quick answer
A slow WordPress admin is usually caused by one plugin doing too much work, the Heartbeat API polling too often, a bloated database, an old PHP version, or hosting CPU limits. Install the free Query Monitor plugin, open the slow screen, and it will show you which plugin or query is responsible. Fix that one thing first. Most slow dashboards are fixed by removing or replacing one plugin, slowing the Heartbeat API from 15 to 60 seconds, or cleaning up the database.
Why is the admin slow when the front end is fast?
This confuses a lot of beginners, so it is worth understanding first. Your public pages can be cached: a caching plugin saves a finished copy of each page and serves it to visitors without running WordPress at all. Logged-in admin screens cannot be cached that way. Every click in wp-admin runs PHP code, queries the database, and loads every active plugin's admin code, live, on every page.
That means a plugin that is invisible on the front end can still slow down every admin page. A database that is fine for serving cached pages can still choke when every admin click runs dozens of fresh queries. The front end being fast tells you almost nothing about the admin area, and that is actually good news: it narrows the suspects down to plugins, the database, background requests, and your hosting account's CPU limits.
Step 1: Diagnose the cause in 5 minutes
Do not start changing settings at random. Spend five minutes finding the actual cause, because the fix depends entirely on what you find. You need one free plugin and your browser.
Install Query Monitor
Query Monitor is a free plugin from the WordPress plugin directory. Install it, activate it, and reload the slow admin screen. A new menu appears in the top admin bar showing the page load time, the number of database queries, and the memory used. Click it and open the Queries panel, sorted by slowest first. It shows which query took the longest and which plugin or theme function made the call.
If one plugin's name keeps appearing next to the slowest queries, you have found your culprit. If the queries are fast but the page is still slow, the problem is probably background requests or server limits, which the next two checks will show.
Check the Network tab
Open the slow admin screen, press F12 to open your browser’s developer tools, and switch to the Network tab. Tick Disable cache, reload the page, and filter by Fetch/XHR. Look for requests that take more than two seconds. If admin-ajax.php is the slow one, open its Payload and read the action value: it names the feature making the call, often a live-stats widget, an auto-refresh feed, or the Heartbeat API itself.
Check your hosting resource usage
In cPanel on most shared hosts, open Metrics, then Resource Usage, and look for CPU, entry process, or memory faults at the times you were working in the dashboard. If you see red spikes or faults, your hosting account is hitting its limits, and no plugin fix will help until you deal with that. Your host’s support team can also tell you whether you are hitting limits.
| What you find | Most likely cause | Fix to try first |
|---|---|---|
| One plugin owns the slowest queries in Query Monitor | A heavy or badly coded plugin | Fix 1: find and replace the slow plugin |
| admin-ajax.php waits 2+ seconds and repeats | Heartbeat API or a plugin polling constantly | Fix 2: slow the Heartbeat API |
| wp_options autoload is over 1 MB, or hundreds of revisions | Bloated database | Fix 3: clean up the database |
| PHP 7.4 or older in Tools, then Site Health | Outdated PHP version | Fix 4: update PHP |
| CPU or entry-process faults in Resource Usage | Hosting account limits | Fix 5: check hosting limits |
| Slow queries everywhere, no single culprit | No object cache, repeated database work | Fix 6: add object caching |
| Many open admin tabs, dashboard full of widgets | Admin clutter and background tabs | Fix 7: tidy the admin |
Fix 1: Find and replace the slow plugin
Every active plugin can add scripts, styles, and database queries to every admin page, whether or not that plugin is relevant to the screen you are looking at. The average WordPress site runs 20 to 30 plugins, and each one adds roughly 30 to 80 milliseconds of PHP work to every uncached request. One badly coded plugin can add far more than that.
Here is how to find it:
- In Query Monitor, open the Queries panel on the slow screen and sort by slowest. Note the plugin behind the slowest queries.
- If Query Monitor does not point clearly at one plugin, deactivate all plugins, reload the dashboard, and confirm it is fast again. Then reactivate plugins one at a time, testing the dashboard after each one. When the slowness returns, the last plugin you activated is the problem.
- Before you delete it, check whether the plugin has a setting that causes the load: live stats, real-time feeds, auto-refresh, or an activity stream. Turning that one feature off often fixes it without losing the plugin.
- If there is no such setting, look for a lighter alternative that does the same job. A plugin that slows your whole dashboard is not worth keeping, no matter how useful its main feature is.
Keep a short list of what you deactivated and when, so you can undo the change if a plugin turns out to be essential.
Fix 2: Slow down the Heartbeat API
The WordPress Heartbeat API is a built-in system that keeps your login session alive, runs autosave, and powers post locking. It does this by sending a background request to admin-ajax.php every 15 seconds while the post editor is open, and every 60 seconds on the dashboard. Every open admin tab sends its own requests, so five open tabs means five times the traffic.
On shared hosting with tight CPU limits, that steady polling alone can make the whole admin area feel sluggish. The fix is to slow it down, not to kill it. Changing the editor interval from 15 seconds to 60 seconds cuts Heartbeat traffic on that page by 75 percent, while autosave and post locking keep working normally.
The easiest way for beginners is the free Heartbeat Control plugin by WP Rocket, available in the WordPress plugin directory:
- Go to Plugins, then Add New, and search for Heartbeat Control.
- Install and activate it.
- Open Settings, then Heartbeat Control, and set the interval to 60 seconds for the post editor. You can also disable the Heartbeat entirely on the dashboard screen, where autosave does not matter.
- Save, then reload the editor and confirm it still autosaves.
Developers can do the same thing with a few lines of code: a heartbeat_settings filter in a small must-use plugin that sets the interval to 60 seconds. Either way, do not disable the Heartbeat completely in the editor. Without it, autosave stops and two people can edit the same post without any warning.
Fix 3: Clean up the database
WordPress stores a surprising amount of clutter in its database: post revisions, expired transients, spam comments, and leftover rows from plugins you deleted months ago. Two parts of the database matter most for admin speed.
The first is the wp_options table, specifically the rows marked autoload. WordPress loads every autoloaded option into memory on every single page load, admin or front end. When that autoloaded data grows past about 1 MB, every admin click pays the price. Old plugins are the usual cause: they leave autoloaded rows behind when you delete them.
The second is post revisions. WordPress saves a revision every time you update a post, and a busy blog can accumulate thousands of them. They rarely hurt the front end, but they bloat the database and slow down the queries the editor runs.
A free plugin like WP-Optimize handles both safely:
- Install WP-Optimize from the plugin directory and open its Database page.
- Run the cleanup for post revisions, auto drafts, trashed posts, spam comments, and expired transients.
- Check the autoload size it reports. If it is still over 1 MB after cleanup, look at the largest autoloaded options: they usually belong to a plugin you no longer use, and removing that plugin's leftover rows (or the plugin itself) brings the size down.
Always take a backup before running a database cleanup. Your host usually offers one-click backups, and a backup plugin works too. A cleanup is routine and safe, but a backup turns a rare mistake into a five-minute restore instead of a disaster.
Fix 4: Update PHP to 8.2 or newer
PHP is the language WordPress runs on, and each major release has shipped meaningful speed gains. Upgrading from PHP 7.4 to PHP 8.2 makes the same site run noticeably faster on the same hosting, with no code changes needed for actively maintained plugins and themes. Running an old PHP version also means missing security updates, so this fix helps twice.
Here is how to check and update:
- In WordPress, go to Tools, then Site Health, then the Info tab. It shows your current PHP version.
- If it says 7.4 or older, update it. In cPanel, open Select PHP Version or MultiPHP Manager, choose PHP 8.2 or 8.3, and save. Other hosts put the setting under a PHP or software section; if you cannot find it, ask your host's support team.
- After the change, load the dashboard and a few pages, then check the front end too. If a very old plugin breaks, the Site Health screen will usually say so, and you can switch back to the previous version while you replace that plugin.
WordPress itself now recommends PHP 8.2 or newer, and as of late 2026 the actively supported branches are PHP 8.4 and 8.5. You do not need the newest version to see the benefit: moving off 7.4 is the big win.
Fix 5: Check your hosting CPU limits
If the dashboard is slow even with few plugins and a clean database, your hosting account may simply be out of CPU. On shared hosting, your site competes with other accounts for the same processor, and most cheap plans cap how much CPU one account can use. The admin area shows it first, because every click runs fresh PHP while visitors get cached pages.
Open your host's Resource Usage graph, as described in the diagnosis step, and look for CPU or entry-process faults. If you see them regularly, you have three options:
- Ask your host whether a higher plan raises the limit enough to matter, and what the next plan costs.
- Move to a host with more generous CPU allowances. If you are shopping for a new host, our best WordPress hosting for beginners guide compares the options with real prices, and our SiteGround vs Hostinger comparison covers two popular starter choices.
- If you already host with SiteGround or Bluehost, their higher tiers raise CPU limits, and their support teams can confirm whether your plan is the bottleneck before you spend anything.
Do not upgrade hosting blindly. Confirm the limit is actually being hit first, because a host upgrade will not fix a slow plugin or a bloated database. It only helps when the Resource Usage graph shows real faults.
Fix 6: Add object caching
Page caching does not help the admin area, but object caching does. An object cache, usually Redis or Memcached, stores the results of repeated database queries in memory so WordPress does not have to run the same query again on every admin click. On a dashboard that runs dozens of queries per page, that adds up fast.
This one depends on your host:
- Many managed WordPress hosts include Redis or Memcached on their plans and can turn it on for you. Ask support first: on some hosts it is a one-click toggle, and the matching drop-in plugin is installed for you.
- On shared hosting without object cache support, this fix may not be available. That is fine: the earlier fixes usually solve the problem on their own, and object caching is the finishing touch, not the first step.
- Once it is on, reload the dashboard and compare the load time in Query Monitor. You should see fewer database queries and a lower total query time.
Do not install a Redis plugin on a host that does not provide a Redis server. The plugin alone does nothing without the server behind it, and it will just add another thing to troubleshoot.
Fix 7: Tidy the admin area
Small habits add up when every admin page loads live. Close admin tabs you are not using: each one sends its own Heartbeat requests, so five open tabs mean five times the polling. On the dashboard itself, click Screen Options at the top right and switch off the widgets you never read. Some widgets, like news feeds and stats panels, make their own remote requests on every dashboard load.
Also limit post revisions so the database stops growing again after you clean it. Add a line to your wp-config.php file, above the line that says "That's all, stop editing", that sets WP_POST_REVISIONS to 5. That keeps the last five revisions of each post and discards older ones automatically. If editing wp-config.php makes you nervous, the WP-Optimize plugin from Fix 3 has a setting for the same thing.
What not to do
Two shortcuts look tempting and both cause trouble. First, never block admin-ajax.php in your security plugin or server rules. Saving posts, uploading media, and most plugins depend on it, and blocking it breaks the editor in confusing ways. Slow down whatever is calling it instead.
Second, do not disable the Heartbeat API entirely. It feels like a quick win, but autosave stops working, post locking stops, and you can lose work or overwrite a colleague's edits without warning. Throttle it to 60 seconds and disable it only on screens where it does nothing useful, like the main dashboard.
Quick checklist
Work through this list in order, and stop as soon as the dashboard feels fast again. Most sites are fixed by step two or three.
- Install Query Monitor and find the slowest plugin or query.
- Deactivate the slow plugin, or switch off its live or auto-refresh feature.
- Slow the Heartbeat API to 60 seconds with the free Heartbeat Control plugin.
- Clean the database with WP-Optimize, and check that autoload stays under 1 MB.
- Update PHP to 8.2 or newer.
- Check Resource Usage for CPU or entry-process faults.
- Ask your host about object caching.
- Close extra admin tabs, trim dashboard widgets, and limit post revisions to 5.
Frequently asked questions
Why is my WordPress admin slow but my website is fast?
Because your public pages are served from cache while admin pages are not. Every admin click runs PHP and database queries live, so plugin overhead, database bloat, and background requests show up in wp-admin first. Fix the admin cause directly; front-end speed tools like image optimization will not help here.
Is a slow WordPress dashboard a hosting problem?
Sometimes, but check the other causes first. Install Query Monitor and look at the slowest queries. If one plugin is responsible, switching hosts will not help. If the Resource Usage graph shows CPU or entry-process faults, then yes, your plan is the limit and an upgrade or a move will help.
How many plugins is too many?
There is no magic number. A site with 30 light, well-coded plugins can be faster than a site with 10 heavy ones. What matters is what each plugin does on every admin page load. If Query Monitor shows one plugin adding seconds to a page, that plugin is too much, whether you have 8 plugins or 40.
Will a caching plugin speed up wp-admin?
No. Page caching plugins speed up the front end for visitors, not logged-in admin screens. For the admin area, the tools that help are object caching, a clean database, a current PHP version, and removing whatever is making slow requests.
Keep your site fast from here
A slow dashboard is usually a warning sign, not a one-time glitch. The plugin you just removed, the revisions piling up, or the PHP version you have not touched in two years will all come back if you ignore them. Add a monthly check to your routine: open Site Health, glance at the PHP version and the database size, and remove any plugin you have not used in a month. Our WordPress website maintenance checklist turns that into a ten-minute habit, and our how to speed up WordPress guide covers the front-end side of performance once the dashboard is fixed.
