10 proper ways to mitigate your slow WP-admin backend.

If you’re frustrated with a slow backend taking forever to click from one page to the next, trust me I hear you. Frontend pages are so much easier to cache but the backend is not.

Does that mean you’re forever cursed with miserable backend load times, and admin functions that take forever?

NO!…ok, maybe…but I’ll help you make the best of your options.

The CAUSE of slow backends

Backends are slow because they’re completely dynamic.

And by “dynamic”, I mean that they have to query the database for every page request. The database is called up and every bit of information is requested from scratch as if its never seen it before. There’s zero caching applied.

It also doesn’t help that the backend sometimes shows more info. What users, what content, what comments, how many sales, etc. It often calculates info that isn’t even being shown. There’s also the heartbeat API running constantly in the background to auto-save your edits.

Databases can also get slower as they grow in size. Just like how finding things in your house becomes harder when you have more things. Databases take longer when you start looking for very complicated data that’s buried or organized in complex and/or inefficient ways.

Knowing this…let’s see how we can optimize these dynamic backend requests to speed up your WP-admin experience.

1. Audit your plugins

Anytime someone comes to me for help with a slow backend, they are immediately “guilty until proven innocent” to me.

Check all your plugins and see which ones are contributing to this god awful slow-ass backend load.

“But how?!”

Like this…

1. Deactivate some non-essential ones to see if it runs faster. Then deactivate some more. Keep going until you get to the point of having no plugins activated. I’m sure you’ll have an idea which ones it is by now.
2. You should also check your theme. With all your usual plugins activated, try switch themes to the default theme for a second. Did it help?

Hahaha, I’m kidding…ignore those first 2 steps (don’t wreck your live site) and do it like a pro. Install Query Monitor and then surf some pages from frontend while studying the diagnostic panel at the bottom of your browser. There’s only two things you need to check—Slow Queries, and Queries by Component. Those two alone will tell you which themes, plugins, or queries are causing the biggest delays. You should also take note of the memory use (on your top admin bar) and how many queries each plugin makes.

Once you find out what’s causing it…you ought to replace them!

• Slow slider plugin? – get a new slider plugin!
• Slow theme? – get another theme!

Some of you are going to have attachment pains letting go of your precious plugins…but I promise you this…whatever bullshit crap-code plugin you have lagging your backend, there’s a good chance a higher quality developer-grade one exists and without any the slow query nightmares.

2. Check for errors

• Error.log – find it in your public_html directory and look inside. Do you see lots of errors?
• Console errors – open up developer tools and see if there’s any obvious 404 requests.

It’s usually not so much the errors that are causing the problem, but the plugins related to those errors that are.

3. Check for high memory use

Three things you need to know:

1. How much memory your entire site uses. (Try WP Server Health Stats)
2. How much memory your theme and plugins use. (From Query Monitor)
3. How much memory your autoloads use.

From here, we have a couple tactics.

Of course, you can try increasing your site memory limits. Add the following lines below to your wp-config.php file above the line that says “That’s all, stop editing! Happy blogging.”:

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

The first one increases memory use for the frontend, the second one increases for the backend. For most well-built sites, you don’t need either. You can even raise the 2nd one to 512mb or even higher but here’s the thing…that limit is still restricted by the server’s global PHP memory limit. If you have your own VPS server, you can set as high as you want. If you’re on a crappy shared host, it’s probably very limited and trying to set it higher won’t do anything.

If it needs to be said, you should get rid of plugins that are eating up so much memory. And please don’t forget to check your autoloads. Quite often, there are many old themes or plugins you don’t have any more that are still eating up your memory! They sit around in the database loading their indexes even when there’s no plugin using them!

4. Upgrade your web-hosting (or web-server)

Did you replace all your bloated plugins?!

• NO?!
• WHY NO? Because you wanted to save money?

Well today, you get to spend that money you saved on better hosting. Sorry buddy, you have to pay for a quality experience!

Ok, let’s be fair…maybe some of you did replace your plugins. Or you saw that your plugins weren’t the problem!

The answer is the same…the easiest hassle-free way from this point is to get a better webhost or stronger web-server. Keep in mind, I didn’t say go get a MORE EXPENSIVE webhost. No!

Whatever tier of webhosting you’re in (shared hosting, VPS, etc), I guarantee there’s probably another one that’s better and not that far away in price.

But be careful..this simple bailout button doesn’t work like you think. The new server you get can’t just be more expensive or bigger, it actually has to give your site more resources! Just because you’re going with a bigger or stronger server doesn’t mean your site automatically gets access to more CPU and MEMORY. I’ve seen many people upgrade and pay double and still not get better performance.

• You can read my Best WordPress Hosting Reviews.

What should a good server have?

Hard to say because any specs or stats I give you could be easily lied about through false marketing (just like how you got into your current predicament). The easiest way is to feel if it’s fast or not.

But if you insist, it’s good to know if they have the latest PHP and MySQL. Fast hard drives with good disk I/O rates. And aggressive settings. Also good to have decent PHP memory limits.

5. Decrease heartbeat API interval

This is low-hanging fruit and can get some mild results without much effort. There are some specialized plugins that do this, like Heartbeat Control…but it’s much better if you could use it from your caching plugin (like Swift, Rocket, LiteSpeed).

My recommendations below:

• You can (probably) safely disable heartbeat on all pages frontend and backend except for the post editor.
• Don’t disable it from the post editor because the Heartbeat is used there to do auto-saves.
• If you have many writers logging in and working at the same time, fine you can lengthen the Heartbeat interval for the post editor, but still do not disable it!
• Click here to learn more about WordPress Heartbeat API.

