Slow admin, fast front end

When the public pages are fast and the admin is slow, you are usually not measuring the same thing twice. The public pages are being served from a cache; the admin is running your application on every click. The admin speed is the real speed of the site.

Confirm the cache is the difference

curl -sSI https://yourdomain.com/ | grep -i x-cache\ncurl -sSI https://yourdomain.com/admin/ -H 'Cookie: session=...' | grep -i x-cache

HIT on the first and BYPASS on the second is the whole explanation. See page caching and when it lies to you.

Then find what the application is actually doing

• Queries. An admin list view usually loads far more per row than a public page. See N+1 queries.
• An external call on page load - a licence check, an update check, a feed - where the dashboard waits on somebody else's server.
• A log or activity table that has grown and is now being counted on every page.
• Dozens of admin-only scripts, which is a browser problem rather than a server one.

Measure the split

curl -sS -o /dev/null -w 'ttfb %{time_starttransfer}  total %{time_total}\n' \\n     -H 'Cookie: session=...' https://yourdomain.com/admin/

A high TTFB is the server; a low TTFB with a slow total is the browser. That one line decides where to look and takes a second.

The usual culprit

SELECT COUNT(*) FROM wp_options WHERE autoload = 'yes';\nSELECT option_name, LENGTH(option_value) FROM wp_options\n WHERE autoload = 'yes' ORDER BY 2 DESC LIMIT 10;

Anything autoloaded is read on every single request. Several megabytes of it - left behind by a removed plugin - slows every page, and it shows up first in the admin because nothing there is cached.