How To Speed Up A Slow WooCommerce Backend

0:00Why a Slow WooCommerce Backend Is a Problem

Hey, it's Brendan here from WP Speed Fix. In this video we're going to talk about speeding up the WooCommerce backend or admin panel. It's something we get asked about a lot, and it's an important one, because when you're working with WooCommerce all the time, managing orders and managing products, a backend with a 5 to 10 to 20 second delay loading pages is really frustrating. It just makes simple things take a lot of time.

So let's talk through some points here. These are the big win items that will really move the needle. Usually when customers come to us with this problem, one of these is the root cause, and the others are optimizations on top of that. There are lots of other small things you can do as well, but these are the ones that usually move the needle, so let's get into it.

0:45Use Good Hosting for WooCommerce

Let's get into it. It goes without saying that the first one is to use good hosting. The host we recommend is Cloudways. If you go to cways.net you'll see their website. On our site we have a post under our DIY guides, Fastest WooCommerce Hosting. These are generally the three hosts we recommend as a starting point if you have a WooCommerce site and you want to look at a better host. Cloudways is probably the fastest out of these, but it's a bit more technical, and you generally get the best bang for buck out of Cloudways, so that's who we recommend for most sites. The other two, Kinsta and SiteGround, are a little less technical, but in terms of raw dollars for performance, Cloudways is the best. So go to cways.net and check that out. I won't go into it too much, because it kind of goes without saying.

We still do see clients on GoDaddy and Bluehost and HostGator and some of these cheap hosts, and that's just not going to cut it. It's slow. There's a reason cheap hosts are $5 a month and not $50 a month: you get what you pay for. The difference between good hosting and cheap hosting isn't much. It's kind of the cost of a cup of coffee versus the cost of a nice lunch. When you take your own activity into account, if you're sitting there for hours each month waiting for pages to load, the cost of labor really adds up. So going with really cheap hosting is a false economy, because you're losing money elsewhere. It's worth getting good hosting.

Cloudways has lots of different locations, lots of different options and a ton of features that will speed up WooCommerce in general. If you read that post on WooCommerce hosting, you'll see it talks about object caching. Object caching is a type of database caching, and that will also help speed up WooCommerce in the backend, the cart, the checkout and anything to do with products and orders. Object caching does a lot, particularly if you have a busy site or multiple checkouts happening at the same time. That will make a big difference to performance. So that's hosting, pretty straightforward. Let's get into the next one.

2:40Fix the Database Storage Engine (InnoDB vs MyISAM)

Let's get into the next one. This is a really big one, particularly if you have an older WooCommerce site that's been around for a while. It's something we see a lot. If you've got a site that's 5 or 10 years old, you might have this issue where you're using an older version of the storage engine that the database runs on. Basically, database tables can run on two different formats. The faster, better one is InnoDB, and the older one is MyISAM. I'll link you to this in the description below. On our website there's a post, speeding up WordPress database queries, and if you go down to point 6 it explains how to fix this.

With the older MyISAM table, when something is writing to that database table, nothing else can write to it. Think of the database table as an Excel spreadsheet. When something is writing to that spreadsheet it's locked, so only one write can happen at a time. With the newer format, multiple writes can happen at a time, so the whole table is not locked, just the row being written to. That makes a huge difference for performance. It's akin to emailing around an Excel document where only one person can work on it at a time, versus using something like Google Sheets where multiple people can work on it at once.

When you have a busy site with lots of add to cart and checkout actions happening, the database writes start to queue with the older format. With the newer format you don't really get that, so the database just goes much faster. That post talks about a simple way to convert the database tables. Make sure you do a backup first, but if you use the plugin Servebolt Optimizer, that's an easy way to do it. If you've got a small database, that's basically one click and 30 seconds and you're done, and it will make a huge difference. You can cut the page load time in the backend from 5 to 10 seconds down to 1 second. It also can add indexes to the database tables, so that helps too. Even if you're not using the older storage engine, the indexes on the tables will help things as well.

