How To Fix Slow WordPress Admin Backend

0:00Why the WordPress Admin Is Slow and How to Diagnose It

WP Speed Fix. In this video we're talking about how to speed up the WordPress admin backend. This is a question we get asked about a lot. We have a blog post on our site about it and I'm going to walk you through it now. This is a bit different to WooCommerce, so if you have a WooCommerce site, we actually have a post specifically for WooCommerce because it's a bit different, and you can check that out on the site here. There's a link here for how to speed up a slow WooCommerce backend, and there is a video on YouTube as well if you want to check that out. There are a few additional things that are WooCommerce specific that make it a bit different to a normal WordPress site, so if you do have WooCommerce, start there as opposed to this post. So let's get into it.

You'll see on the post we've broken it down into why the WordPress admin is so slow and given the specific reasons. A lot of people do speed optimization and they just randomly change things, or add things, remove things, turn things on and off without actually diagnosing what the problem is. There are specific reasons why the WordPress admin backend is slow, and quite often when we do speed optimization work there are one or two specific things that are a problem, or one or two things that are actually broken or not right. Then the rest of the things are just optimizations on top of that to make it faster.

When people come to us with a slow backend, a slow admin panel, typically we're talking about pages that take 5 to 10 seconds to load. We're not talking about pages that take 2 seconds to load where they want them as fast as possible. There's a difference between slow and needing optimization.

1:31Slow Hosting and Missing HTTP/2 Support

This post will get you to something reasonable and will give you some optimizations on top of that. They're kind of two separate things. So let's get into it. The first one is kind of obvious, but we have to say it again and again: use good hosting, or avoid using bad hosting. If you have cheap hosting, the backend is going to be slow. There's no real way around that. By cheap hosting we're talking about the cost of a cup of coffee versus the cost of a nice lunch. If your hosting is $2 or $5 a month, it's probably not going to be good enough, and expecting performance out of that is probably unrealistic, as opposed to paying $20, $30, $50 a month for hosting. Just keep that in mind.

There are some specific things that good hosting does that bad hosting doesn't, and one of those key things is support for the HTTP/2 protocol. I've got that here on our list. This is a big one. Often when we see people come to us with a really slow website, they're on hosting that they've been on for a very long time, or it's very cheap, and it doesn't support this protocol. This protocol has been around since 2015 and basically it speeds up how quickly the browser can connect to the website and download stuff. With this protocol in place the site will be 30%, 50%, even 100% faster, so twice as fast. If your hosting doesn't support this protocol, the site is just going to be slow. A good yardstick, like I said, is that if the hosting is $2 to $5 a month, even $10 a month, it's probably too cheap to be high performance. Just keep that in mind.

There are a few things you can do to look at the hosting. The first one is that we have this post with the fastest WordPress hosting. These are the hosts we typically recommend on an ongoing basis, so check that out on the site. It's under here, DIY Guides, Fastest WordPress Hosts. Cloudways, cways.net, I'll just type that here and we'll put it in the show notes in the description of the video. Cways.net is probably the host we recommend in terms of value versus performance. It is a bit technical, but it's worth checking out.

Also, run your site through our speed test tool. If you go, on our site, to More Free Stuff, Free Site Speed Test, and run your site through this test here, it's free, it takes about 90 seconds and there's no opt-in required. You'll get a result that looks like this. This is a test I just picked up, and you'll see it will actually detect whether your host supports the HTTP/2 protocol, so that's probably a good way to just check as well. We do have some hosts that are on our naughty list, and it will tell you if it detects one. It's not 100% accurate, but it will usually detect these hosts that we know are slow and problematic. Hosts like Bluehost, HostGator, Crazy Domains are very commonly cheap and slow hosts. I think that goes without saying, but slow hosting is definitely a problem.

4:15PHP Errors and Site Configuration Errors

