Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

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.

Describe my issue Send a message

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.

Related pages

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

pages
constructeur
extensions
hebergement (facultatif)
mesure (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.

Related pages