Why wp-admin is slow when the front end is fine, and how to fix it
The site loads fast for visitors but the dashboard takes eight seconds and saving a post feels like dial-up. That gap has a short list of causes, none of which a caching plugin can reach. Here they are, with the check for each.
Published 6 min read
This post runs queries against your database. Back up before the first DELETE, and expect your tables to differ from the ones described. If you'd prefer someone else did it, the end of the post says what we charge.
The short answer
Page caching never serves you while you're logged in, so the dashboard runs every plugin and query on every click. Measure first with Query Monitor, then check autoloaded options, Heartbeat and cron, plugins that call other servers, heavy admin screens and your host's PHP workers.
- 01Find out what’s slow first
- 02Autoloaded options
- 03Heartbeat and Cron
- 04Plugins that phone home
- 05The admin screens themselves
- 06PHP workers and the host
Rather hand it over? Get a fixed price for the whole job, from $699.
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. (It hurts admin more than the front end because admin is never cached. The deep version, including how to find which plugin keeps refilling the table, is in the autoloaded options post.)
Stop here. Add "clear expired transients" to your monthly routine.
Step 03.
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, whose tables grow until someone sweeps them) 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.
Rather hand it over at this point? Finding where the time goes is the first thing our performance work does, with a fixed price before we start.
From the RoundBorders team
Still slow after these steps?
Send the address and what you measured. We find where the time goes and send a fixed price, usually within a few hours.
- From $699
- Measured before and after
- Nothing to pay until you approve a price
Write as much as you like: what's happening, what you want, links, errors. The more we know, the more exact your fixed price.
Founder of RoundBorders. Building and fixing WordPress sites since 2012; our work is listed in the WooCommerce, Pressable and Jetpack partner directories.
Found a mistake? Write to me.