Okay, the next one. Apart from slow, bad hosting, this is probably the next most common root cause of a slow backend for most sites. It's either PHP errors or some sort of error happening under the bonnet. It doesn't necessarily need to be a PHP error, so let's say a site configuration error, or PHP version errors. The site either has too low a version of PHP or too high a version of PHP, and there are plugins that are having errors, or code that has errors or is throwing errors as a result. Often these errors are happening under the bonnet and you don't see them, but on every single page load on the backend the hosting is having to deal with these errors.

Anytime you have an error, or even something like a 404 error, it'll produce unpredictable results. The hosting, or the browser, or whatever it is, has to figure out what to do with that error, and sometimes it just waits to time out. Sometimes things are crashing in the backend. Basically errors cause freezing and unpredictable behavior, and the symptom you feel is slowness, but various things could be happening under the bonnet. The easiest way to diagnose this, or to surface these errors, is to use this plugin here, Query Monitor. It's free, here it is. When you install it, it adds this toolbar menu item into WordPress in the backend, and you'll see it will surface errors as red and warnings as brown. Red is actually really bad, it means there's something specific that's problematic. Brown is a warning, it maybe needs to be fixed. It will surface PHP errors or issues with plugins or configuration, and then you can go down that rabbit hole and work with a developer or whoever to sort that out.

The most common issue we see is that there are paid plugins on the site, or really old plugins that have been orphaned or abandoned, and they no longer support the version of WordPress or no longer support the current version of PHP. Usually if that's the case, Query Monitor will give you the error and it'll give you the plugin that it's attached to. A simple way to fix that is to upgrade the plugin. We see this issue especially with paid plugins that sit outside the WordPress update ecosystem. They may need to be manually updated, so you need to go to the website, download it and then install it. Using this plugin you'll uncover those errors. Maybe the PHP version is too high and you need to drop it back, or it's too low and you need to bring it up, or there are plugins that need to be installed, or there's some sort of configuration error.

If there are errors inside the WordPress configuration file, the wp-config file, it'll also throw that up. One common error we see is configuration code that's been duplicated. Or if you've moved your site around from a different host, there might be old code in there that's custom for that hosting provider, which no longer works on your existing host, and it's throwing some sort of error. Basically, install the plugin and then troubleshoot the errors or the warnings that it's surfacing. I think that's all pretty straightforward, so we won't go into any more detail there.

7:21Page Caching, CDN and Object Caching

Next, no caching in place. WordPress basically needs page caching to go fast. What caching does, essentially, is prebuild the pages on the front of the site, so when the user comes to the site the pages are ready to go. They're already built, all the PHP processing's done, all the database lookups are done. There are basically two plugins we recommend: WP Rocket, wprocketplugin.com, or the FlyingPress plugin, flyingpress.net. FlyingPress is a bit more technical to configure. WP Rocket is a bit more DIY friendly. Either of those will get page caching in place, and they both do a lot of similar optimization. Without page caching in place the site is just going to be slow, because every load on the front end is chewing a lot of server resources, so it will make everything slower. You need page caching in place. Some hosts have page caching built in, so it's worth checking that before you go buying plugins. The caching may also be disabled. You may have caching but it's been turned off and it's making everything slow. That's pretty straightforward.

The next one, number 5: no content delivery network in place. A content delivery network is a network of servers around the world that serve up some part of the site or all of the site. We recommend Cloudflare. Cloudflare is pretty much the biggest CDN in the world. Even the free Cloudflare plan will help you, but we recommend you use the $5 a month APO service. You'll see here's the Cloudflare website. I think if we go to pricing we should be able to find that. Oh, here we go, compare all plans. It's not listed, the $5 service. There we go, APO. Basically the free version is great, but the APO service will add caching. It's going really slow. It'll add caching, so basically Cloudflare caches the entire page at all the Cloudflare nodes around the world. That will absorb a lot of load. Cloudflare is taking up a lot of the load for not-logged-in visitors, so there's less load on the hosting. That frees up the hosting to only do the stuff that the hosting can do, which in this instance is the stuff in the backend.

