Tech Breakout Summit/2021: The Ultimate Guide to Optimizing Your WooCommerce Website
When it comes to eCommerce, getting your products online is the first step, but it’s certainly not the last. Once you’re ready to sell, it takes patience and tuning to keep your store operating at its best. The session below offers a closer look at tools and techniques you can use to tune your store so that users can find what they’re looking for—and checkout—before the competition pulls them away.
A good store is more than raw speed; the real goal is an efficient user experience that makes shopping on your site a breeze. Learn how to get there and win the race for your customers with insights from WP Engine Senior Software Engineer Chris Weigman.
In this session, WP Engine Senior Software Engineer Chris Weigman discusses:
- How to scale WooCommerce sites to make sure you can handle traffic now and in the future.
- Optimizing WooCmmerce sites for everything from your images to your WooCommerce hosting provider to ensure the best user experience.
According to Google, 53% of users will leave a site if a page load speed takes longer than three seconds. That means you’ve got exactly three seconds to get them all the data on that product page—all the images you’ve sent them, all the information about it, all the little widgets, and ads.
WP Engine Senior Software Engineer Chris Weigman
Full text transcript
CHRIS WIEGMAN: Welcome back. We’re going to be talking now about optimizing WooCommerce websites. We’re looking at WooCommerce performance. We’re going to be looking at scaling WooCommerce sites to make sure that your can handle your traffic now and you can handle through your traffic in the future.
My name’s Chris Wiegman. I’m a senior software engineer here at WP Engine now. I’ve been scaling websites for enterprise-level WordPress installations for quite some time for many universities, for WordPress agencies such as 10up, for WordPress plugin sites such as iThemes.
So most of my career of scaling sites and different types of performance with WooCommerce, BuddyPress, and various systems. And today, of course, we’re talking specifically about WooCommerce performance. And when we talk about performance typically, we talk about page speed.
If you were to Google or search for WooCommerce performance, you’re going to get dozens of articles on shrinking images, on which plugins can cache and help things like that. And those are all very important.
But today, we want to remember that it’s more than just page speed. There’s a reason we want things to be faster. And that’s because, with WooCommerce, we’re worried about max users or the scalability of the site.
If page speed is the speed at which an individual page loads on the site, that’s how fast the user perceives it to be. But here, now, we need to talk about the max number of users and site can support. Think of this like your browser tabs.
If you’re like me, you get started on a project. You suddenly have 800 tabs open. And your computer really slows down. Think of each tab as a user on your WooCommerce site. Every time they would add something to the cart– every time they do a checkout– every time they insert their payment details– every one of those things has to go back to your host and process something for that individual user.
The more that you have, the slower a site can be, as each of those tasks– inserting things into your database, searching for things on the server– all that requires a little bit of CPU time for each person. With a small site, it’s really not that big a deal.
If I have two users on my site at any given time, just about anybody can support it. What happens when I do my Black Friday sale, then? And suddenly I have 1,000 users buying a product that maybe only normally would sell one or two a day. Things can get very out of control very quickly.
So large stores are going to face this problem over time. Or any store that starts out small and wants to grow will see this type of problem. It’s not specific to newcomers. But the nature of WordPress, in general, these days means it’s much more pronounced with systems, like BuddyPress or WooCommerce or things that are doing a lot of individual type data. Everybody’s shopping cart is different.
Hopefully, not everybody’s adding the same credit card or that type of information in the order form. So it needs to personalize data. And that takes a little bit of time. What ends up happening is something like this. And this graph shows the red line is how much time a page takes to load.
The blue line is the number of successful users that have been able to do something. And if we look along the bottom, it says one user, everything loads really quick. You can see that red line is slow. And as we go to the right, we start hitting 50 and 60 users. The site’s getting slower. And then something bad happens– this.
At a certain point, everything falls over. You’ve got too many tabs open. And everything starts really going slow on your computer. At this point, things just fail– every one of these where the line kept getting taller and taller. Before here, we had 50 users, 50 successful, 60 users, 60 shops, even if it was getting slower.
But once we get a little bit higher, we get to that 60, 70, 80 range. What’s happening? Everything’s falling apart. We have 70 users. But we only have about 15 that actually finished the purchase. The site completely went away for the rest. They get that white screen of death. They get some sort of error page. And that’s what we want to try to avoid with WooCommerce or any large-scale site.
Again, it’s not a problem when you get started. It’s only a problem as things grow. And not only does that fail, but you’re also looking at the fact that things are slower at that point to the more users you have at a time that more popular your site is, the greater the chance somebody’s just going to shop somewhere else because it’s simply too slow.
According to Google, 53% of users will leave a site if a page load speed takes longer than 3 seconds. That means you’ve got exactly 3 seconds to get them all the data on that product page– all the images you’ve sent them– all the information about it– all the little widgets, ads.
Whatever that page loads, you have 3 seconds before they say, this is too much. I’m going somewhere else. So that’s something to really keep in mind. If you’re only getting a couple of users a day– your first day in sales– you’re selling your lifecycle widget– not a big deal.
Once you hit the big time, though, that’s really going to slow things down for people really quickly. And in the case of WooCommerce, they’re going to fail for some rather specific things, inefficient plugins or themes. Too much data in the WordPress database that especially with WooCommerce, if you’ve kept every order that’s ever been placed from now, WordPress just turned 18 years old last month.
If you had every order you’ve ever placed if for 18 years, think about it. Every time somebody needs to pull up an order, your database has to search through 18 years of history. Things slow down very quickly. If you have an insufficient hosting plan and you’ve signed up for the 2.95 special that you saw advertised on a blog versus a managed hosting plan that may start at $35 or $40 a month, which one’s going to handle your site better?
The more expensive site is going to provide more resources. It’s like buying a more powerful computer. You buy that entry-level 500– you go to Best Buy. And you buy the $500 windows machine. It works great until you start saying, well, now I’m getting into video, or I’m getting into podcasting. This machine’s too slow.
It’s the same type of thing. An inefficient hosting plan is too small a computer, too small a server, it’s going to slow things down. Another big problem is feature bloat. What feature– do you really need, when they’re checking out, to start showing your user, switch over to this? Here is a social widget. Here is this. Here is that.
Everything that you add to a site adds to that loading time and can help slow things, can contribute to that poor experience, can contribute to things that the computer needs to look up– your host needs to look up in the database to actually lower the number of users that your site can support later.
And, of course, there’s the common one. This is what we see if we google performance. We’re going to often see things related to poor content choices unoptimized images– too many images– too bad ways of loading content. You’ve got things appearing one over the other, things like that. Too much CSS. Too much JavaScript.
But the real theme here is you want to make sure you have enough computer or enough hosting for the features that you need to support your site. And more is not always better. So how do you know that you have this?
There’s a lot of ways that we can analyze a site to really get deep. First, when we do this, we want to start looking for some very specific things. Excessive function calls– if you’re a developer, this means going into certain tools and looking to see how many times we’re calling x function– this hook, that hook.
I found some well-written plugins. It can oftentimes be better than a single small plugin doing the one thing if that one thing it’s done inefficiently. If you’ve ever taken a computer science class, they talk about things like big O notation. And big O notation basically says if I have an IF statement that reads each record in a database once, that would be an O of one. It has to scan every record one time.
Well, what happens if it finds a record and then it has to scan them all again? Or it does some sort of loop that maybe has to go through every single record 3, 4, 5 times. And that can scale up rather quickly and exponentially.
The more times it has to go through the data, the more inefficient it is, the slower things are going to be. And that really starts to play into the database size itself. If I have 10 products on my site and haven’t sold anything, scanning through 10 records at a time, even if I have to do each one 100 times, probably never going to notice.
Now if I’ve got a million orders in the database and 50,000 products on my site and 22,000 users and I need to find a specific order for a specific user and a specific product, what’s going to happen? If it’s that same inefficient script that ran 100 times, but now you have a million times for the products 22,000 times, what combination of those are they all going to add?
That’s going to take a lot more processing. It’s going to be a lot more expensive to run than something that only scans the data it needs once, pulls everything on the first try, and keeps going with it. And then there’s the classic with this, the extra-large HTTP requests. The more a user has to download, the slower their site’s going to be.
So that’s the third thing we’re looking for. A lot of times, like I said, you’ll see this first– remove extra requests, optimize the images. But that’s not always what we want to worry about first when we’re talking about WooCommerce.
There’s a few really good tools out there to really help you with this. If you’re working on the WordPress site yourself, you want to have installed the Debug Bar plugin and WP query monitor. Both of these plug-ins will help you really dig down deep and show you what’s going on behind the scenes.
Of course, don’t keep these running when you go to production because like anything else, everything that loads, if it’s running these analyses on run-end users, you’re going to slow it down again. So make sure you take them out– if you’re trying these, take them off before you send it to your host for final use.
But there’s some other tools you can look at. Webpagetest.org is a good one. Tools.pingdom.com– both of these tools show you everything that loads on the site. So maybe it’s going to show you that you have 100 JavaScripts going and that your tracking pixel for social media is what the slowest piece of your site can be.
That’s something that maybe you want to remove. Again, everything you add– the analytics, the tracking, the social widgets– all contribute to what’s going on in the background. There’s websitecarbon.com, which is a really neat site. It does similar to what a webpage test or Pingdom would do.
But it looks at it in terms of the ecological footprint of your site. How big is your site compared to others? How much is being downloaded? And it can give you a really good idea of just how heavy that site is.
Again, if your site is very light, think of it like, picking up a piece of paper. It’s really easy to pick up one piece of paper. Now, pick up that whole printer ream at once. It’s much heavier. And all three of these tools– and then Google Core Web Vitals, as well, are going to do the same types of things and help you find that.
One of the handiest tools beyond these—now, that shows you the weight of everything that’s loading of how big each thing is—how long it took the load. But there’s something that can do a little bit of all of this. And that’s New Relic. If you’re on a higher plan, a place, like WP Engine, like one of our higher-end plans, you may have this built into your site. If not, you probably want to look at turning it on independently.
New Relic is a service that it’ll go into and watch every line of execution. It’ll watch every database query. It’ll watch each PHP line that’s being loaded. And it’ll tell you, OK, you have this hook. And it took 7 seconds to load that single hook. And it tried to load it 600 times.
Now, you know with it, you have that piece of low-hanging fruit that you can go back to and really clean that up very quickly. Maybe you remove it. Maybe you simply change a line or two of code. And suddenly instead of 7 seconds, it’s taking 1 second.
Maybe this is where you need to focus on whatever caching solution that you’re using. But something like New Relic is probably the most single most effective tool out there in order to be able to really dig down deep and see what’s going wrong.
And my last position when I was at the University of Florida, a lot of my responsibility was our intranet. And this was a site of roughly 40,000 active users across the hospitals– patients, employees, nurses, and doctors– all contributing.
There were social aspects. There were all different types of aspects to this. When I started that job, the average page load was over a minute, which would take—I think the record I found was 729 different PHP errors and warnings in the background on a single page load.
New Relic was what I was able to use to help bring that all down to under 5 to 6 seconds for an average page load, because it didn’t take a lot of effort. It was, Oh, well, we wrote this six years ago for a version of WordPress that doesn’t exist. Or maybe it’s for a plug-in that doesn’t exist. I can just eliminate this feature. Things like that add up very quickly.
And then, of course, there’s your built-in browser tools. There’s your dev tools. There’s the inspectors. There’s the things like that. They can help see what’s going on, help see how long things take to load, so on and so forth that can provide a lot of confirmation.
Now, public browser tools is depending on how you have them loaded. It may not be the best representation of what your clients– what your users are actually accessing your site with. Maybe you’re logged as an admin that’s loading other things, stuff like that.
But there are also that they can still be very handy at finding, Oh, Hey, I’m loading. This product page has seven 15 meg images of this product on there. I probably don’t need to load those all at the same time. So it comes very handy in finding things that way.
Going to break this down a little bit. This is the debug bar plugin that I was talking about just on a simple WooCommerce site. And this is really handy because if you take a look at the way—when you actually click on it, it’s breaking down things, like 1.48 seconds. How much data?
131 database queries just on that simple site. Is that what I need? Is that efficient? Is that a problem? WordPress has a feature called autoload, which tries to autoload options so they’re always available. And in certain caching environments, you may exceed the size of the cache that it can hold. And you may see that it’s simply loading all these autoload options 400 or 500 times on a single page load.
That gets very inefficient. And these types of plug-ins, this query bar and debug, can help you find that. Some other views. And it’s going to do this in really great detail. 134 queries when I loaded this page, which took 74.6 milliseconds. And this is a really basic site. But now you can see each and every query and how long it took to load.
It was Friday afternoon a couple of weeks ago. And the boss needed this fancy feature right out. So I did it really fast. And it wasn’t as efficient as I thought. This type of thing is how you’re going to be able to find that and be able to improve these.
Maybe you accidentally typed the left joint instead of the right joint if you’re a My SQL person. Those types of mistakes, those types of inefficiencies can really add up. And these plug-ins can help you find them. Then, of course, again, we’re sticking to just the good old-fashioned browser tools.
That waterfall view sorting by how many of these are JavaScript– how many of these are CSFs? Maybe you can combine some of those. Maybe, especially with JavaScript, do you need six tracker scripts on every page? Those are the types of things that the browser tools can really help you find.
But again, I caution you to be a little bit careful with just browser tools because, as you can see on this screen load, I’ve got the debug bar plug-in and the query bar plug-in at the top. Those are loading things. So they’re not going to be the same.
Those are going to load assets that an end-user wouldn’t see. So it can be a little bit of false positives. So you have to watch that just a little bit. But together, New Relic, these plug-ins, your browser tools, and these external sites that try to browse your site as a user– Pingdom, Website Carbon, et cetera– can really help you find, hey, this is where the low-hanging fruit is. This is where things are breaking down.
This is where the slowness is happening. And those are things that maybe you can fix. 15 minutes might save you 30% or more. You don’t even have to switch insurance companies to get to it. Just a few minutes of time really might make it a lot easier for you.
Let’s talk about some specifics, though, as far as what are things we can do to help improve? 3 and 1/2 ways to speed up your site. So, of course, there’s dozens of different things. Every site’s a little bit different. So as you listen to me talk about this, remember that your site, mileage may vary.
Look at the tools and make sure you take what’s best for your site. Some of these might not apply. And there might be a dozen other things that you can do that can really help improve the site very quickly. So be a little bit careful with that.
And one of the biggest things, as I go through this too, is don’t worry so much about your theme. Themes are not the future of WordPress. We’re very close. I believe it’s this month. Sometime right around the time you’re watching this. WordPress 5.8 will be dropping with the start of full site editing.
Full site editing means you can edit now the header, the footer. Every piece of your site may not require a theme at all. So if you start going through these and finding your theme that you’ve had– maybe you paid a developer a lot of money two years ago and now it’s just not efficient– don’t worry so much about that part of it. They’re not the future of WordPress. Look for how your data is being stored and handled.
One of the best things that you may be able to look at regarding your data is how is search being effective? Search is slow. And it’s a really bad user experience. It’s 64% of users search– you search for that I want to buy moment. 43% of users go directly to the search bar. And 39% of users are influenced by a relevant search.
Its search can be really slow. If you’ve ever done a search on WordPress, if it’s not optimized and you type in one letter off, you get no results at all. Or if they have a whole lot of products, users, and everything else in there, maybe it takes 10 seconds for that search to appear. In the meantime, if I go to Amazon and search for– or if I go to Google and search for my last name and even misspell it, it’s probably still going to find me. That’s a really different experience.
And that instant search when you see on Google or DuckDuckGo versus something that’s going to take 7 seconds. Remember, after 3 seconds, people move on. So if you have a lot of data and your search has taken 5, 6, 7 seconds, you’re going to lose 40% or more of your traffic really quickly.
One of the features we’ve offered to experiment with this specifically within WooCommerce is ElasticPress. Now, ElasticPress is a plug-in by 10up that uses something called Elasticsearch. Now, what Elasticsearch does is it indexes or takes all the database information that would need to be searched. And it offloads it to something very fast to search through for it.
Our first customer that we put on this just a few months ago immediately saw 3% more orders. They saw their bounce rate drop by 2%. And they saw revenue per visitor climb by 3%. And for this particular store, that’s $4,000 a year simply by optimizing search.
And it works for one specific reason. Shoppers find what they’re looking for faster. If my site’s selling batteries, how many times all the Internet of Things stuff that we have in our smart home stuff? Your remote for your smart lights dies, and you pull out the battery. You’re not going to go browsing, searching for the word “battery” and browse until you find CR2032.
You’re going to go to a battery place that sells batteries, type in CR2032. Or maybe you put a dash in between the R and two. Maybe you didn’t put a dash in between it. It doesn’t matter. You’re going to expect an instant result that gets to the battery you want.
That fastest result means that’s where I’m going to buy from. If I’m searching for– and we’ve all done this, even on something big like Amazon. If you can’t find specifically what you want, that’s when you move off to another store. So search can really help the page load performance. It’s offloading all that processing that’s needed for search. But more importantly, it’s handling all the– it’s going to make sure users can get to what they’re looking for faster.
The next big thing is specific to scaling. And it’s specific to WooCommerce, in general. Well, everything can be handled with WooCommerce. But there is one thing with WooCommerce in particular that we really need to pay attention to. And that’s this cart fragment.
Whenever you’re on a WooCommerce store, if you add something to the cart, if you hover over the cart icon, like you see on this, you’re going to get this little mini cart. I’ve added this. I’ve added that. Maybe I’ve added six copies of it. And you can go quickly to the checkout.
It can be very handy, but it’s also very intensive. Every time somebody leaves the browser, it comes back and loads a cart. Even if there’s nothing in the cart, it loads the cart. And on a site with a lot of data, a complex older site, this can lead to a very slow site. And in the case of hosting support, we see this as one of the single biggest issues when people call our support for WooCommerce performance.
The solution to this is fairly simple. You can remove it altogether. But just like search, if the idea is getting things and the user experience, maybe that’s not the best solution. Look at the plug-ins that you have. Talk to your support person. There are plug-ins, for instance, we have a solution that can make use of caching and help cache that card a little bit better.
There’s Optimocha makes a plug-in that’ll turn it off if there’s nothing in the cart and turn it back on people who are actively shopping for things. So there are multiple solutions that we can use in order to make this cart experience a better experience and still use it, but reduce that single biggest point of failure. The more users—if you have 100 users that are shopping and maybe 1,000 users actually on the site because not everybody buys. If your average conversion rate is 7%, that means 93% of your users aren’t actually buying, but maybe they still added something to the cart.
Think about how many people are loading that cart. It can really slow down things pretty quick. They’re running processing power as if they’re actively buying, only they’re not. So look to kill that cart fragment if possible, or use Optimocha or one of the other plug-ins that throttle that a little bit.
The second thing with WooCommerce, or really any big site, is don’t hoard data. Large amounts of order data cost processing time. The biggest way to help this is to remove obsolete order data. Depending on the type of store, this may not be the best solution for you. So really look at what you’re doing.
But if you have a type of store where things are being purchased that are very time-sensitive, in 90 days they can’t return it, it may be a type of thing that a ticket or something, where they wouldn’t be able to buy it again anyway. Remove all that old order data. WordPress is not your accounting software. It should not be your accounting software. Export that order data into your accounting software and remove it from the site.
Elasticsearch can help index it as well, which may make things a little bit faster for you. But of course, the best is still to take it out altogether. Again, be a little bit careful with this. Maybe talk to your accountant. Depends on the type of store you have. But removing that order data, removing obsolete products, removing old shoppers if they’re not– if you never have repeat shoppers because of the nature of your product, remove those extra users. Maybe they don’t need to register for your site at all.
But be a little bit careful and take out as much extra data. Reduce what the database has to search for every time somebody searches for something. Change that as much as possible. Free that up for your users as much as possible.
You’ll find next to killing the cart fragments, that this will make a large site, a site that’s growing, infinitely more– not infinitely more, but significantly faster than somebody that has all that data. That’s one of the reasons an older site on WooCommerce is harder to maintain than a brand new site. All of that data collects, it’s like hoarders. The more that’s in there, the harder it is to work around it and to get through all that data. So only keep what you need to on the site itself.
And this last one is, make sure that you’re using an optimized store, an optimized infrastructure. Make sure your hosting plan is right for you. Make sure that your hosting plan can handle it. If you’ve signed up for that $2.95 special, and you know you’re coming up to Black Friday, and things are getting popular, switch over to– contact your host. Switch to a higher-end plan.
Again, offload that search. We offer instant store search here that– so if you’re on one of our WooCommerce plans already, that might be some– both of these might be already handled for you. You can also talk to your account representative if you need a higher-end plan. But in other words, plan ahead. And watch your site security.
Make sure things are updated. A lot of times when you– how many times have you updated your– your phone app updated, and the entire changelog is performance and security enhancements? That happens an awful lot with both WordPress core and the plugins. So again, if you’re with us on one of your WooCommerce plans, you might have this already covered in our SPM product.
But if you’re not on SPM, if you’re on something that’s doing this for you, make sure that you’re updating all your plugins. Make sure your theme’s on the latest version. Make sure everything’s current, so that you’re not going to have any issues with it—you take advantage of any improvements that the company has made.
WooCommerce is a big one over the years. They’ve changed how database stores things. They’ve made a lot of changes over the last decade or more in order to make things faster for existing sites. Take advantage of that, and make sure that you’re keeping up on those changes.
Watch your content creation. Use the right kind of blocks when you’re putting content together. If you’re– you might not want to be playing with blocks that add 20 images to a gallery when four will do. Watch the default limits on these blocks. Watch your content creation tools.
If they can optimize your images for you, do it. If they’re suggesting put four images up for a product, and you’re like, ah, this doesn’t work. And you go out and pay somebody to put 20 up, that’s going to slow things down. Try to use those defaults instead of increasing, especially in the case of when increasing or changing defaults is going to increase the load time of an end user.
So again, just to kind of recap all of this, watch your search. Kill the– watch your features. The biggest feature you can kill on WooCommerce, kill that cart fragments right away. And then watch your data.
Make sure your data is offloaded if people are searching for it, offloaded to something like ElasticPress. Make sure everything’s up to date and is optimal as it can be. And then just be really careful with how things are working for you.
And most of all, look at the store you have. If the store you have doesn’t require X feature, don’t include it just because somebody’s blog told you to. Use what works best for you and for your users. They’ll thank you for it in the end.
But that’s what I’m going to thank you for attending this and for listening to me. I do appreciate this. I love talking about WooCommerce and performance. And I will be available for any questions you might have.
