Fixing a slow WordPress admin dashboard
How to diagnose and fix a slow WordPress admin dashboard, covering plugin overhead, database bloat, Heartbeat API issues, large content tables, server resources and admin-specific performance problems.
If your WordPress site loads quickly for visitors but the admin dashboard takes forever to respond, you're dealing with an admin-specific performance problem. Pages take seconds to load, saving a post feels sluggish, the plugin list crawls and sometimes the dashboard times out entirely.
This is a different problem from a generally slow site. Your front end might be fast because caching is serving stored copies of pages to visitors, but the admin dashboard can't be cached in the same way. Every admin page load runs PHP, queries the database and loads assets from your active plugins and theme. When any of these are inefficient, the admin is where you feel it.
Admin slowness usually has a specific cause that you can track down, rather than being a vague "everything is slow" situation.
Identify which admin pages are slow
Before making changes, note whether the slowness affects the entire admin area or just specific pages. This narrows down the cause significantly.
If every admin page is slow, the problem is likely something that loads on every page: a plugin that injects scripts or runs queries across the entire admin, a bloated database or server resource limitations.
If only specific pages are slow (for example, the post list, the WooCommerce orders page or the plugins page), the problem is more likely related to the volume of data on that page or a plugin that adds functionality specifically to that screen.
If the front end of your site is slow as well, start with our guide to diagnosing a suddenly slow WordPress site instead.
Check the page load time in your browser's developer tools (F12, then the Network tab). The total load time and the number of requests give you a baseline to measure improvements against. For more detail, the Query Monitor plugin shows the database queries, HTTP requests and PHP errors behind each admin page, and which plugin is responsible for each. Deactivate it when you've finished, since it adds overhead of its own.
Check plugin overhead
Plugins are the most common cause of admin slowness. Every active plugin can load its own CSS, JavaScript and PHP on admin pages, sometimes even on pages where the plugin isn't relevant. The more plugins that do this, the more overhead every admin page load carries.
The most effective test is to deactivate all plugins temporarily and see how the admin performs. If it's dramatically faster, plugins are the cause. Reactivate them in small batches to narrow down which ones are responsible for the most overhead.
Deactivating plugins on a live site switches their features off for visitors too, which matters if you run a shop, a membership site or contact forms. The official Health Check & Troubleshooting plugin has a troubleshooting mode that disables plugins and switches to a default theme for your logged-in session only, while visitors continue to see the normal site. Take a backup before using it all the same, and note which plugins were active so you can put things back if anything goes wrong.
Pay particular attention to plugins that display their own dashboard widgets, show notifications or banners across the admin, add columns to post or product list tables, run background checks or scans on every page load, or load large JavaScript files on every admin page rather than just their own.
You don't necessarily need to remove the plugins causing slowness. Sometimes the fix is configuring them differently, disabling features you don't use or contacting the developer about the performance issue. But knowing which plugins are the heaviest gives you the information to make that decision.
Reduce the Heartbeat API frequency
WordPress includes a feature called the Heartbeat API that sends regular background requests from your browser to the server while you're logged into the admin. WordPress uses it for things like post locking (the warning when someone else is editing the same post), login session checks and some plugin notifications.
By default, the Heartbeat API sends a request every 15 to 60 seconds depending on the screen.1 On servers with limited resources, these background requests can add up, especially if several people are logged into the admin at the same time.
You can reduce the frequency with a small code snippet. The safest place for it is a code snippets plugin or a child theme's functions.php file, so a theme update doesn't remove it. Download a copy of functions.php before editing it, since a typo in that file can cause a critical error:
add_filter( 'heartbeat_settings', function( $settings ) {
$settings['interval'] = 120;
return $settings;
} );
This changes the interval to 120 seconds (2 minutes). WordPress's own code notes that intervals longer than 120 seconds can limit or disable some features, such as post locking,1 so don't go higher than that if more than one person edits content on your site.
If you'd rather not add code, some performance plugins include Heartbeat settings. Check your existing caching or performance plugin before installing anything new.
Speed up large content lists
If specific admin pages are slow, the most likely cause is a large amount of data being loaded and displayed on that page.
The Posts or Pages list can become slow when you have thousands of entries, particularly if plugins add custom columns that each run their own database queries. Large WooCommerce order lists and media libraries with tens of thousands of files can struggle too.
WordPress shows 20 items per page on these list screens by default. You can lower this to speed up the page load. Click Screen Options at the top right of the list page and reduce the "Number of items per page" value.
Screen Options also lets you hide columns, but hiding a column only hides it visually. WordPress still generates the column's contents for every row,2 so hiding a slow plugin column won't make the page faster. If a plugin's column is slowing the list down, look in that plugin's settings for an option to turn the column off, or ask its developer.
Clean up the wp_options table
The wp_options table is one of the most frequently queried tables in WordPress, and it's also prone to bloat. Plugins you've installed over the years may have left settings, temporary data and cached values in this table, even after you deactivated and deleted them.
Part of this table (the "autoloaded" options) is loaded on every single page request. If the autoloaded data grows large, it adds overhead to every page load, including in the admin.
Since WordPress 6.6, Tools → Site Health shows a critical issue when your autoloaded options add up to more than 800 KB, so check there first.3
You can also check the size of your autoloaded data by running this query in phpMyAdmin (select your WordPress database, then click the SQL tab). This query only reads data and doesn't change anything. WordPress 6.6 introduced new autoload values alongside the old yes, so the query needs to include them all:3
SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');
The result is in bytes. If it's over about 800,000 (800 KB), there's likely clean-up to be done. Use your actual table prefix in place of wp_ if it differs. Common culprits include temporary data left behind by plugins, large settings stored by page builders or theme options, logging data that's grown over time and settings from plugins that are no longer active.
Be very cautious about deleting rows from wp_options by hand, and always export a backup of the database first. This table contains critical WordPress and plugin settings, and deleting the wrong row can break your site. If you're not confident working with the database, this is a job to hand to a developer.
Check for excessive background requests
Some plugins use AJAX (background JavaScript requests) to load data, check for updates or run processes while you're on admin pages. If a plugin makes many of these requests, or they're slow, the admin can feel sluggish even if the initial page load is fast.
Open your browser's developer tools (F12), go to the Network tab, filter by "Fetch/XHR" and watch the requests that come in while you're on an admin page. If you see a high volume of requests, or requests that take a long time to complete, note which plugin or feature they relate to. The request URL or the data being sent usually gives a clue.
Check server resources
If the admin is slow across the board and deactivating plugins doesn't help much, your server may not have enough resources for what the admin needs.
The front end of your site may be fast because caching handles most of the work. The admin doesn't benefit from page caching, so it exposes the true speed of your server's PHP processing and database queries.
Check your hosting control panel for CPU, memory and database usage. If the admin sometimes fails completely with a 502, 503 or 504 error, see our guide to fixing those errors. On WooCommerce stores, a very large backlog of background tasks can also slow the admin, and our guide to past-due scheduled actions covers clearing it. If you're on shared hosting and regularly hitting resource limits, the admin is usually the first thing to suffer.
Your hosting provider can tell you whether your plan's resources suit the size of your site. A site with WooCommerce, a page builder, dozens of plugins and thousands of posts or products needs more resources than a simple blog, and a plan with more CPU and memory can make a noticeable difference.
Check your PHP version
The version of PHP running on your server affects both speed and security. Check your current version under Tools → Site Health → Info → Server or in your hosting control panel.
WordPress currently recommends PHP 8.3 or newer, and notes that older versions have reached their official end of life and may expose your site to security vulnerabilities.4 The PHP project publishes which versions are still supported and until when.5
Changing PHP version is done in your hosting control panel or by your host, and it can break plugins or themes that aren't compatible with the new version. Before switching, take a full backup, check your plugins and theme support the new version, test on a staging copy if you can and note your current version so you (or your host) can switch back if the site shows errors.
Need help with a slow admin dashboard?
If your WordPress admin is still slow after working through these steps, or you've found the cause but need help fixing it without affecting your live site, my WordPress development service and emergency WordPress support cover admin performance, database clean-ups and plugin audits.
heartbeat.js, WordPress source code on GitHub. ↩ ↩
class-wp-list-table.php, WordPress source code on GitHub. ↩
Options API: Disabling autoload for large options, Make WordPress Core, 18 June 2024. ↩ ↩
Requirements, WordPress.org. ↩
Supported versions, PHP.net. ↩