There are also some things we'll talk about in a minute with Cloudflare. Cloudflare is also a firewall, so we can add firewall rules into Cloudflare to remove a lot of the garbage traffic, scrapers and crawlers that are hitting the site. We'll talk about that in a second. Long story short, use a content delivery network, ideally Cloudflare. It's the biggest, it also has a free plan, and it has a whole bunch of other features there, like the firewall. On the higher paid plans, the $20 a month plan, it also adds things like image optimization and a beefier firewall, so if you have a highly monetized site that would be worth doing as well. But long story short, use the CDN, and don't use two CDNs. One common problem we see is people stacking optimizations on top of each other and using two optimizations. If you use two content delivery networks, that'll actually make things slower and worse, so just keep that in mind as well.

So that's CDN, content delivery network. Next, object caching. This is probably not applicable unless you have a bigger site or a lot of users. We have some clients with sites where multiple staff are editing pages or products or posts on an ongoing basis, all day long. If you have a bigger site like that, you ideally want to have object caching. The lack of object caching won't specifically make the site slow, but this is more of an optimization. If you have multiple staff in there, or a bigger site, object caching will help. Basically it's a type of database caching, so the hosting needs to support it. You need to have support for something called Redis or Memcached, which is the piece of software that runs on the server, and then you need an object caching plugin. If you're using a host like Cloudways, like we talked about before, or one of the other hosts we recommend, they do have object caching built in. It may be that it needs to be turned on, or you might already have it. That will help bigger sites, so that's worth checking out, especially if you have multiple staff in there at the same time making edits and changes.

11:32Malicious Traffic, Brute Force Attacks and Aggressive Crawlers

All right, let's get into this. We talked about this with the Cloudflare stuff: malicious traffic, brute force attacks and aggressive web crawlers. You'll see I've got two points here. They may be legitimate crawlers, like the Google crawler crawling things like query strings, or they may be aggressive SEO crawlers like SEMrush or Ahrefs. Let's talk about these together. Basically it's bad traffic. It's traffic that's not legitimate, they're not real users, and they're hammering the site and chewing up a lot of resources. Brute force attacks are probably the most common one here. WordPress sites typically get 1,000 to 10,000 brute force attacks a day, which is a lot. Each one of those chews a lot of server resources. Malicious traffic and brute force attacks don't happen spread out throughout the day, they happen in small clusters of time, so you might have multiple attempts per second to log into the backend, to brute force the backend.

There are a few different ways we deal with this. Like we talked about, we use Cloudflare, and we have this post, Cloudflare rules for WordPress. If you click on that and go to our site, there's one here. If I scroll down, "block brute force attacks". We have a simple way to block brute force attacks. Basically you add this firewall rule to Cloudflare, the free version of Cloudflare will do it, and it will filter out brute force attacks on the WordPress backend, which significantly reduces the load on the site. This is going to be a very common problem if you have a bigger site that's ranking well, or if you're in a highly competitive industry as well. That's an easy way to block brute force attacks, and it moves the load across to Cloudflare. You'll see here my next point is to use the free version of Wordfence. This will also block brute force attacks, but it does that at the hosting layer, so that actually chews resources, whereas if you do it at Cloudflare, that chews Cloudflare's resources, not your hosting resources. We're using multiple layers of protection here, and Cloudflare is a good place to start with that because it's free and it doesn't affect the hosting.

You'll see on this post we also have a couple of other rules. If you don't have a WooCommerce site, you don't need the XML-RPC file exposed. This is a WordPress API, so we can block that in Cloudflare. That again is something that quite often gets attacked. Next, blocking SEO bots and crawlers. We do this as well. These are the most common crawlers we see: SEMrush, Ahrefs, Open Site Explorer and DotBot. They're very aggressive, so you can just block those outright in there with this firewall rule. That also has a secondary benefit in that the data about your site won't be as rich in those tools, so competitors can't see as much about your site in those tools as they would if those crawlers were allowed to access the site. Quite often those bots can be very aggressive and can knock the site offline, even.

