# The wp-admin dashboard is very slow

> A fast public shop and a sluggish dashboard don’t share the same causes: a different set of mechanisms plays out behind wp-admin, involving the Heartbeat API, options loaded on every request and a missing object cache, independent of whatever makes the front end fast or slow.

- Source canonique : [https://allaux.fr/en/wordpress-woocommerce/problemes/admin-wordpress-tres-lent](https://allaux.fr/en/wordpress-woocommerce/problemes/admin-wordpress-tres-lent)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Open Tools > Site Health to note the PHP version and the memory limits, then measure the size of the wp_options rows whose autoload is set to yes: that block is re-read on every wp-admin screen. If the dashboard is still slow, space out the Heartbeat API calls to admin-ajax.php and clear the backlog of scheduled actions.

## How I go about it

1. **Scoping the problem** — I confirm the slowdown specifically affects wp-admin and wc-admin, by comparing against the public site’s load time at the same moment.
2. **Checking the Heartbeat API** — I check how often admin-ajax.php is called, by default every 15 to 60 seconds on every open wp-admin tab, and its effect on a host with a limited number of PHP-FPM workers.
3. **Auditing autoloaded options** — I measure the size of wp_options rows with autoload set to yes: this data loads on every request, admin and front end alike, and builds up over years of plugin installs.
4. **Checking the object cache** — I check whether an object cache (Redis or Memcached) is in place. Without one, WooCommerce screens such as the Orders list or Reports re-run costly SQL queries on every load.
5. **Targeted fix** — Depending on what dominates, I tune the Heartbeat frequency, clean up stale options, set up an object cache, or rewrite a query specific to an admin screen that’s become too heavy.

## What I handle regularly

- The public shop loads fast, but wp-admin takes several seconds on every click
- The Orders list takes an unusually long time to load, especially after applying a filter
- The WooCommerce Analytics screen spins for ages before showing any numbers
- Having several wp-admin tabs open visibly slows down the rest of the site
- The slowdown gets worse year after year with no recent plugin changes

## What specifically slows the admin down

The Heartbeat API polls admin-ajax.php by default every 15 to 60 seconds on every open wp-admin tab, for autosave, notifications and session checks. On a host with a limited number of PHP-FPM workers, just a few tabs open at once are enough to visibly slow the whole admin down.

wp_options rows marked autoload=yes build up over years of installing and removing plugins, and some plugins never clean up after themselves. This set of options loads in full on every request, admin and front end alike: the heavier it gets, the slower every page becomes, quietly but consistently.

Without an object cache (Redis or Memcached), WooCommerce admin screens, particularly the Orders list and Analytics reports, re-run non-trivial SQL queries on every load instead of reusing an already computed result. Reports screens aggregate the entire order history: on a catalogue with several years of sales, that can genuinely get heavy without a proper index or cache layer.

## Server configuration, or a query to rewrite

> Setting up an object cache and trimming autoloaded options is server configuration work. Rewriting the query behind a specific admin screen that’s become too heavy on a large catalogue is development.

## Related pages

- **Slow WooCommerce site** — A slow public site follows different causes than wp-admin: page cache, images, front-end queries. ([/wordpress-woocommerce/site-lent](/wordpress-woocommerce/site-lent))
- **Maintenance contract** — Regular upkeep prevents stale options and unused plugins from piling up for years. ([/services/maintenance](/services/maintenance))
- **All WooCommerce work I handle** — Other faults and features I handle on WooCommerce. ([/wordpress-woocommerce](/wordpress-woocommerce))

## FAQ

### Why is my public site fast but not wp-admin?

Because they’re driven by two different sets of mechanisms. The front end mostly depends on page cache and images; the admin depends on the Heartbeat API, options loaded on every request, and the object cache.

### What exactly is the Heartbeat API?

A native WordPress mechanism that polls the server at regular intervals from every open wp-admin tab, for autosave and notifications. Its default frequency can be reduced or limited to specific screens.

### Is an object cache hard to set up?

It depends on the host: some enable it with one click, others require installing Redis or Memcached at server level, out of reach without technical access.

### Can I fix this myself?

Tuning the Heartbeat or enabling an object cache offered by the host is within reach of a generalist. Diagnosing a slow query specific to a WooCommerce screen needs a code-level read.

### Why is Analytics the slowest screen of all?

Because it aggregates the entire order history on every load. On a catalogue with several years of sales, without a proper index or cache, it’s the most SQL-costly screen there is.