So that's pretty straightforward, and you'll find the link up there with the instructions. Point 6 is the one you want. There's a bunch of other stuff about the database in that post, but 6 is the one. So that's database tables, the first of the database fixes.

5:04Switch to High Performance Order Storage (HPOS)

Okay, this is a big one: High Performance Order Storage. This is kind of similar, another database one, and it's a new feature on the WooCommerce side. In WooCommerce 8.2, released in October 2023, a new version of the database was introduced. When WooCommerce was first added to WordPress, it was kind of just hacked in there, and everything to do with products and orders and customers just used the existing database tables. That was fine if you had a handful of products and a handful of orders, but if you have a busy site with thousands of products, thousands of orders and thousands of customers, that doesn't work. It's very slow, because those database tables were never designed for that. High Performance Order Storage fixes that. It changes the database so there's a new set of database tables for products, customers and orders, and it speeds things up substantially.

There's a long blog post about it, but it's pretty easy to set up. Basically there are three steps. Under the WooCommerce settings you go to Advanced and then Features, and you'll see the settings for setting it up. You need to have all plugins compatible with this new feature. If you have plugins that aren't compatible, it will show you the list of plugins that need to be updated. Often those are paid plugins where you just need to find the update, or pay their subscription to renew the license, and get the latest version. So make sure all the plugins are compatible and there's nothing showing there that's an issue, and then just turn it on. It will take some time, because the database needs to synchronize the orders and customers and everything else you have to the new database format. Once that's done, you can switch over.

There's a whole bunch of stuff in the documentation about how it works and about incompatible plugins, but basically this will dramatically speed up everything. It won't just speed up the backend, it'll speed up add to cart and checkout, anything the customers are doing as well. So that's an important one, and it's pretty simple. Before you go messing around with this stuff, make sure you take a backup. So that's High Performance Order Storage, an easy one.

These three alone, getting good hosting, fixing up the database storage format and High Performance Order Storage, are usually what the issue is, or the fix. If you get those three nailed, you should see a big difference in that backend speed.

7:24Fix PHP Errors with Query Monitor and Use the Latest PHP

Let's talk about the next ones. These are more niche and a bit more difficult, and they're probably not going to be the root cause of the issues. The next one is fixing PHP errors, or errors with your WordPress configuration, that are happening under the bonnet. We use a plugin called Query Monitor to do it. If you just search for Query Monitor, that's the plugin. It's a free plugin, and once you install it, it adds an item to the toolbar in the WordPress backend. It also shows on the front end if you're logged in, and it just shows any errors or warnings that are happening on that page load.

I was actually speaking to a customer this morning, so I'll turn it on here, and you can see it's got 20 PHP errors on this page. Anytime the hosting has to deal with an error like that, it's going to slow things down, and in some cases it can slow things down substantially. We're talking about 10, 20, 30 seconds if there are serious errors. It gives you the information here, and you can see that in this case two plugins are not compatible with the version of PHP the site is running. The version of PHP is too high, so these old plugins need to be updated to support version 8.3 of PHP. In your case there might be other errors. It might say there's something wrong with wp-config, or something else. The warnings are in brown, but if there are errors they'll be in red like that. Errors are usually really bad, warnings are not so bad, and then there are notices. Anything in there really needs to be fixed to get the maximum performance out of the site.

Once you've finished with Query Monitor, make sure you disable it. It's just a normal plugin, so you go in and deactivate it. It does have some resource overhead, so you don't want to run it all the time if you don't need it. Quite often we find configuration errors because sites have been moved from different hosts and they have code from an old host. That could be the issue, and it might just be a case of that code needing to be removed, or it's duplicating code somewhere in the configuration files. But that's basically what we use to troubleshoot those errors happening under the bonnet. Very straightforward, and usually not the root cause of most issues, but worth checking.

