Why wp-admin is slow when the front end is fine, and how to fix it

A slow dashboard is a different problem from a slow site, and it fools people because the usual fixes don’t apply. Page caching serves visitors a saved copy; it never serves you, because you’re logged in. So the front end can be quick while wp-admin runs every plugin, every query, and every background job on every click. The good news: the list of causes is short, and each has a one-minute check.

Step 01 Find out what’s slow first

Install Query Monitor (temporarily), open the dashboard, and read the top bar: total time, number of queries, and the slowest component. In two minutes it tells you whether you’re waiting on the database, on a plugin, or on an outside server. If the admin bar shows 400 queries and 6 seconds, keep reading. If it shows 60 queries and 0.4 seconds but the page still feels slow, the wait is in the browser: a plugin’s admin JavaScript, or a page builder loading its whole editor on every screen.

Step 02 Autoloaded options

The most common one. WordPress loads every wp_options row marked autoload = yes on every request, including admin ones. Years of plugins leave megabytes behind.

SELECT option_name, LENGTH(option_value) / 1024 AS kb
FROM wp_options WHERE autoload = 'yes'
ORDER BY kb DESC LIMIT 20;

If the top rows belong to plugins you removed years ago, set their autoload to no or delete them. If the total is over 2 MB, this alone is a visible improvement. (The same check is step 04 of the TTFB post; it hurts admin more because admin is never cached.)

Step 03 Heartbeat and Cron

Two background workers run inside wp-admin. Heartbeat pings the server every 15 seconds while a post editor is open (autosave, post locking). On a slow server with several editors open, those pings queue up and everything waits. Reduce it to 60 seconds, or disable it outside the editor; most performance plugins have the switch.

WP-Cron is worse: it runs scheduled jobs (backups, email queues, WooCommerce’s Action Scheduler) during a real request, so the visitor or admin who happens to trigger it waits for the job. Move it to a real server cron: add define( 'DISABLE_WP_CRON', true ); to wp-config.php and have the host call wp-cron.php every five minutes. Every managed host documents this.

Step 04 Plugins that phone home

Some plugins check a licence, fetch news for their dashboard widget, or call an analytics API when an admin page loads. If that remote server is slow, your dashboard waits for it. Query Monitor’s “HTTP API Calls” panel lists them with timings. The fix is a setting (disable the news widget), a replacement, or, in one memorable case, an entire plugin whose only slow part was a wp_remote_get to a server that had been switched off two years earlier.

Step 05 The admin screens themselves

Dashboard widgets from every plugin, a WooCommerce orders list with 200 rows per page, an admin theme, a page builder that loads its editor on screens that don’t need it. Screen Options (top right) hides widgets and reduces rows per page; both change what loads. And check the object cache: without Redis or Memcached, every admin screen re-runs the same queries WordPress could have remembered.

Step 06 PHP workers and the host

If the site is busy, wp-admin competes with visitors for the same PHP workers, and on cheap plans there are two. Uncached front-end traffic (search, carts, logged-in users) fills them, and your admin click waits in line. The host’s resource graphs show it. The fix is more workers, which usually means the next plan up, or a host whose plans are built for WordPress.

That’s the list. Ninety percent of slow dashboards I see are steps 02 and 03. If yours isn’t, and you’d like it measured instead of guessed, that’s the performance work I do, admin side included.