I think there's one more: filtering traffic outside your target country. This can be useful. Our company is based in Australia and we have a lot of Australian customers, and this is one common thing we do for customers that are targeting only Australia. We also have a lot of US customers as well. We don't like blocking outright, but we filter traffic outside the target country. With this firewall rule, what this will do is basically run the traffic through a CAPTCHA-type page. You would have seen this around the web: you go to a website and it says "checking your security". What that is, is basically running you through a CAPTCHA-type check to see if you're a legitimate browser or a bot. That will filter bot traffic, or automated traffic, outside of your country. It will block some legitimate traffic too. If you've got APIs or third-party tools accessing the site, it most likely will block those as well, so you'll need to add exceptions there. You'll see in this rule here we actually have an exception for uptime monitoring tools, but there may be other tools, like backup plugins, that need that rule to be tweaked.

Then legitimate crawlers. Particularly recently, we've seen this in the last 6 months, since about mid-2024, particularly with Google, since AI search became more of a thing, Google is more aggressively crawling websites, and we see query strings being crawled a lot. Query strings are the bit on the end of the URL. They're not full pages. In WooCommerce in particular we see this issue where a crawler will come along and crawl add-to-cart and add-to-wish-list query strings, which add things to and remove things from the cart very rapidly in a short period of time. We don't want Google doing that. That wastes Google crawl budget, but it also wastes a lot of server resources. You can get this list of query strings from Google Search Console and you can block them in the robots.txt file. Here's our website, WP Speed Fix, and you can see we've blocked these different URL extensions because Google was crawling them. This one here is a very common one: Google will crawl the search on a site, and we don't want it crawling the search pages, so we block that. We don't want Google crawling the login page either, so we block that.

If you pause for a second, I'll bring up, oh, here it is, Google Search Console. If you want to find the query strings you should be blocking, go to Google Search Console for the site. Usually it's under this section, alternate page with proper canonical tag, and it will list out the query strings. You see here's a couple, some affiliate strings that Google is trying to crawl. If these aren't legitimate pages, these really aren't a big deal for us because there's only a handful of them, but if they are not legitimate pages, you might want to block those query strings. You'll see once you've blocked them they'll appear here as "blocked by robots.txt", so you can see there the query strings we're blocking. You saw that we're blocking the wp-login page, for example. You really want the query strings that are appearing a lot, and you can see here that wp-login is appearing a lot for us. That's why we blocked it. We don't want Google trying to crawl the login page like that. It's not ideal, it burns crawl budget, et cetera. So that's that.

That one is a bit technical. Be careful: if you add something, even if you have a typo in that robots.txt file, it could break your SEO. Be very mindful messing with this stuff. If you're not comfortable, you probably need a developer to help you. We do also have a Google Search Console audit service at WP Speed Fix that will give you the exact recommendations, the exact items in this case, that you need to add to the robots.txt file. Basically we want to block anything that's not legitimate pages from legitimate crawlers. I think that makes sense. The whole point of that section is to reduce load on the site, so stop the resource drain on pages that aren't legitimate, or from users who aren't legitimate.

18:37Large Database Tables and MyISAM vs InnoDB

All right, let's talk about the next one: large database tables, and also running the MyISAM storage engine. A large database doesn't by itself make WordPress slow. You may get some scenarios where a plugin has been logging things it shouldn't, or isn't clearing out its log, or has a lot of transients, and that's making the database very big. That's most likely what the issue would be there if there's a large database table. Probably more common is that you're running this older storage engine, MyISAM. I'll just bring up this post here to illustrate this one. The WordPress database can run in two different formats. Here we go. This post talks about the WordPress database specifically, speed up WordPress database queries. I've linked to that. There's a whole bunch of other stuff about database work there, but this is the most common one we see.