6. Object caching

I’m sure you’ve heard of buzzwords like “Memcache” and “Redis” before. Redis (being the better and standard one nowadays) is a server module that allows you to cache your database queries. It’s very fast, since it saves that info in memory rather than on the disk (like typical page caching).

There are many caveats and variables to think about…I’ll leave general recommendations below and you can research the rest if curious:

• Object caching needs lots of memory. Therefore, it’s usually only allowed with VPS plans and almost never on shared hosting. Even if your shared hosting does allow object caching, it’s probably neutered.
• A good object cache expiry time is anywhere from 5-60 minutes. Too short and the cache expires before you get to benefit from it. Too long and your dynamic content is outdated until the object cache expires (but maybe that’s ok with you).
• Object caching acts like page caching but with shorter cache “benefit” times. The first few hits are slow, subsequent hits are fast until the cache expires (and needs to be rebuilt).
• Object caching helps if you work around in the backend a lot. If you’re only in and out a couple minutes each day, you’re probably faster without object caching.

It case you’re wondering, it’s called object caching because it caches the database queries (aka “database objects”)…which allows you to retain most of your dynamic functionality but benefitting from faster speeds (since some queries are already built and don’t have to be looked up on each click).

7. Caching admin-areas and logged-in users.

Alright, this is flat out desperation mode here. It’s mostly a bad idea but can work in some situations. Here’s when it does and doesn’t help:

HELPS if…

• You have many logged-in users.
• Your logged in users see mostly static content.

DOESN’T HELP if…

• You don’t have many logged-in users.
• All of your backend is completely reliant on live dynamic data.

If you really think about it, caching only helps you load repeated content faster. If you don’t have any static backend content or enough users to benefit from it, then caching the admin area isn’t gonna be much use IMO. If anything, it’ll make your site even slower! (Slower because your server resources are now wasted for building and purging cache that isn’t even used.)

HOW to cache the backend?

Enable the following features in your cache plugin:

• Cache admin area – should be easy enough.
• Cache for logged-in users – you may have to decide which areas are public vs private. Public means all users see the same content. Private means all users see different content (like their “Account” pages).
• ESI cache – can play with this hole-punching technology but I warn you that it’s not for DIY people. You need a developer to do this right. If you use LiteSpeed server and caching, the easiest way to use ESI is if your content is deployed via shortcodes or in a widget.

8. Check your security plugin

Do you have Wordfence or Sucuri? Well, you don’t have to get rid of them but do know that they slow down the backend a lot. Since they check every page load for hack executions and what not.

Sure, you might have seen guides telling you to slow down the scanning…but really, it won’t matter much. It’s because of those security plugins logging every page load, and checking for potentially bad code executions.

9. Prevent unnecessary plugin load on backend

Welcome to the “joy” of asset load management. Here, we disable all unnecessary CSS/JS calls from the backend.

I take back what I said about the previous step. There IS a step even more desperate than the previous. I used to try and optimize to this degree but I realized it’s stupid. Your life is more valuable than wasting time doing this. There is no point whatsoever…this is like cleaning the bottom of your shoes the night before you go mud-running the next day.

You should have NEVER had to do this.

• You should had a quality theme.
• With quality plugins.
• On a good web server.
• And with your autoloads cleaned up of any cruft left from old themes/plugins.

If you’re here trying to time-travel your life away switching CSS/JS assets on and off…it’s because you were being stubborn about a previous step. I urge you to go back and do everything else. You’ll end up doing so much more work here than you would just replacing your themes/plugins. AND you might inadvertently break your site or affect future operations and forget that you disabled something.

Still want to go forward with this? *Sigh* Ok, you win. Recommendations below:

• I prefer Asset CleanUp: Page Speed Booster over all the other asset loaders or plugin organizer plugins out there.
• Perfmatters can be nice as well.
• WP Gonzalez and Plugin Load Filter are also ok as well.
• The rest are either 1) too complicated and poor UI to use, or 2) they add their own load which negates the load they’ve removed!
• Don’t try to remove every single asset from every plugin. Focus on the major bloated plugins!

The only pro way to remove unnecessary asset loads from plugins:

Fork the plugin and hack it.

10. Resist the dumb ideas

I’ve heard clients scheming up many silly tactics from time to time. They’ll read random words on the internet and think it applies. Happy to dispel them for you below:

• Getting better cache plugin – sorry, no. Cache plugins are generally designed for frontend use.
• Installing performance plugins – I’ve seen all the dumb booster plugins for WooCommerce, pagebuilders, and what not. At best, they just hog up more memory via autoloads making their intended plugin run faster while the rest of your site slows down.
• Increasing memory limits – this only allows your slow site to run instead of erroring out. It doesn’t make your site reduce it’s [wasteful] memory use.
• Cloudflare caching your admin – DUMB! NO! *slaps your hand away*
• Static site – no, static sites are only for frontend.
• Load balancing, or cluster setup – if your site is too bloated to load on one server, adding another proxy isn’t gonna help or redistribute the load in any way. It’s like trying to bake a cake using 2 kitchens instead of one. Load balancing is for high traffic load, not slow code load.
• Remote database – lol, no! Your slow database runs even slower now since it’s not in the same server.
• Asset organization (step #7 above) – because even if you chop out the assets, you’re still not chopping out the queries. And keep in mind that asset management mostly only helps frontend users as backend users don’t even use those assets to load.
• Tuning MySQL configurations – I highly doubt this is your issue.

Some speed optimization really isn’t for non-developers to do. Even if you don’t break your site, you might only improve your slow speed by 10% (if not make it worse). I recommend you hire a developer if you’ve gotten this far.