Performance

Diagnose a slow wp-admin dashboard when the frontend is fine

A scenario prompt for an 8-second wp-admin dashboard load on a site where the public pages are fast and fully cached, pointing at admin widgets, Heartbeat, and admin_init hooks instead of frontend fixes that won't help.

Works with Claude / GPT220 uses 3.9

The prompt

performance-slow-wp-admin-dashboard
A client keeps saying "the site is slow," but the public-facing pages load in under a
second per GTmetrix, fully served from page cache. The problem is specifically the
wp-admin dashboard screen, which takes 8 seconds to become interactive after login.

ACTIVE PLUGINS: [Jetpack, Yoast SEO, WooCommerce with the Analytics dashboard widget
enabled, a page builder]
QUERY MONITOR NOTES: [dashboard page fires 60+ admin-ajax.php calls in the first 10
seconds; WooCommerce Analytics widget query alone takes 2.1s; Jetpack's "At a Glance"
widget makes an external HTTP request to a stats API]

Diagnose this as backend-specific, since frontend caching advice is irrelevant here:
1. Explain why frontend page caching does nothing for this problem, wp-admin is never
   served from a page cache, so the fix space is entirely different: reducing what
   runs on that screen, not caching its output.
2. Identify the two most likely offenders from the notes: the WooCommerce Analytics
   widget's uncached query, and Jetpack making a live external API call that blocks
   rendering until it times out or responds.
3. For each, give the exact fix: disabling or lazy-loading the WooCommerce Analytics
   dashboard widget via remove_meta_box, or configuring Jetpack to trim which modules
   run on the dashboard screen.
4. Address the Heartbeat API's role in the 60+ admin-ajax calls: whether the interval
   needs slowing down on the dashboard screen specifically, versus disabling it
   outright, which would break post-locking and autosave for content editors.
5. Note which of these are pure wp-admin/plugin-settings fixes versus, if the real
   bottleneck turns out to be database query time under load, a case for checking
   with hosting on slow query logs or PHP worker contention during business hours.

“The site is slow” almost always means the frontend to a client and the backend to whoever’s actually complaining about it, so the first job here is confirming which one before applying any fix. Frontend performance advice wastes a support ticket if the real problem is a dashboard widget nobody remembers enabling.

Bring your own Query Monitor output from the dashboard screen specifically (not the homepage) for a precise read on what’s actually running there.