# WordPress admin slow? Heartbeat, autoloaded options, database bloat and admin plugins

> A slow WordPress admin is almost always the database, autoloaded options, the Heartbeat API or plugins that do heavy work on admin screens. How to find which one with Query Monitor and Site Health, and how to fix each.

Updated 2026-09-26 · WordPress & WooCommerce · HTML version: https://getreport.app/guides/wordpress-admin-slow

When the WordPress admin is slow but the public site is fast, the cause is almost never the theme or images. It is the server doing work that only happens for logged-in users: loading oversized autoloaded options, querying a bloated database, answering Heartbeat requests from open tabs, and running plugins that do heavy work on admin screens. None of it is cached, because the admin never is. This guide shows how to find which of these you have in about 20 minutes, and how to fix each one safely. It is part of our guide to [why a WordPress site is slow](https://getreport.app/guides/why-is-my-wordpress-site-so-slow), which covers the front end.

## Quick answer

- **Install Query Monitor** (on staging if you can) and open the slow admin screen. It shows the page generation time, slow database queries, HTTP calls to other servers and which plugin caused each.
- **Check autoloaded options** in Tools → Site Health. Since WordPress 6.6 it warns when autoloaded options exceed 800 KB; find the biggest ones and switch off autoload for those that don't need it.
- **Clean the database:** limit post revisions, delete expired transients, trim WooCommerce's Action Scheduler logs, and remove tables left by deleted plugins. Back up first.
- **Tame the Heartbeat API:** close idle admin tabs, and slow Heartbeat to 60–120 seconds outside the post editor.
- **Find admin-only heavy plugins:** SEO analysis, page builders, backup and security scanners, and dashboard widgets that call external servers.
- **Fix the server basics:** PHP 8.3 or newer, OPcache, and a persistent object cache (Redis or Memcached) if the host offers one.

## Why is my WordPress dashboard so slow?

Every admin page is built from scratch. A visitor gets a cached copy of a page in 100–300 ms on good hosting; an editor loading Posts → All posts waits for PHP to load WordPress, every active plugin, the full list of autoloaded options, and dozens of database queries. Anything that makes each request more expensive hits the admin first and hardest.

| Symptom | Likely cause | Where to look |
| --- | --- | --- |
| Every admin page is slow, even the empty dashboard | Autoloaded options, slow PHP, no object cache, or a slow host | Site Health, Query Monitor's overview |
| One screen is slow (Posts, Orders, Media) | Slow database query, often from a plugin adding columns or filters | Query Monitor → Queries by component |
| Dashboard slow, other screens fine | Dashboard widgets fetching news or stats from other servers | Query Monitor → HTTP API calls |
| Slows down over the day with many editors | Heartbeat requests from open tabs, PHP workers exhausted | Server logs for `admin-ajax.php`, host's resource graphs |
| Saving a post takes seconds | Plugins running on `save_post`: SEO analysis, cache purge, sitemap rebuild | Query Monitor on the save request |
| Slow after a plugin install or import | New autoloaded data or a large table without indexes | Autoload size, database size |

It helps to know whether the server is slow in general. The free TTFB test measures how long your server takes to answer a public page; if a cached public page is already slow, the host is part of the problem and the admin will be worse.

> **Free tool:** [TTFB test: check your time to first byte](https://getreport.app/tools/ttfb-test): Free TTFB test: measure time to first byte from Frankfurt, in a Lighthouse run and from real Chrome users, plus the redirects before the page. No sign-up.

> **Check: Time to First Byte.** TTFB is how long the server takes to start answering. Everything else waits for it, so a slow first byte makes every other metric worse. Google's 800 ms target is for real visitors, network included; Lighthouse flags the server's own share above 600 ms (see server response time).
>
> 1. Add page caching (WordPress: WP Rocket, LiteSpeed Cache, or your host's cache; Shopify does this for you).
> 2. Put a CDN in front (Cloudflare, Bunny) so the first byte comes from a nearby edge.
> 3. Check database-heavy plugins and slow hosting; a plan with more CPU often fixes this outright.

## Step 1: Measure with Query Monitor and Site Health

**Query Monitor** is a free plugin that adds a panel to the admin bar. Open the slow screen and read, in this order:

1. **Overview:** page generation time and peak memory. Over 1 second on a simple admin screen means something is wrong.
2. **Queries by component:** which plugin or theme ran the most and slowest database queries. Sort by time.
3. **HTTP API calls:** requests from your server to other servers during the page load. A dashboard widget or licence check that waits 2 seconds for a remote API adds 2 seconds to every load.
4. **Hooks and actions** on a slow save, to see which plugin's code runs.

Query Monitor itself adds a little overhead; deactivate it when you are done.

**Site Health** (Tools → Site Health) checks the server and WordPress configuration. Look at the Status tab for "Autoloaded options could affect performance", "You should use a persistent object cache" and the PHP version, and at Info → Directories and sizes for the database size.

## Step 2: Shrink autoloaded options

WordPress keeps settings in the `wp_options` table. Options marked for autoload are loaded in one query on every request, front end and admin. Plugins often store large data there, such as caches, logs or statistics, and some leave it behind when they are deleted. A few megabytes of autoloaded data slow down every single request and fill the object cache.

WordPress 6.6 improved this: options larger than 150 KB are no longer autoloaded by default when a plugin adds them without saying, and Site Health warns when the total autoloaded size exceeds 800 KB. Older data stays as it was.

Find the total and the biggest entries with SQL, in phpMyAdmin or `wp db query`. Replace `wp_` with your table prefix:

```sql
-- total autoloaded size in KB (WordPress 6.6+ values)
SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

-- the 20 largest autoloaded options
SELECT option_name, ROUND(LENGTH(option_value) / 1024) AS kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;
```

For each large option:

- **From a plugin you deleted:** remove it. The option name usually starts with the plugin's slug.
- **From an active plugin:** check the plugin's settings for a log or cache you can clear, and ask its developer whether it needs to be autoloaded.
- **Needed, but not on every request:** switch autoload off with `wp_set_option_autoload( 'option_name', false );` (available since WordPress 6.4), or with SQL: `UPDATE wp_options SET autoload = 'off' WHERE option_name = 'option_name';`.

Back up the database before deleting anything, and change one option at a time. Never touch core options such as `siteurl`, `home`, `active_plugins`, `cron` or `wp_user_roles`.

## Step 3: WordPress database optimization

A large database is not slow by itself, but some tables grow in ways that slow down the admin screens that query them.

**Post revisions.** WordPress keeps every saved revision of every post by default. A site with years of edits can have more revisions than posts. Limit new ones in `wp-config.php`:

```php
// wp-config.php, above "That's all, stop editing!"
define( 'WP_POST_REVISIONS', 10 );
```

Delete old ones with WP-CLI, after a backup: `wp post delete $(wp post list --post_type=revision --format=ids) --force`. On very large sites, do it in batches.

**Expired transients.** Transients are temporary cached values stored in `wp_options` when there is no object cache. Expired ones should be cleaned up, but often are not. `wp transient delete --expired` removes them.

**WooCommerce Action Scheduler.** WooCommerce and many plugins use the Action Scheduler, which keeps completed and failed actions and their logs in `wp_actionscheduler_actions` and `wp_actionscheduler_logs`. Completed actions are purged after 30 days by default, but failed ones and busy stores can leave hundreds of thousands of rows. Check Tools → Scheduled Actions for failures, fix what fails, and see our guide to [wp-cron and scheduled tasks](https://getreport.app/guides/wp-cron-and-scheduled-tasks) for running the queue outside visitor requests.

**Leftover tables.** Deleted plugins often leave their tables behind. List them with `wp db tables --all-tables` and compare against your active plugins. Drop only tables you are sure belong to a removed plugin, after a backup.

**Spam and trash.** Empty spam comments and trashed posts, and shorten automatic emptying with `define( 'EMPTY_TRASH_DAYS', 7 );`.

After a clean-up, `wp db optimize` rebuilds the tables to reclaim space. Database optimisation plugins can do all of the above from a screen; whichever you use, schedule it monthly rather than running it continuously.

## Step 4: Tame the WordPress Heartbeat API

The Heartbeat API keeps the admin in sync with the server. While an admin tab is open, the browser sends a request to `admin-ajax.php` at a regular interval: every 15 seconds in the post editor, for autosave and post locking, and every 60 seconds on other admin screens. Plugins hook into it for live notifications and dashboards.

One tab is harmless. Ten editors with five tabs each on a small hosting plan means a steady stream of uncached PHP requests, each loading all plugins and autoloaded options, competing for the same few PHP workers the admin needs. The symptom is an admin that gets slower during working hours.

What to do:

- **Close idle admin tabs.** It is the cheapest fix.
- **Slow Heartbeat down outside the editor.** The `heartbeat_settings` filter accepts intervals between 15 and 120 seconds:

```php
// In a small custom plugin or your child theme's functions.php
add_filter( 'heartbeat_settings', function ( $settings ) {
    if ( ! is_admin() ) {
        return $settings;
    }
    global $pagenow;
    if ( ! in_array( $pagenow, array( 'post.php', 'post-new.php' ), true ) ) {
        $settings['interval'] = 120;
    }
    return $settings;
} );
```

- **Leave it on in the post editor.** Disabling Heartbeat there switches off autosave and the warning that another user is editing the same post.

Most caching and optimisation plugins have a Heartbeat setting that does the same without code. Use one method, not both.

## Step 5: Find plugins that are heavy in the admin only

Some plugins cost almost nothing on the front end and a lot in the admin. The [WordPress plugin detector](https://getreport.app/tools/wordpress-plugin-checker) cannot see them from outside, because they load nothing for visitors:

- **SEO plugins** that analyse content on every edit and add columns to the post list.
- **Page builders** loading their editor and templates library.
- **Backup and security scanners** that run scans during admin requests instead of from cron.
- **Dashboard widgets** from plugins and hosts that fetch news, stats or licence status from remote servers on every dashboard load.
- **Analytics dashboards** that query large statistics tables or remote APIs.
- **WooCommerce admin** with large order and analytics tables; High-Performance Order Storage, the default for new stores since WooCommerce 8.2, keeps orders in their own tables and makes order screens faster than the old post-based storage.

Query Monitor's component view names them. Then: turn off features you don't use (content analysis, dashboard widgets under Screen Options), schedule scans from cron, or replace the plugin. Our guide to [what each WordPress plugin costs](https://getreport.app/guides/wordpress-plugin-cost) covers the front-end side of the same audit.

## Step 6: Fix the server basics

- **PHP version.** WordPress recommends PHP 8.3 or newer. Each major PHP release has made WordPress faster, and hosting panels switch versions in a click. Test on staging first.
- **OPcache.** PHP's bytecode cache should be on; nearly every host enables it. Site Health's Info tab shows the PHP extensions loaded.
- **Persistent object cache.** Redis or Memcached keeps database results in memory between requests. It helps the admin more than the front end, because the admin is never page-cached. Site Health recommends one when your host supports it; install the host's object cache plugin or a Redis object cache plugin.
- **PHP workers and memory.** Plans with very few PHP workers queue admin requests behind each other. If Query Monitor shows fast page generation but the admin still feels slow, the wait is before PHP starts: that is the host. Our guides to [server response time on shared hosting](https://getreport.app/guides/server-response-time-on-shared-hosting) and [choosing a WordPress host by measured TTFB](https://getreport.app/guides/choosing-a-wordpress-host-by-measured-ttfb) help decide.

> **Check: Speed against other sites on your host.** Comparing your server with other sites on the same host shows where a slow first byte comes from. When most sites on the host answer faster, the host is not the limit; slow plugins, missing page caching or an undersized plan usually are. The numbers are anonymous, from sites we checked, and appear only once a host has 50 sites.
>
> 1. Turn on full-page caching first; it removes most of the server's work for repeat visits.
> 2. Profile the slowest plugins or database queries (Query Monitor on WordPress) and remove or replace them.
> 3. If the site is already cached and lean, ask the host for a larger plan or move to a faster one.

## How to verify

1. Note Query Monitor's page generation time and query count on three screens (Dashboard, Posts, one heavy screen such as Orders) before you start.
2. Make one change at a time and re-measure the same screens, logged in, with the same number of tabs open.
3. Check Site Health again: the autoload warning should be gone.
4. After a week, ask editors whether saving and list screens feel faster during busy hours.

## Common mistakes

- **Installing a "speed" plugin for the admin.** Page caching does nothing for logged-in users; the admin needs the fixes above.
- **Disabling Heartbeat everywhere,** which breaks autosave and post locking.
- **Deleting options or tables without a backup.** A wrong row can take the site down.
- **Running a database optimiser on every page load** or every hour. Monthly is enough.
- **Testing admin speed with Query Monitor left on in production** for months.
- **Blaming WordPress core** before checking plugins: on a default install with a default theme, the admin is fast.

## Questions people ask

### Why is my WordPress dashboard so slow but the website fast?

Because visitors get cached pages and you do not. The public site is served from a page cache in a fraction of a second, while every admin screen is built from scratch by PHP and the database, with all plugins and autoloaded options loaded. Heavy autoloaded options, a bloated database, Heartbeat requests and admin-only plugins all add to that. Query Monitor shows which one costs the most.

### Should I disable the WordPress Heartbeat API?

Not completely. Heartbeat powers autosave, post locking and login expiry warnings in the editor, so turning it off there risks lost work and two people overwriting each other. Slow it to 60–120 seconds on other admin screens instead, with the heartbeat_settings filter or your optimisation plugin's setting, and close admin tabs you are not using.

### How big should autoloaded options be in WordPress?

Under about 800 KB, which is the level at which Site Health has warned since WordPress 6.6, and well under that on a healthy site. Autoloaded options load on every request, front end and admin, so a few megabytes slow every page. Find the largest entries with a SQL query, delete those left by removed plugins, and switch off autoload for data that is not needed everywhere.

### Does cleaning the database speed up WordPress?

It can, when specific tables have grown out of control: autoloaded options, hundreds of thousands of revisions, expired transients or Action Scheduler logs. Then admin screens and saves get noticeably faster. Removing a few thousand rows from a healthy database changes nothing you can measure. Measure with Query Monitor first, back up, clean the tables that are actually large, then measure again.