AdminVelox · WordPress admin performance audit

Why your WordPress admin is slow

wpadminperformance.com

measured: 2026-09-11
method: median of 5 loads per screen, measured from inside the site
access used: a plugin installed by you. No FTP, no SSH, no database, no hosting panel
changes made: none. This audit reads only

What this comes down to

Plugins screen is the slowest screen you use, at 2.68 s.
Your public site answers in 0.10 s. The admin is 26× slower, because page caching never applies once you are logged in.
Most database time on that screen comes from wordpress-seo.
About 394 ms of one admin page load is spent waiting for other servers to answer.
Several things people usually blame are not the cause here. They are listed below so you do not pay to fix them.

Measured load times

Screen	Median	Verdict
Front end (home page, logged out)	0.10 s	good
Plugins screen	2.68 s	clearly slow
Users	2.25 s	clearly slow
Dashboard	2.22 s	clearly slow
Pages list	1.11 s	slow
Posts list	1.05 s	slow

Good is 0.6 s or under, which is the threshold WordPress core itself uses. Slow is up to 2 s. Clearly slow is above that.

Findings

Plugins screen takes 2.68 s to load

Measured as the median of 5 loads. WordPress core treats 0.6 s as a good server response time, so this screen is 4× over that mark.

The admin is 26× slower than the front end

The public site answers in 0.10 s because it is cached. Page caching never applies to logged-in admin screens, which is why visitors see a fast site while you do not.

wordpress-seo accounts for the largest share of database time

11 queries and 109 ms of database time on a single dashboard load. This is the plugin to examine first, not necessarily the one to remove.

394 ms of a single admin load is spent calling other servers

2 outbound HTTP requests run while the page is being built, the slowest being https://api.wordpress.org/core/browse-happy/1.1/ at 298 ms. The page cannot finish until they answer, and no front-end speed tool reports this.

No persistent object cache

Without Redis or Memcached, every admin request rebuilds the same option and metadata lookups from the database. This is usually the single largest available improvement, and it requires server-side provisioning.

OPcache status could not be read from inside the site

The host restricts the API. This is not a fault, it just means this part has to be checked at server level rather than measured here.

Where the database time goes

One instrumented load of the dashboard screen, 131 queries in 227 ms. An instrumented load is always slower than a normal one, which is why the table above uses uninstrumented measurements instead.

Source	Queries	Database time
wordpress-seo plugin	11	109 ms
elementor plugin	38	38 ms
wordpress core	31	34 ms
gt3-themes-core plugin	15	15 ms
flying-press plugin	9	11 ms
gt3-photo-video-gallery-pro plugin	8	5 ms
wordpress-seo-premium plugin	4	4 ms
revslider plugin	4	3 ms

Calls to other servers during one admin load

Request	Made by	Time
https://api.wordpress.org/core/browse-happy/1.1/	wordpress	298 ms
https://assets.elementor.com/mixpanel/v1/mixpanel.json	elementor	96 ms

What is not the problem

This section is here so that you do not spend money on the wrong thing.

The public site is fast at 0.10 s. Front-end optimisation would not change what you experience in the admin.
Autoloaded options are 170 kB, comfortably under the 800 kB limit. This is not a cause here.
No overdue scheduled tasks. Background work is keeping up.
PHP 8.2.28 is current. An upgrade is not what is needed.

What to do, in this order

Stop the outbound calls made during admin page buildslow risk
They can be deferred or cached without changing how anything behaves.
Examine wordpress-seo on the dashboard screenanalysis only
Measure with it disabled on a copy of the site, never on production, to confirm the share before deciding anything.
Add a persistent object cachemedium risk, server work
Usually the largest single improvement. Requires Redis or Memcached on the host and careful invalidation.
Re-measure with the same tool after each changeno risk
One change at a time, same screens, median of five loads. Otherwise you cannot tell which change did what.

Do not touch these without a plan

Payments, orders, webhooks, any accounting or ERP connection, and point-of-sale integrations. A faster admin is not worth a broken order flow. If a change would affect any of these, it belongs in a separate, tested piece of work.

What this audit cannot see

Said plainly, because an audit that hides its limits is not an audit.

Server-level facts: how the PHP processes are configured, whether the machine is oversold, and what the slow query log contains.
OPcache across all sites on the same server, which one site cannot observe.
What the browser does after the page arrives. These numbers are server response times, not the full experience.
Anything that happens only under load, at a particular hour, or for a particular user.