There are two different storage formats, MyISAM and InnoDB. MyISAM is old, InnoDB is newer. It's not new, but it's newer. Basically the difference between the two is akin to an Excel spreadsheet that you would email around to people to edit, versus a Google Sheet where multiple people can edit it at once. With a MyISAM table, the main bottleneck is that when the database is writing to a database table, and think of a database table as a spreadsheet, only one write can happen at a time. The database table is locked, so the writes have to be done in a series. They queue up waiting for the database table to be available. With InnoDB, only the row in that table is locked while that database write is happening, so the writes happen much faster. This is particularly important if you're in the backend of the website editing things and you update a post. The writes will happen much faster with the InnoDB storage engine, and especially so if you have multiple staff in there editing things at once. We want to be running on this newer format.

If you have an older WordPress site that's been around for a few years, you're going to be running this older format, or maybe you have some tables running this older format. We recommend this plugin here, Servebolt Optimizer. You basically install it, run its optimization, it will convert the database tables, and then you can get rid of the plugin. Before you do this, make a backup. Don't go and do this without backing up your database. There's not very much risk here, but there's always risk when you change these things, so that's my disclaimer: make sure you have a backup first. Then go and make this change. This tool will convert the database tables to that newer format. It'll also add some indexes to a couple of the database tables to speed them up. It's really easy to do the optimization. It might take a minute, so the round trip might take you 10 minutes to do a backup, install this plugin, and then get rid of it after you run the optimization. So that's that.

You can also use this plugin here, which will also do it. This plugin used to be a database-only plugin and now it does a whole bunch of other stuff, so just don't turn anything else on in there. Like we talked about before, two of any optimization is bad. But this will also give you detailed insights into database sizes, and it can also convert to that newer storage engine. It'll highlight any tables that are big or fat. We typically use this one to look at database table size. Usually it will tell you inside this plugin. I don't know if there are any screenshots here, yeah, probably. There we go. This will show you, I wonder if we can load that up, there we go, database table size. If you have a database table that is huge in comparison to the other tables, then that may be something to look at. Often log tables will be named logs, so it's very easy to see if you have an issue. The most common issue is a log file gone astray, where it's logging all the visits to the site or all the actions, or something. Clearing out the log reduces the size. That's the most common issue we see. But from a performance perspective, doing that conversion to InnoDB is the big one.

Next, deleting transients. Transients are temporary information about visitors who visit the site, and after a while they expire. I'll just make that clear: you want to delete expired transients. WP Optimize can do this. The WP Rocket plugin can also do this on a scheduled basis. We don't see it so often anymore, but in the past we have seen sites with 2 million transients. That's 2 million lines in a database, which is going to make database lookups slow, and that really is where we see large database tables slowing down database lookups. Deleting expired transients will also help speed things up in the backend, but if you have a fairly modern site that's up to date, you probably don't have that issue. Okay, let's leave database stuff alone. If you want to see more on database stuff, we have a whole post about it, so go check that out.

23:34Over-Optimization and 404 Errors

Next, over-optimization. Like I said before, two optimizations where you should only have one. The most common problem here is two content delivery networks. The reason why that's slow is that you have to loop the traffic from one network to another and then to the hosting, so you're adding an extra hop, or an extra step, in the process. You only want one CDN. Often we'll see people use Cloudflare and then use the CDN inside the WP Rocket plugin. That is a mistake, don't do that. One CDN only, one caching plugin only. Don't duplicate optimizations. You can certainly use two optimization plugins. Very often we'll use a combination of WP Rocket, Autoptimize and Perfmatters, or WP Rocket and Perfmatters. You just want to avoid having the same optimization turned on in two different plugins. We use those plugins for different reasons because they have different features. Just keep that in mind, but avoid duplicating optimizations.

