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.

Fixing a slow WordPress admin dashboard

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 static 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 all your active plugins and theme. When any of these are inefficient, the admin is where you feel it.

The good news is that admin slowness usually has a specific, identifiable cause 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.

Try loading the admin with ?debug or 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.

Check plugin overhead

Plugins are the most common cause of admin slowness. Every active plugin can load its own CSS, JavaScript, and PHP on every admin page, even pages where the plugin isn't relevant. A site with 30 or 40 active plugins can have a significant amount of overhead on every admin page load.

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 (five at a time) to narrow down which ones are responsible for the most overhead.

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 libraries for their settings pages 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. It's used for things like auto-saving drafts, showing real-time notifications, displaying lock warnings when someone else is editing a post, and keeping your login session active.

By default, the Heartbeat API sends a request every 15 to 60 seconds depending on the page. On servers with limited resources, these frequent background requests can add up, especially if multiple people are logged into the admin at the same time.

You can reduce the frequency or disable the Heartbeat API on pages where it isn't essential. Add the following to your theme's functions.php file (ideally in a child theme):

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

This changes the interval to 120 seconds (2 minutes), which significantly reduces the load while still keeping auto-save and session management functional. You can increase this further if needed, though very long intervals may mean auto-save doesn't capture your work as frequently.

If you'd rather not edit PHP files, some performance-oriented plugins include Heartbeat management as a feature. Look for this in your existing caching or performance plugin's settings before installing anything new.

Optimise large content tables

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 published posts, particularly if plugins add custom columns that each require their own database query. The WooCommerce Orders page is notorious for this at scale. The Media Library can struggle with tens of thousands of uploaded files.

WordPress loads a set number of items per page on these screens. You can reduce this number to speed up the page load. Click Screen Options at the top right of the list page and lower the "Number of items per page" value. Reducing it from the default 20 to 10 or even 5 can make a noticeable difference on large sites.

If custom columns added by plugins are contributing to the slowness (each column can trigger additional database queries for every row displayed), you can disable unnecessary columns through Screen Options as well.

Clean up the wp_options table

The wp_options table is one of the most frequently queried tables in WordPress, and it's also one of the most prone to bloat. Every plugin you've ever installed may have left settings, transient data and cached values in this table, even plugins you've since deactivated and deleted.

A large wp_options table slows down the entire admin because WordPress loads a portion of it (the "autoloaded" data) on every single page request. If the autoloaded data has grown to several megabytes, it adds overhead to every page load.

You can check the size of your autoloaded data by running this query in phpMyAdmin (select your WordPress database, then click the SQL tab):

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';

If the result is over 1MB, there's likely cleanup to be done. Common culprits include transient data left behind by plugins, large serialised arrays stored by page builders or theme options, analytics or 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 manually. This table contains critical WordPress and plugin settings, and deleting the wrong row can break your site. If you're not confident working with database queries, this is a task worth getting professional help with.

Check for excessive admin AJAX 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 is making many AJAX requests or if those requests are 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 "XHR" or "Fetch" 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 plugin deactivation doesn't help significantly, your server may not have enough resources for the admin's needs.

Remember that 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 performance of your server's PHP processing and database query speed.

Check your hosting control panel for CPU, memory and database performance metrics. If you're on shared hosting and consistently hitting resource limits, the admin will be the first thing to suffer because it's the most resource-intensive part of WordPress.

Consider whether your hosting plan is appropriate for the size and complexity 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. Upgrading to a plan with more CPU, memory and dedicated database resources often produces an immediate improvement in admin performance.

Check your PHP version

The version of PHP running on your server has a significant impact on admin performance. PHP 8.x is substantially faster than PHP 7.x for the kind of processing-heavy work the admin dashboard does.

Check your current PHP version under Tools → Site Health → Info → Server or in your hosting control panel. If you're running anything older than PHP 8.0, upgrading can provide a noticeable speed improvement across the entire admin.

Before upgrading, check that your plugins and theme are compatible with the newer PHP version. Most actively maintained plugins support PHP 8.x, but older or abandoned plugins may not. Test on a staging environment if possible.

Need help with a slow admin dashboard?

If your WordPress admin is still slow after working through these steps, or if you've identified the cause but need help resolving it without affecting your live site, my emergency WordPress support service covers admin performance diagnosis, database optimisation and plugin auditing.

Adam Greenough

Written by Adam Greenough

Freelance web developer with over 15 years of experience building and fixing WordPress sites. I work with businesses across the UK on everything from emergency support to full builds.

Need hands-on help?

I offer emergency WordPress support with a no-fix, no-fee guarantee.