Tickets about a slow WordPress dashboard usually describe the same thing: opening the page editor, saving a post or loading a list screen takes five to ten seconds. That is a different problem from an admin area that is simply not as quick as you would like, and it nearly always comes down to one or two specific causes rather than a general lack of tuning. This article splits those causes into what the server handles and what lives inside your WordPress install, so you know which side to look at and what to send us if you need a hand.
Diagnose before you change anything
The usual reaction to a slow backend is to start switching plugins on and off or to install another optimisation plugin. That makes the real fault harder to find. Work out what is broken first, fix it, and only then look at optimisations on top. If your site runs WooCommerce, some of the causes are different (orders, carts and customer data add their own load), but everything below still applies.
The server side
Connection protocol
HTTP/2 changes how quickly a browser can connect to a site and download its files, and it is a server setting rather than something WordPress controls. You can check it in your browser’s developer tools: on the Network tab, the Protocol column shows h2 or h3 for modern connections. If your own domain shows http/1.1, open a ticket. HTTP/3 is a smaller step beyond that; if your domain runs through Cloudflare, it is switched on in the Cloudflare dashboard.
PHP version
A PHP version that is too old or too new for your plugins produces errors on every admin page load, and errors show up as freezing and slowness rather than an obvious message. The aim is the highest PHP version your plugins support. If you are not sure which one that is, or want us to make the switch, ask in a ticket and we will note the current version so it can be rolled back.
Object caching
Object caching is a database cache. It needs Redis or Memcached running on the server plus an object caching plugin in WordPress. On a small site its absence will not make the dashboard slow; it matters on bigger sites and where several staff are editing pages, products or posts at the same time. Ask our support team whether it can be enabled for your site.
Scheduled tasks
By default WordPress runs its cron (background maintenance jobs) during page loads. On a site with many plugins those jobs can take anywhere from two to thirty seconds, so an unlucky admin page waits for them to finish. The fix is to set DISABLE_WP_CRON in wp-config.php and run cron from the server on a fixed schedule instead. This is a hosting task; open a ticket and we can set it up.
Inside your WordPress install
- Hidden errors. Install the free Query Monitor plugin. It adds a toolbar item that shows errors in red and warnings in brown, with the plugin responsible. Common culprits are abandoned plugins and paid plugins that sit outside the normal update system and need a manual download. Duplicated code in wp-config.php, or code left behind for a previous host after a migration, also shows up here.
- Page caching. Use one caching plugin, such as WP Rocket or FlyingPress, and check it has not been disabled. Cached front-end pages leave the server free to handle your admin requests.
- One of each optimisation. Two CDNs (for example Cloudflare plus the CDN option in WP Rocket) add an extra hop and slow things down. The same goes for two plugins doing the same job.
- Database format. Older sites often have tables on the MyISAM storage engine, which locks a whole table while it writes. InnoDB locks only the row being changed. The Servebolt Optimizer plugin converts tables and adds a few indexes; run it, then remove it. Take a backup first and do it outside busy hours. WP-Optimize shows table sizes, which helps spot a runaway log table, and can delete expired transients.
- 404 errors in the template. A missing file referenced in a header or footer is requested on every page and slows everything.
- Slow media uploads. Image compression plugins often compress each file as it is uploaded. Pause the plugin or switch it to scheduled optimisation and see if uploads speed up.
Traffic competing with you for the server
Brute force login attempts, aggressive SEO crawlers (Semrush, Ahrefs, Open Site Explorer, Dotbot) and Google crawling query strings all consume the same resources your admin session needs. Brute force traffic tends to arrive in bursts of several attempts per second. If your domain uses Cloudflare, firewall rules there stop much of this before it reaches our server. Wordfence’s free version adds a layer inside WordPress, though it runs on your hosting resources.
For crawled query strings, Google Search Console’s “Alternate page with proper canonical tag” report lists them, and they can be disallowed in robots.txt. Be careful: a typo in robots.txt can block pages you want indexed. If you add a country filter in Cloudflare, remember it can also catch uptime monitors, backup services and other tools that need access.
Changes that will not help
- Minifying or combining files does nothing for backend speed and can make it worse.
- Limiting the WordPress Heartbeat does not fix a slow admin and can break autosave and other features.
- Raising the memory limit only matters if pages are crashing with out-of-memory errors. More memory does not make pages faster.
- Removing dashboard widgets speeds up the dashboard page and little else.
- Caching admin pages risks stale data and overwritten content. Never do it.
What to include in a ticket
- Which admin screens are slow and roughly how long they take.
- When it started, and anything that changed around then: a plugin update, a PHP change, a migration.
- A screenshot of any red items in Query Monitor.
- Whether the domain is behind Cloudflare, and how many people edit the site at once.
With that we can check the PHP error log and access logs for errors and crawler activity that do not appear anywhere else. Stability comes before speed: we will not suggest an optimisation that risks data loss.