Long story short, 404 errors. This is a very common problem, especially if the 404 error on the front of the site is happening across all pages. That's where something in the template, say the header or footer, is 404ing out. There are a few different ways to check. Use our site speed audit tool like I showed you before, SiteSpeedBot. Go to our website, go to Free Site Speed Test, and it'll surface 404 errors. I think that example we had actually had a 404. Yeah, there we go, you've got at least one file that's 404ing out. You can scroll down here and it'll have red next to it. There you go, that one there. In this case this is a site under development, and we can see here the header file is 404ing out. It'll give you the file that is 404ing out. The other way to do it is to do a full SEO audit of your site, using an SEO audit tool. Either one of those. Basically 404s are slow. When the browser hits the 404, the hosting has to process it and do something with it. Anytime you have a 404 error it's bad for speed. It's bad for users, because the site will be broken in some way, and it's bad for SEO. So 404s are actually really bad for speed and SEO and overall not good. We want to fix any 404s you have. That's enough about that.

25:29Cron Issues and Slow Image Uploads

Cron issues, so let's talk about this. WordPress has a cron job. A cron job is a scheduled job that does things in the background. That may be things like cleaning up databases, it might be just maintenance items, things like that. Basically it's scheduled work that happens in the backend. By default WordPress runs the cron on every page load. On a big site with a lot of plugins the cron job can actually be very slow, and it can cause some of the page loads in the backend to be very slow, especially if the cron jobs are taking a long time. The solution for this, and I'm not going to put a lot of detail here because it depends on the host you're on, is to use a server-based cron. Instead of that scheduled job running every time a page loads, it will run at a specific interval set by the server. Basically you want manual server cron jobs. The best way to set this up is to search for your host, how to manually set the cron job in Cloudways, for example, and it will give you the instructions to do that. It's a bit technical, you might need support to help you, but basically you want to have a server-based cron versus a WordPress-based cron. That will make things in the backend faster, especially if you have a big site, and especially if you have a WooCommerce site, because cron jobs tend to run long there. The cron job can take anywhere from 2 seconds to 30 seconds. If you are not using a server-based cron job and the cron job takes 30 seconds, that means occasionally some of your backend loads will take 30 seconds. That's that issue there, but that one is a bit more developer, not so DIY.

This one here is specific to uploading images and media. If the images are very slow to upload or laggy, it may be because your image compression plugin is slow. If you have an image compression plugin, typically it will compress the images every time you upload them, so it has to dial out to compress those images. That could be the issue there if anything to do with uploading images or media is slow. There are features where you can schedule optimizations and not have them run when the images are uploaded. Most plugins have this feature anyway. You want to disable that feature, or just disable your image optimization plugin temporarily and see if the images are faster to upload. So that's an image-specific issue around image uploads. If your image uploads are slow, that could be your issue there.

28:11Minor Optimizations and Things That Make No Difference

I've added a couple more bits here. Minor optimizations. Enabling HSTS will help the speed a little bit, particularly for repeat visitors, and we have a post about HSTS. HSTS is basically a server header that tells the browser to only ever load the site over a secure channel. It will reduce the time to first byte, so it will reduce the load time a little bit. It's a minor optimization though. It won't take you from 10-second loads to 1-second loads. In some scenarios it might take half a second, maybe one second, off the loading time of backend pages. So it's a minor optimization, and it may do nothing. Just keep that in mind. Also using a host that supports, or enabling, the HTTP/3 protocol. We talked at the top about the HTTP/2 protocol. There's also the HTTP/3 protocol, which is a little bit faster than HTTP/2. It's not like going from version 1.1 to version 2, where you're getting 50 to 100% speed gains. You might get a 10% speed gain, maybe a 20% speed gain. You can enable this if you're using Cloudflare, and it can be enabled there. Usually it's enabled by default. Not all hosting supports it, so asking your host whether they support this protocol may also help the speed and be something to look at. That is another optimization similar to HSTS. It may do nothing, it may give you up to half a second speed gain. Those are minor optimizations. Again, they're not going to take you from 10 seconds to 1 second.

