Slow WordPress Admin? How to Find the wp-admin Bottlenecks and What’s Changing in Script Loading

A slow WordPress admin is a different complaint from a slow site for visitors: the public page loads fast, PageSpeed is green, yet whoever publishes content, handles orders or updates plugins waits several seconds on every click. The explanation is simple. Visitors almost always get a page served from cache; the dashboard never does. Every wp-admin screen runs PHP, queries the database and downloads dozens of scripts and stylesheets.

This article shows how to trace where the time is going and covers a change the core performance team started shipping this week: the mechanism the dashboard uses to load its scripts — the same one for more than fifteen years — is being replaced.

First step: locate where the slowness comes from

“The dashboard is slow” can mean three distinct problems, each with its own fix. Open your browser’s developer tools (Network tab), reload an admin screen and look at the first row, the HTML document:

• Long wait on the document (TTFB): the server is taking too long to build the page. The problem is in PHP, the database or external calls.
• Fast document, but many slow files: the bottleneck is script and stylesheet loading, or the lack of browser caching for them.
• Everything fast, but admin-ajax.php requests piling up: that’s the Heartbeat API or a plugin running background requests.

Without this first diagnosis, the usual path is installing an optimization plugin that touches everything and fixes nothing.

The most common causes of a slow WordPress admin

Too many autoloaded options

Every request to WordPress, public or administrative, loads in one go all options flagged as autoload in the wp_options table. Old, poorly written or already removed plugins leave data there that nobody uses anymore. Since WordPress 6.6, Site Health reports a critical issue when that set exceeds 800 KB, and options larger than 150,000 bytes are no longer autoloaded by default.

To list the largest ones with WP-CLI:

wp db query "SELECT option_name, LENGTH(option_value) AS bytes
FROM $(wp db prefix)options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY bytes DESC LIMIT 20"

Before changing any option, find out which plugin it belongs to and back up the database. The wp doctor package, maintained by the WP-CLI team itself, ships a ready-made check (autoload-options-size) that warns above 900 KB, along with other useful ones: more than 50 scheduled cron jobs, more than 80 active plugins.

Plugins that call external services on every screen

License validation, news feeds, stats, promotional notices: many plugins fire HTTP requests to third-party servers while the dashboard loads. If the remote server is slow, your dashboard is slow with it.

The tool to see this is the Query Monitor plugin. It shows database queries by component, duplicate queries, HTTP API calls with their duration and the plugin responsible, plus the hooks that ran. Use it on staging or for a limited time in production, and deactivate it when you’re done.

Heartbeat API with many open tabs

The Heartbeat API keeps the browser talking to the server: it’s what powers autosave and stops two people from editing the same post at once. The cost is a POST request to admin-ajax.php every 15 to 60 seconds, per open tab. None of those requests can be served from cache, and each one takes up a PHP worker. A team of five people with three tabs each already means constant load on a modest hosting plan.

Turning Heartbeat off entirely breaks autosave. The sensible adjustment is to lengthen the interval:

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

A server with no headroom

The dashboard gets nothing from page caching, so it depends directly on three things: a current PHP version with OPcache enabled, the number of PHP workers available, and a persistent object cache (Redis or Memcached), which avoids repeating database queries. If the diagnosis points to high TTFB even with few plugins, that’s a conversation to have with your host.

What’s changing in wp-admin script loading

For more than fifteen years, the dashboard has bundled core scripts and styles into a few large files, assembled on the fly by two PHP endpoints: load-scripts.php and load-styles.php. Back then the approach made sense, because every HTTP request was expensive. Today the technique has known costs, documented in Trac ticket #57548:

• each screen gets a different bundle, which keeps the browser from reusing its cache from one screen to the next;
• building the bundle uses server memory; one hosting provider recorded peaks of 1.9 GB, and there are reports of 503 errors in the editor on servers with less than 1.5 GB;
• the two endpoints are an attack surface that security plugins often restrict;
• both suppress PHP errors, which makes debugging harder.

The counterpoint, noted in the same ticket, is that bundling files still tends to be faster on a first visit, when the browser has nothing cached. Simply disabling concatenation would make that first load slower.

The fix: prefetching the next screen’s files

In the performance chat summary of October 6, 2026, Weston Ruter announced that prefetching has been committed to core (changeset 64120). The new wp_prefetch_admin_assets() function, tagged for version 7.2, prints <link rel="prefetch"> tags for the files of the screen the user is most likely to open next. It works in two places: on the login screen, anticipating the dashboard, and on the Dashboard and post list tables, anticipating the editor’s stylesheets.

The numbers published in the pull request (Chrome, local environment, median of 10 runs) explain why the two changes go together:

These are the author’s measurements in a single browser with a simulated network. Treat them as a sense of direction, not a promise for your server.

The announced next step is to turn concatenation off by default outside development environments and, after that, remove the two endpoints. As of this writing, that part was still under review. WordPress 7.2 Beta 1 is scheduled for October 20 and the final release for December 8; whatever doesn’t land by the beta moves to the next cycle. We covered the rest of the release in what’s coming in WordPress 7.2.

The detail that depends on your server

The same pull request includes a test worth your attention. With no explicit caching headers, after 241 seconds only 6 of 24 prefetched files were reused from cache; the rest were revalidated. With Cache-Control: max-age=31536000, all of them were reused.

In other words: the benefit of the new model depends on your server sending long cache headers for the static files under /wp-admin/ and /wp-includes/. It’s worth checking now:

curl -sI https://example.com/wp-includes/css/dashicons.min.css | grep -i cache-control

If nothing comes back, or the lifetime is short, the fix belongs in your web server or CDN configuration.

Can you test this before 7.2?

Yes. Concatenation can already be disabled with a constant that has existed for many years:

// wp-config.php
define( 'CONCATENATE_SCRIPTS', false );

It’s a classic troubleshooting step when the dashboard shows up unstyled or returns a 503 error on load-scripts.php. On staging, it reveals how your dashboard behaves with separate files: whether the cache headers are right, whether the server uses HTTP/2 and whether any plugin relies on the old behavior. Without the 7.2 prefetch, the first load tends to be a little slower, as the table shows.

Where do AI agents fit in?

An agent operating the site through the REST API or MCP doesn’t load dashboard scripts, but it competes for the same PHP workers, the same database and the same autoloaded options. A backend that barely keeps up with five editors won’t serve five editors plus an agent firing dozens of calls per minute. Getting the dashboard in order is also preparing the ground for automation.

Conclusion

A slow dashboard rarely has a single cause, and it’s almost never solved with one more plugin. The way forward is to measure: separate server time from loading time, look at autoloaded options, external calls and Heartbeat, and only then act. The script loading change that starts arriving with 7.2 helps, as long as the server is configured to make use of the cache.

If your WordPress dashboard is getting in your team’s way, Amicatek can run this review for you. Request an assessment of your site and get a list of what’s weighing it down and what to fix first, or take a look at our WordPress maintenance plan, which includes this kind of monitoring on an ongoing basis.

Sources

• Performance Chat Summary: 6 October 2026 — Make WordPress Core
• Ticket #57548: Stop concatenating scripts and stylesheets in wp-admin — WordPress Trac
• Pull request #13084: Script Loader: Prefetch assets for the next admin screen — wordpress-develop
• WordPress 7.2 release schedule — Make WordPress Core
• Options API: Disabling autoload for large options — Make WordPress Core
• Default doctor diagnostic checks — WP-CLI Handbook
• Taming the Heartbeat API — Delicious Brains
• Query Monitor — WordPress VIP Documentation