This next one is usually not the root cause of most issues. WordPress runs on PHP, that's the programming language it uses, and every version of PHP is faster than the last one. So you want to use the highest version of PHP your site supports. The current version right now is 8.3, as we're towards the end of 2024. Depending on what you're doing, each version can be 10 to 50% faster than the previous version. It depends on what functions are being performed, but 8.3 would be a bit faster than 8.2, and that's faster than 8.1 and 8.0. The point is you want to use the highest version your site supports.

You don't want to just go and change this, because it's going to break things. There are plugins, and many hosts have ways to test PHP compatibility, so look that up for your own host and then look at switching. That is a developer level change, and you probably want to use these two in conjunction with each other. If you change the PHP version, you probably want to install Query Monitor and make sure there are no issues or errors happening under the bonnet. I think that all makes sense, but that one's probably for a developer, not a DIY.

10:50Use a CDN: Cloudflare with APO and Brute Force Rules

All right, the next one is to use a content delivery network. We recommend using Cloudflare with their APO service, Automatic Platform Optimization for WordPress. It sounds like a dorky name, but it's a really good service, and it's only five bucks a month. If you're not familiar, a content delivery network is a network of servers that takes up some of the workload from the hosting. For the problem we're trying to solve here, we're moving the workload off the hosting and somewhere else. We're moving some of the work from the web hosting onto Cloudflare. There's a free version of Cloudflare, so even if you use the free version it will help substantially, but APO will help even more.

The difference between the free version and the APO service is that with APO, the entire page, for all the pages of the website, is cached on Cloudflare's network. When a user comes to the site, Cloudflare serves up the page. As soon as the user starts doing things like logging in, adding to the cart, or anything to do with the checkout, products or orders, the APO service essentially turns itself off and that traffic goes back to the website. But the point is that with a content delivery network, we move workload off the hosting, so the hosting is free to do more of what only it can do, which is processing your stuff in the backend.

There are some other bits and pieces on top of that that will help even further, and again it's about moving or reducing workload. There's a blog post on our website, Cloudflare firewall rules for WordPress, where we have three Cloudflare rules to improve WordPress site speed and security. The most important one here, I'll scroll down, is rule three, the blocking one. With Cloudflare we can block brute force attacks. The typical WordPress or WooCommerce site is getting 1,000 to 10,000 brute force attacks a day, so that's a lot. Usually they happen in a very tight period of time, multiple times per second, which chews a ton of server resources. With Cloudflare we can add rules to filter that traffic, so it runs them through a captcha page or some sort of security message. You'll have seen this before: you go to a website and it says it's checking your security. That's Cloudflare or something similar.

Before they hit the WordPress backend login or the My Account login in WooCommerce, we're running them through that filter. If it's an automated brute force attack, it will filter 99.9% of that stuff. The work is handled by Cloudflare's layers, so it never gets to the website. That's a really simple one there.

There's another one here to block SEO bots and crawlers. Again, with a WooCommerce site, some of these crawlers like Semrush and Ahrefs can be extremely abusive to the website. They do things like add and remove from the cart multiple times per second, or hit the wish list multiple times per second, and again that chews a lot of server resources. If you're getting flat spots where the site runs fast and then all of a sudden it's slow for an hour, that may be the issue: SEO bots and crawlers coming to the site, hammering it, and then they go away or time out. Those two are probably the important rules. You'll see the first rule there, and you shouldn't use that one for WooCommerce because it may break things. So those two rules, that's the Cloudflare rules.

14:20Wordfence Security Plugin

Okay, next one, again about eliminating or reducing workload. We use the free version of Wordfence. The Wordfence plugin, that's just autocorrect there, but you want to use Wordfence on your WooCommerce site. It will filter threats and things like brute force attacks that get through Cloudflare. It just provides another layer of security to filter that garbage, and anybody that's trying to do malicious things on the website, it'll help filter that as well. So install Wordfence, it's pretty straightforward. Use the free version and it'll help a lot.

