A slow WordPress admin is a different problem from a slow website, and the advice for one does not apply to the other. Page caching. The largest gain on the front end, does nothing here, because admin pages are never cached.
So every admin request runs the full application. Whatever is expensive shows up undiluted.
Why the admin cannot be cached
Each screen is specific to you: your permissions, your notices, your drafts. A cached admin page would be one user's screen served to another, which is why every caching layer excludes them.
That also means the admin is a fair measure of what your site actually costs to generate. A fast public site with a slow admin is a site whose speed comes entirely from caching, with a heavy application underneath.
Find the plugin, do not guess
One plugin querying the database on every admin screen costs more than thirty that do nothing there.
Deactivate plugins in halves on a staging copy, timing an admin page load each time. Twenty minutes and you have the culprit exactly, instead of a theory.
The usual offenders are security plugins scanning on page load, backup plugins checking status, analytics dashboards fetching remote data, and anything adding a widget to the dashboard. There is more on avoiding the next one in How to Choose and Vet WordPress Plugins.
Remote calls block the page
The cause people never suspect.
Plugins that contact an external service. A licence check, a news feed, an update check, do it during the request. When that service is slow or unreachable, your admin page waits for the timeout.
The signature is an admin that is usually fine and occasionally takes twenty seconds, with nothing in your own logs. Twenty seconds is a network timeout, not a database query.
Disable the dashboard widgets you do not read, and remove plugins whose remote calls you cannot control.
Check the autoload figure
Every option marked to autoload is read on every request, before WordPress knows which page it is serving, and the admin makes many requests.
Under 1 MB is fine; over 3 MB is a real problem. The usual cause is plugins you removed leaving their data behind. How to Clean Up and Optimize the WordPress Database goes into the query.
Object caching helps here specifically
Since pages cannot be cached, the gain has to come from making each page cheaper to build.
A persistent object cache: Redis or Memcached, stores query results between requests, which is the one caching layer that helps logged-in users at all. Understanding WordPress Caching Layers goes into what each layer does.
On a site with several editors working simultaneously, this is usually the largest single improvement available.
Post revisions and a large posts table
The post list and the editor both query the posts table, and revisions live in it.
An article edited thirty times is thirty-one rows. Across a site with years of content, that is a table several times larger than the content it holds, and every admin listing pays for it.
Limit revisions in wp-config.php and clear the accumulated ones:
define('WP_POST_REVISIONS', 5);
Heartbeat, and what it costs
WordPress polls the server while an admin screen is open: for autosave, for lock notices, for updates.
On one editor that is trivial. With several people in the admin at once, on a shared plan, it is a steady stream of uncached requests each occupying a process.
Slowing it down, rather than disabling it, is the sensible setting. Disabling it entirely loses autosave and the warning that someone else is editing the same post, which is a bad trade on a multi-author site. How to Monitor Your Hosting Resources walks through seeing the load it creates.
The media library at scale
A library of thousands of images is slow to browse because each thumbnail is a request and the grid view loads many at once.
Use list view for working, and keep the library trimmed: noting that a cleanup plugin can mistake a page-builder image for unused, so take a backup and review the list rather than accepting it. There is more in How to Optimize Images and the Media Library.
When it is the server, not WordPress
Two signs point away from the application.
The admin is slow at particular times of day and fine otherwise; that is a resource ceiling, and requests are queuing rather than running slowly.
Or everything is slow, including static files. That is the server or the connection, not WordPress.
On a small VPS, check whether the database is the constraint before tuning anything, and remember that past a point, tuning stops helping and the limit is the application. How to Tune MySQL or MariaDB on a Small VPS deals with that honestly.
What to do first
Check the autoload figure. Halve-and-test the plugins. Turn off dashboard widgets you do not read. Limit revisions. Then add object caching if editors are still waiting.
That order finds the cause in most cases before you have changed any infrastructure, which is the point, because a bigger server makes a heavy admin cheaper to ignore rather than fixed.
Measure the admin the way you would the front end
Reports of a slow administration screen are usually about one page, and identifying which one narrows the search immediately.
for p in /wp-admin/ /wp-admin/edit.php /wp-admin/upload.php /wp-admin/plugins.php; do
printf '%-26s %s\n' "$p" "$(curl -s -o /dev/null -w '%{time_starttransfer}' -b cookies.txt "https://example.com$p")"
done
A dashboard that is slow while the post list is fast points at the widgets, most of which fetch from elsewhere. The reverse points at the database and the size of the table being listed.
The media screen slow while everything else is fine is almost always the number of attachments combined with image sizes being generated on demand, which is a different fix from either.
Find what is being fetched during a page load
Remote requests made while a screen renders block it, and the screen waits for the slowest one.
wp eval 'add_filter("pre_http_request", function($r,$a,$u){ error_log("HTTP: ".$u); return $r; },10,3); wp_dashboard_setup();' 2>/dev/null
grep -c 'HTTP: ' ~/logs/example.com.error.log
grep 'HTTP: ' ~/logs/example.com.error.log | awk '{print $NF}' | sed 's|.*//||; s|/.*||' | sort | uniq -c | sort -rn | head
That records every outbound request made while the page builds. What appears is usually update checks, licence validation and news feeds, several of which are contacting servers that are slow or no longer exist.
A request to a host that does not answer waits for the timeout on every single page load. One plugin doing that makes the entire administration feel broken, and it is invisible from the front end.
Reduce what the screens have to count
Several administration screens are slow because of how much they summarise rather than because of any single fault.
wp db query "SELECT post_status, COUNT(*) FROM wp_posts GROUP BY post_status;" wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_type='revision';" wp db query "SELECT COUNT(*) FROM wp_comments WHERE comment_approved='spam';"
Revisions, trashed items and spam comments are counted for the badges on every load and contribute nothing. Clearing them is safe and frequently removes most of the delay on the list screens.
Where a table is genuinely large, reducing the number of items shown per page helps immediately and costs nothing. It is a per user setting, so it can be changed for the people who work in there without affecting anyone else. Cleaning up the database covers the wider tidy.