WebGee DocsDocs
WordPress

Improve a slow WordPress or WooCommerce dashboard

Find what is actually making wp-admin slow, then fix it — in the order that finds the cause fastest rather than a list of everything possible.

A slow dashboard is usually the site, not the server. wp-admin is not cached, so every click runs PHP and queries the database — which means it exposes problems the cached front end hides. Applies to all shared and reseller hosting.

Work through this in order. The first two sections find the cause on most sites; the rest are worth doing anyway but rarely the answer on their own.

1. Measure before changing anything

Install Query Monitor. It shows, for the page you are on, how long it took, how many database queries ran, which were slowest, and which plugin issued them.

Without it you are guessing, and the usual result is a dozen changes with no idea which one helped.

PHP X-Ray, in cPanel, does the same from the server side and can profile a request without installing anything into WordPress. See Diagnose a slow website with PHP X-Ray.

2. Find the plugin

One badly-behaved plugin causes most slow dashboards. Query Monitor usually names it outright.

If not, deactivate plugins one at a time, testing the dashboard after each. Start with anything that adds admin columns, runs background scans, or reports statistics — those run on every admin page load.

Do this on a staging copy if the site is live. Deactivating a plugin on a WooCommerce store can affect checkout.

3. Fix the common culprits

Cache plugin clearing constantly. Many cache plugins purge and rebuild the whole cache whenever a post or product is saved. On a store updating stock, that is continuous. Turn off automatic full-cache clearing and schedule a purge once a day instead.

WP-Cron on every page load. By default WordPress checks for scheduled tasks on every request. Disable it and run a real cron job instead — see Stop LiteSpeed cutting off long-running PHP scripts.

The Heartbeat API. WordPress polls the server every 15–60 seconds from any open admin tab. Limit it on the front end and dashboard, and leave it running in the post editor where it powers autosave and lock detection.

Sessions and transients. If wp_options is growing quickly, WooCommerce customer sessions and expired transients are usually why — often created by bots. Clear them, then see Optimise your WordPress database.

4. Give it more resources

Raise the memory limit. WooCommerce recommends 256 MB; our plans allow up to 1 GB. Set it in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Use a current PHP version. Newer PHP releases are substantially faster. Check the version under WooCommerceStatus, and change it in cPanel's MultiPHP Manager. Use a supported release — PHP 8.0 and earlier no longer receive security updates.

Enable OPcache. It caches compiled PHP so it is not recompiled per request. Find it in cPanel under PHP extensions.

Enable Redis. An object cache keeps repeated database results in memory, which is exactly what a query-heavy dashboard needs.

5. Reduce what the dashboard has to do

Remove WooCommerce features you do not use. The Disable WooCommerce Bloat plugin turns off marketing dashboards, the admin analytics tables and similar.

Clean the database. Old plugins leave tables behind. WP-Optimize removes them; back up first.

Reconsider your page builder. Builders add substantial CSS and JavaScript to the editor. If the slowness is specifically in the editor rather than across wp-admin, this is likely the cause.

Things that will not help

Caching wp-admin. Some plugins offer it. Do not — you will see stale order counts and stock levels, and act on them.

Cloudflare Argo Smart Routing. It improves dynamic request routing and is worth considering, but it is a paid add-on and it does not address a slow dashboard whose cost is PHP and database time on the server. Fix the cause first.

Moving wp-login.php. Worth doing to reduce bot traffic, but it is a security measure, not a performance fix.

Verify

Re-check with Query Monitor on the same page you started from. Compare generation time and query count against what you recorded in step 1.

On this page