There is a bit of a performance hit to using Wordfence, but the performance hit that Wordfence has is a lot less than the performance hit that crawlers, scrapers and things probing the site are going to have on the site. So there's a net gain effectively, and you can use the free plugin, that's fine.

15:06Block Search, Add to Cart and Wishlist in robots.txt

Okay, last one here. We want to block the WooCommerce search, the add to cart and add to wish list in our robots.txt file. This will stop crawlers trying to load those pages, or those query strings effectively. I touched on this with the SEO crawlers and scrapers, but even the Google crawler can be malicious, and other genuine search engine crawlers can be malicious as well. Often they will try to crawl search pages, add to cart links and add to wish list links, and they'll do the same thing as an SEO crawler and hammer the website with traffic. That just adds a lot of load and slows things down.

These are the rules, and we put them in the video description. You add these to your robots.txt file, and this will block Google from crawling these URLs, or these query strings, because they're not actually URLs, they're query strings. We have an optimized robots.txt file for WooCommerce with the details. There is a second layer you can do as well. If you check in Google Search Console, I'll just load up a client here, go to Pages and go to "Alternate page with proper canonical tag". You'll see anything else that is loading with a query string, and anything that has a query string in WooCommerce adds load to the website. These are often search filters or categories that have not been set up properly. They've been set up with searches instead of full categories. Anything like this, such as attribute_pa_size or attribute_pa_quantity, is a candidate. We don't want Google crawling those, typically.

You do want to use some care here. Don't go blocking Google randomly, because that might break your SEO. But anytime you see query strings like this, it may be a problem, and it may be chewing a bunch of load. We see here in this case there's an add to cart URL, so Google is crawling the add to cart URLs. Google comes along and adds and removes things from the cart, just like other crawlers. By adding those lines into the robots.txt file, we block Google and we block all the other crawlers that honor that file. Not all crawlers honor it, so that's why we need those Cloudflare rules as well, to block crawlers that just ignore the robots file. But adding those four lines in will reduce the load significantly in many cases.

It also protects you against a type of negative SEO attack we've been seeing, where spammers and scrapers will load up a bunch of searches, or hit the search URL with porn, spam and gambling links, and get Google to index those. By using these disallows as well, we provide a little bit of protection from that. So there is kind of a security boost to doing that too.

17:50Recap and Free Tools From WP Speed Fix

That's it for this video. That's the high level overview. Those are the big ones: 80% of the time it's one of those issues that we find with a site, and that's why it's slow on the backend. Just to recap: use good hosting, look at the format of the database storage engine they're using, and you want to use InnoDB. Get High Performance Order Storage working. Regardless of what else you do, even if the backend's not too slow, that will make a significant improvement all around, even on the front end of the site, particularly for users. Check for PHP errors using Query Monitor, use the highest version of PHP the site supports, use a content delivery network and add those rules, use the Wordfence plugin, and then block these guys in your robots.txt file.

If you want more help, go to our website. There are a few ways we can help you. If you want speed optimization help, fill out a free audit on our homepage and tell us what you need help with, or what the problem is you're struggling with. We can have a look at your site, come back to you and tell you how we can help. We also have a free Core Web Vitals report. If you fill this out, no opt-in is required, and it will give you a report on your website speed. This pulls the data from Google, so this is the real speed of the website. It's a high level overview of the average of the site, but it will give you an idea of how the site is performing. It takes about 60 seconds to generate the report, and it will update on the second Tuesday of each month with last month's data. There's a video there to talk it through and explain how to read that report.

Then also our free WordPress site speed test. Again, no opt-in required, it takes about 90 seconds, and it will give you detailed recommendations on how to speed up whatever page you've tested or your homepage. It will check for simple errors like 404s and things like that. I'll leave that with you. That's all over at our website, wpspeedfix.com. If you have any questions, just post them in the comments and I'm happy to come back to you. Cheers.