There are also a lot of posts around the web written by content writers who have no technical experience, telling you to do things to speed up the backend. Again, that comes back to stabbing in the dark, randomly making changes without actually diagnosing the root cause of the problem. These things will make zero difference to the backend speed, or you just shouldn't do them. Anything to do with minifying files or combining them does nothing for backend speed. That's a waste of time. If anything it'll actually make the backend slower, so you want to avoid anything to do with minification or combining files. Minifying is a very old optimization that does nothing in the modern web with server compression. We've got gzip, we've got Brotli, we have caching. Minification does nothing or actually makes the speed worse, so just avoid it. Just don't do it.

Anything related to the WordPress heartbeat. This is just another nonsense optimization that you'll see around the web. The heartbeat is not making your backend slow. The WordPress heartbeat is basically the browser talking back to the website. If you've got a post open, for example, and you're making edits, the post might be background saving at 60-second intervals or something like that. Messing with the WordPress heartbeat can break things. You can actually break functionality in the backend and cause errors upstream, so don't do that. There are settings inside the WP Rocket plugin that you should avoid. Don't mess with it, it's not going to do anything. Increasing the WordPress memory limit won't do anything either. If you are hitting the WordPress memory limit, your pages are going to crash. If you have enough memory, the page will load fine. More memory does not make the pages load faster. They will just crash if they don't have enough, and you'll get an error saying out of memory. So this won't do anything, it's not going to make any difference.

Removing dashboard widgets will only speed up the dashboard page. It may speed up the login a little bit, but overall it's not really going to speed up the whole backend experience. If you're doing a lot of logins to the site it might, and if you've got a really slow widget it might, but it's not really going to fix the real problem you have. It's a simple optimization to do, but it's not going to fix problems with editing pages and that sort of thing. Caching the WordPress backend, I've seen this around the web, you do not want to do this. We always talk about reliability over speed, and some of these optimizations break things. That's why I said anything related to the WordPress heartbeat is bad. Especially caching the WordPress backend is bad, because you'll have out-of-date data in there, you'll have stale data, and you may overwrite things in the database, which will cause corruption. We always want to choose reliability first, or stability first, over speed. We don't want speed optimizations that introduce risk, introduce the chance of data loss, or anything that's going to break the site. So don't cache the WordPress backend or anything like that.

32:29Uptime Monitoring and How We Can Help

There's probably one other thing worth doing for general reliability, and that's getting uptime monitoring on your site. Uptime monitoring will surface issues with performance or host configuration, or basically the site going offline or having issues. There are lots of different uptime monitoring tools out there. We have built one of our own, SimpleUptime. You go to simpleuptime.co. It's cheap, it's easy, it's simple. We built this for this specific problem, because we have clients who were on unreliable hosting, so uptime monitoring will surface those issues. Again, like I said, you want reliability over speed, and a host that's down is zero speed, essentially. So uptime monitoring, if your site is monetized, is a must. Check that out at simpleuptime.co.

That's pretty much it for this post. If you want more help, there are a few different ways we can help you. If you go to our site, wpspeedfix.com, you can request a free audit there on the homepage. We can tell you what we can do and how we can help. There's also a bunch of free tools here: a free SEO audit tool, a free Core Web Vitals report, a free site speed test, and a free website valuation tool. The first three are no opt-in required. They take 60 to 90 seconds. There's plenty of stuff in there, and it'll give you plenty of advice for free if you want to DIY. Particularly the SEO audit tool and the site speed test tool will uncover issues that are potentially hurting the speed in the backend. This one's powered by AI, so you'll see there's a lot of errors that it surfaces, and it'll tell you about the general site speed overall. So that's it for this video. If you have any questions, post in the comments below and we'll happily come back to you. Cheers.