WooCommerce Caching, Scaling, Plugin Optimization, Security, Headless, and AI

Marcel:
Well, hello everyone. Welcome to another episode of the Woo DevChat with me, Marcel, and Mike. Hey, Mike, how are you?

Mike:
I’m good, Marcel. Happy Monday. Happy Monday.

Marcel:
So today we have a very special episode, and this is something we’ve been talking about lately as well in other episodes. Today we have a very special guest joining us for the show. Before we dive in, Mike, what have you been up to?

Mike:
What have I been up to recently? I’ve been making some blueprints for caching logged-in users for commerce and membership sites and caching the cart so users can still browse around and see cached pages without having to view an uncached version of the page.

Marcel:
You’re talking about the subject of our next episode because that’s very much a subject we can talk about for an hour, I believe.

Mike:
Yeah.

Marcel:
Oh, thank you for asking, Mike. Well, so I’ve been doing—just joking—I’ve been very busy with React things on the front end, so everything that has to do with hacking, I can say, the ways of React to present in either the backend or the front end. It’s been a very interesting journey, and through that, I learned that there are a lot of spaces where you can inject code into the block editor that I didn’t know about. This is probably going to be an episode, and I’m going to update my website with some of my discoveries. They’re not super fancy discoveries, but I think they might help a lot of people in injecting code and creating solutions for the block editor that are creative, I would say.

Mike:
Are those spaces intentional, or are they overlooked by WooCommerce?

Marcel:
No, they’re intentional, but I think the use cases I’m applying them to are a little unconventional. Like, for example, having information update on the sidebar as you mess with other controls on the block editor. So, sort of making the sidebar or a zone of the sidebar dynamic according to whatever happens on the editor itself and also the other way around. It’s been a little hard to describe without giving you a concrete example, but it has to do with grabbing all the JavaScript functions that you have access to on the block editor, which are exposed for people to use, and using them in a way that is a little unexpected. I’m definitely going to be talking about that in a later episode and also doing a very extensive blog post because I think it’s very interesting, and our friends at Code Audible are also interested in having us explain or expose that in a call we’re going to do. So, it’s very creative stuff. I don’t know if it’s ever been done before. It’s going to definitely make people scratch their heads about the usage I’m proposing for these React components. But let’s see, I think it’s fun stuff. Usually, we think about everything according to specific rules, and “Oh, these features are meant to be used this way or that way.” I like to explore a little more beyond that, and it happens because of a client we’ve been working on, and I think it’s very interesting to share with the world.

Mike:
Yeah, that’s really cool. There’s a term in psychology called functional fixedness. So, when you see a wrench—I had to build IKEA furniture recently, and the toolkit I opened did not have a hammer. There was a wrench instead, which you typically use for screwing things, but we used it to bang in some plastic nails. Normally, if you suffer from functional fixedness, you’d think, “I need a hammer; I can only use a hammer to fulfill this task.” But there are plenty of other ways to do it. That’s what your story reminded me of. I think it’s cool that we also share this stuff that we work on publicly, like caching the cart and logged-in users. We’ve actually been doing this with clients on Kinsta, which is where our special guest works. We’re going to do a case study sharing the details of that one day, and it’s going to be really—

Marcel:
Oh, that’s really cool. Yeah, we should definitely go back to that one in our episode when that comes out because “caching” and “cart” in the same sentence isn’t something that people usually think about—it’s black magic—and it also can—

Mike:
Work, which is really—

Marcel:
Cool. Yep, yep. Alright, then let’s get on with the episode. Today we have a very special guest joining us on the show. His name is Andre Faca, and I have a very hard time pronouncing his last name, so I’m going to ask Andre about it because it’s a very Portuguese word, as you might know already. But Andre Faca, he’s a veteran of the web hosting industry with over 15 years of experience, currently serving as a senior support engineer at Kinsta. Andre has a deep technical background in control panels like cPanel, WHM, as well as technologies like Apache, MySQL, Exim. He’s also skilled in troubleshooting PHP, HTML, CSS, JavaScript. Andre’s experience in leading teams and working closely across tech and non-tech areas makes him a true asset to any project. Welcome to the show.

Andre:
Thanks for having me.

Marcel:
Alright, so we’ve been talking about hosting in our last episode, and we’ve been covering general stuff that people need to know about hosting WooCommerce websites and the difficulties there are with the different offerings that are out there and how to deal with different situations and problems. Basically, I think the most important question people ask themselves when they start doing a WooCommerce site is, “How does scaling a WooCommerce website work for high-traffic stores?” Because at the beginning, we start with very small traffic, but eventually we are working towards having more people visit our website. What do you think should be the approach to scaling your WooCommerce website for high-traffic stores?

Andre:
Well, it really depends on the type of traffic that the person is getting because there are various types of traffic. It could be search engine traffic, it could be genuine customers trying to browse and purchase products from the store, so it really depends on that. When it’s traffic coming from search engines, for example, the best you can do is ensure that everything is optimized and use not as many cache layers as possible, but as many as necessary to ensure that it loads fast, because that’s always going to help you in the search engine rankings as well, and it’s going to be best for the performance of the website because you are not really using resources as you would if you didn’t have caching enabled. That’s one approach. Now, if the traffic is coming from real clients browsing and whatnot, the solution also goes through caching, but slightly differently. Usually, what I do when someone comes to me with that kind of problem is analyze the traffic, and one of the first things I do is check where the cache is being bypassed, because that’s easily overlooked by everybody. A lot of WordPress and WooCommerce themes will have query strings on the URLs, and that forces a cache bypass. The same thing can happen for certain objects. So there are various techniques that you could use to force those objects to use caching. We do have a couple of articles on our website that actually help you do that. When it comes to URLs, for example, when you are filtering items from a store, you’ll usually see that the query string URLs are used for the theme to understand what you’re looking for and whatnot. In those cases, I usually obtain a list with the help of the client. Of course, we get a list of the ones that are used the most, and we try to force caching on them through the configuration of Nginx. This can be done on other web servers as well, but on Nginx, it has to go through the config.

Marcel:
So you mentioned that people coming from the search engine will probably hit the homepage a lot more than other pages, I would suppose. So, does the homepage get a different treatment compared to every other page on a WooCommerce website?

Andre:
It really depends on the theme that is being used, but usually it’s different because web developers usually optimize it for speed and for cache usage so that it loads faster.

Marcel:
And when we talk about homepages, we’re also talking about those landing pages that you probably put on search engine ads, for example, if you want to promote a certain product and you build those very fast-loading pages. You also mentioned that the ranking on Google depends on or will be influenced by how fast those pages load. But when we are talking about people browsing on your website—the organic traffic that you’re talking about—that concern is more about the way that you build your catalog, right? You were talking about filtering. Filtering is obviously one of the most challenging and difficult things to do on a website. What do you think are other challenges? We were just talking about the cart page, for example, and the checkout. Are there other challenges for this organic traffic, and maybe some recommendations we can give to our listeners while they prepare for the busiest season of—

Andre:
When it comes to the shopping cart and the ordering pages, you are really forced to skip any type of caching that you have because it’s impossible to conclude transactions with it. With caching, I mean, what you could do in those cases would be object caching, like Redis, for example. It could help, but mainly it would be to use some sort of caching to cache the objects—like a CDN, for example. It could help quite a bit, but unfortunately, on other pages

, there’s not a lot that you can do to use caching and avoid server resources from being used.

Speaker 5:
Right.

Andre:
Depending on the server that you’re using, you should have a good amount of PHP workers so that you can process multiple orders simultaneously. Apart from that, there’s not a lot, unfortunately, that can be done.

Mike:
I found something recently. I was doing an audit for a client who’s hosted on Kinsta with New Relic, and I saw so many plugins executing on the cart and checkout pages that didn’t need to be—like Yoast injecting Open Graph and a bunch of other stuff onto the cart page, which, as far as I know, there’s no benefit to adding that kind of information to your cart page. So, I think one of the things we can do is eliminate the amount of code executing unnecessarily on the cart and checkout pages because everything is uncached on those pages. You’re sending data to the payment gateways, you have to add it to the database, webhooks are firing, and all that kind of stuff. We don’t need extra stuff running that doesn’t need to be there. It’s just going to take more of the precious resources that we need for the actual money-making stuff. But that requires a lot more—requires an advanced toolkit, and I think Kinsta’s APM could help you identify plugins running on those pages as well, and be like, “Oh, why is the Gravity Forms plugin or something like that running on the—?” I don’t know if it does or not, but—

Andre:
Oh, definitely, definitely. Yes, definitely. Also, look for anything in the database that could be dragging you down; that can also happen. But when it comes to plugins, usually the problem is that store owners—not all the time, but a good portion of the time—they won’t know how to do that. Like you said, it’s not easy, and you either have a good development kit for that or some sort of plugins that could help you there. If you don’t, you really have to do it manually. And sometimes it’s not really recommended because of theme updates and whatnot. Usually, that’s tied to the theme. So, there’s always that. There’s always that, yeah.

Marcel:
So, the store owners that start with a new site usually get a lot of plugins because they want discounts, they want promotions, they want the loyalty program, they want this and that. So, there are a bunch of things that WooCommerce does not offer out of the box. So, immediately at launch, we’ve seen—and I’ve seen throughout my experience—a lot of store owners already starting with 20-30 plugins without even caring about or knowing—not even caring is not fair to say—but they don’t know that they’re putting so much unnecessary load on different pages. So once they start out and they get their first traffic in, the site is slow, or some parts of the site are slow, or you’re seeing a lot of resources being consumed on the backend. So, the fact that we choose the right plugins is very important. How do you troubleshoot that? What is some practical advice we can give people who are starting out to know if their plugin choice is directly hindering site performance?

Andre:
One of the things that I’ve noticed quite a few times with several clients of ours, and even other companies that I’ve worked for, is that sometimes users read articles that recommend a large portion of plugins, but they don’t recommend using them all simultaneously, and they install them all. So, this is one of the problems there. This is one of the problems there. Usually, what I do in those cases, if it’s a matter of plugins running, you could use the APM tool. You could also use the browser tools—the inspection tools—to check on that. But, like we were saying, when it’s a large number of plugins, it’s inevitable that at some point you’re going to have difficulties.

Marcel:
And just for everyone who’s listening, an APM is basically an application performance management—or is it called that? I think it’s right—or application monitoring tool that allows you to measure individual web requests and transactions. It allows you to take a look at how much resources are being spent on a page load and how many requests are being made to the database and all of that, right?

Andre:
Correct. It’s application performance monitoring. That’s exactly what it does. It shows you the external requests, which sometimes are also the cause for pages to take longer to load because there’s an external request before the actual page load completes, and that drags everything down. It’s not uncommon to see that due to API calls. I’ve seen licensing servers causing that as well.

Marcel:
Wow.

Andre:
Yeah, it’s not as uncommon as people would think. All it takes—if you’re using certain premium plugins—is one licensing server being slower than usual, and you’re going to notice it.

Mike:
Especially in the backend. WP admin is one of the most common things I see with New Relic and other APM tools—five plugins, premium plugins phoning home, and you’re like, “But I’m trying to check my orders. Why are you doing this?”

Marcel:
We also have to remember that WordPress is not like an app that has background processes running all the time doing separate jobs. The opportunity a developer has to run something is whenever people call a page. So, whenever a page is called is when all the different stuff happens in the background, if I can say it like that. So, all the scheduled actions that we have and all of that get only fired or programmed or scheduled if there is actually an access being made to the website. And what I believe happens with those situations is they don’t want to miss an opportunity. So whenever a request comes—that might be just a cart request or any other request—they don’t have the sensibility to inquire first what type of access is being done so that they can make a decision about whether to load this now or delay it to another opportunity. They just go in and maybe take the most reused filter on the WordPress system or action or hook and just say, “I’ll run it right here. It doesn’t matter. I’ll take the first seat on the wagon and update this.” So, people have to be aware of that, right? And these APM tools allow you to look into that. It’s like a microscope and gives you the ability to exactly know what’s happening under the—

Mike:
I wanted to mention something as well that Andre said about a new WooCommerce store owner reading a beautiful blog post with all these cool recommendations. It’s not uncommon to see two or three page builders installed on a WooCommerce store. It’s common to see two or three form plugins on a WooCommerce store. And I try to tell clients, treat your website like it’s an F1 car. If you want to win and perform well in F1, you don’t just add any engine or any parts without thoroughly looking at them, examining them, turning them all over and being like, “Ah, is there a way that we can tweak this and rebuild it so it only has the pieces that we need that our customers are going to value or that our employees are going to find beneficial?” And I think even if you don’t like F1, it’s an approach that most people can relate to. It’s the same thing with your house. If you want to be able to find things and move efficiently through it, it can’t be a big mess and disorganized everywhere. Things need to have a purpose and be chosen carefully. Don’t just get a massive table for your dining room if you have a small dining room, for example, or a bed that’s so big that you can’t walk around and navigate inside your bedroom. So I think that’s really important for us as developers—to educate WooCommerce store owners—because a lot of them aren’t technical or are dangerous enough with the knowledge they know to make a negative impact without necessarily knowing why that’s having a negative impact.

Andre:
Very good analogy, and I totally agree. Not to mention the plugins that always leave remnants behind them.

Mike:
Yeah, that’s one of the things we’re doing for clients now—these database audits that are very, very thorough and look everywhere and anywhere. And one of the places, of course, is the options table that gets stuffed with a lot of leftover things, and plugins don’t clean up after themselves. Well, 99% of them don’t. And there’s a reason for that, right? You re-enable the plugin, and then customers or the store owners would be angry, like, “Where did my settings go?” So, you understand why developers make these choices, just like with Marcel mentioning the licensing checks. But I think we would all benefit more from people having this performance hat on, like the F1 manager is not going to allow licensing checks to be happening while the tires are being changed in an F1 race. It just wouldn’t happen.

Andre:
Very good point. When it comes to the cron that Marcel was talking about earlier, one of the things we usually recommend doing when you’re having problems with performance is disabling WP cron, because at Kinsta, you still have a system cron job running there manually every 15 minutes. So, that’s one of our recommendations right away when people start having those problems because, like Marcel said, if you have WP cron enabled, each page load will trigger an enormous amount of actions, especially if you have a large number of plugins enabled.

Marcel:
So, for people who don’t have access to these A

PM tools, what do you recommend for optimizing performance, and what else can we do? Turning on and off plugins is the old advice that almost always works, but are there any other recommendations we can give people?

Andre:
Usually, the recommendation I give to clients really depends on how knowledgeable the client is when it comes to web development. But usually, I try to help them learn how to use the inspector tool on the browser because it helps quite a bit, especially if it’s just a silly request, if it’s just a request taking too long. But if that doesn’t help, there are tools for that, like New Relic or certain plugins that do a similar job—Perfmatters, for example.

Marcel:
Query Monitor.

Andre:
Yeah, yeah, yeah.

Marcel:
I usually try to explain to clients when they come over and say, “My website is slow,” that there are mainly two parts to it—the part that runs on the server and the part that runs on the client side, in the browser. And because nowadays we’re having a lot more JavaScript being loaded at different times and we have a lot more processing being done on the client side, the actual way that people perceive the loading of the website is not always attributed to the backend part of it—to all the processing that PHP does before it starts sending the first bytes to the browser—but it has also a lot to do with what happens in the browser right after all the JavaScript is being given to the browser, and now it has to deal with all of this information and execute it in an order that makes sense. And so, those are two different parts to the problem that I start explaining to people—backend and frontend. So, on the backend, we’re talking about whenever people make a request to a certain website, it goes to the server, and then the server starts working on building that request or that HTML that is sent back to the browser. Plugins have an influence on that, but also queries on the database. What is your experience with dealing with those issues and problems? Because we do have long-running queries on WooCommerce, and that is quite common, right?

Andre:
It is, it is.

Marcel:
How do we get to know that a database is running a long query?

Andre:
Usually, we are going to go back to the APM tool because, yeah, that’s our standard at Kinsta—we always use the APM tool or something similar that will help you because the problem there is that you need to know the time it’ll take for that transaction to complete on that specific request. So, the best option for that would be to use an application monitoring tool. It could be ours, but it could be New Relic or something else.

Mike:
I think there’s also the slow query log—you can enable that by default. I know a lot of hosts do, and—

Andre:
We don’t. If necessary, we can ask our system admins to enable it, but usually it’s not really necessary because usually, if we search and if we enable the APM tool, we will figure out very quickly what’s causing that to happen.

Mike:
And Marcel, I wish there was another way besides using an APM tool to capture these queries. You can use Query Monitor, but that requires the query to happen during your transaction as you’re—and the slow query might happen during the cart or the checkout process, or a visitor viewing the homepage or something like that. And then you don’t have a chance unless—because Query Monitor only runs in the background.

Marcel:
And also the experience I’ve had activating those monitoring systems on the plugin level—it’s also a weight on the PHP worker, so it’s kind of like using the same slow train to figure out why the train is slow. So you put more weight on it, asking yourself what’s the other half that is causing the train to go slow, which is not a very effective way to do it, right?

Andre:
True, true, true, that’s true.

Marcel:
So, we have to go a layer below it, as you’re saying. APM tools will definitely be a good way to do that. As far as the frontend part is concerned, is there anything that a hosting company can do to also help people identify if the frontend is the one that is dragging the website or the loading of the website?

Andre:
You mean the browser side of things?

Marcel:
Yes.

Andre:
Yeah. We will usually guide our clients to try to understand what’s going on. Usually, like I was saying earlier, personally, what I do is I point them to the browser code inspection tools because usually, you’ll see right away if there’s something causing a delay there or if there’s a script failing. You’ll usually see it there through the console or the network tab, regardless if you are using Chrome or Firefox, it’s very similar.

Marcel:
Or Safari. I just wanted to say that. Yeah, the network tab is actually very, very important. And also the fact that you can know how much time a script is taking, how much a script is wasting to load, and all of that stuff, not only after it’s loaded but while it’s loading, right?

Speaker 1:
Avalara wants to make sure that your projects go smoothly, and part of that includes doing it right with their AI. Their resources cover it all to help your clients manage sales and use excise, GST, VAT, and other tax types across the US and abroad. You’ll find it all on their site, and you’ll be learning more on how they can help you during their sponsorship of Woo DevChat. Want to learn more? Just go to developer.avalara.com.

Marcel:
Can you tell us a little bit more about HTTP/2 and, I think, version 3, which is also being talked about? This is an area that I have very little knowledge on, but I do think it’s very important for people to know that the hosting company has a web server—let’s call it like that—Nginx, Apache, whatever we use. And that is also very important, not only for the PHP processing part of it but also for delivering the assets on a webpage. If you have a website that has 40, 50, 60 different assets to be loaded, we cannot simply download them all at the same time. There are challenges to that. Can you speak a little bit about that? What is HTTP/2, and what’s coming in the future to help us deal with that?

Andre:
Yeah, we do actually have it for some time now. But yeah, previously, it was called HTTP over QUIC.

Marcel:
Exactly.

Andre:
Yeah.

Marcel:
Yes.

Andre:
So, I actually didn’t see HTTP/2—the plain HTTP/2—at Kinsta, so I cannot really tell the difference there, personally. It was always this fast due to QUIC, but—

Marcel:
So basically, what we have is HTTP only allowed you to download one asset at a time, so it was somewhat hindering the process of loading assets in terms of the quantity of JavaScript, images, and whatnot. But then we also have CDNs which come into place, which are being served from another server and have the ability for you to get assets elsewhere—maybe a data center that is near your city where you’re asking the website from. From what I understand, the basic difference between HTTP/2 and 3 is relying on UDP protocol instead of TCP protocol to transmit all of that. But I am not 100% sure about that. The main thing, I guess, people need to know about this is that whenever possible, use HTTP/2, and when 3 becomes available, also use that. I remember when HTTP/2 came along, some of the hosting companies were putting that information on their marketing side or marketing end of it as being something revolutionary, something that was very important for people to have. Right? Do you recall that?

Andre:
On HTTP/2?

Marcel:
Yes.

Andre:
I do, I do. I do.

Marcel:
But nowadays, I guess everybody is doing HTTP/2, right?

Andre:
It’s pretty much the standard nowadays, so I don’t think I’ve seen HTTP/1 for a long time.

Marcel:
Right, right. What do you think are the lesser-known WooCommerce features or plugins or things that you have seen that you didn’t know, perhaps, existed, or some story that you might have that was something very weird going on in the backend that you’ve taken probably a little bit longer to figure out? Do you have any stories like that you could share with us?

Andre:
I had one of them with a client two weeks ago, I believe it was two weeks ago, where I basically had to research their website for quite a few hours, and it was actually due to a caching plugin. So, I’m not going to name the plugin, but it’s a very popular one. And it was actually causing a conflict with our cache. It was basically trying to cache our cache, and it was slowing things down, causing a loop. The client was very frustrated with that. Of course, not everyone does this, but the first reaction you have—if a site is working fine and the next day it doesn’t work—is usually to point to the web hosting company. So, they were pretty convinced that it was something with our cache, but in reality, it wasn’t. It was just a plugin

that had been updated. They had updated some of the code, and it was causing problems with their particular website.

Mike:
One of my favorite first steps when I’m troubleshooting a slow website is disabling all of the performance things—all the things that claim to be making a site run faster. I disable them and see how things are, especially if you know there’s server-side caching on the host. There’s no reason to have other caching plugins installed or active. Yeah, you get these weird collision effects or infinite loops, which ironically cause the site to crash or run out of resources.

Andre:
Some plugins, some caching plugins, will detect nowadays—they will detect during installation if you’re using Nginx or something like that—and they will disable some of the functions that don’t work properly, like page caching is one of them. You have many plugins that, as soon as they detect that you’re using Nginx and you have caching enabled, they disable that right away because it works very well for Apache servers, for example. It works pretty well, and IIS, but when you do that on Nginx, it’s going to cause the site to become way slower. Sometimes.

Marcel:
It’s sometimes also difficult to figure out what type of caching is being used on a specific hosting company, right? Because I always try to put myself into the perspective of a newcomer to this system. Somebody who heard, “WooCommerce is great; WordPress is awesome; it scales and everything.” And once they start digging in and they reach the cache topic, it’s hard to figure out where to even start choosing a hosting company. And we talked about this in the previous episode, where it’s like, “Okay, do I go with a hosting company that has more caching options or less?” And if they have all these caching options, can I also use the plugins? Are the plugins smart enough to realize that the hosting is already doing some of the job and not conflicting with them? And unfortunately, the reality is that that’s not the case, and there’s a lot of conflict going on with the caching systems around the different options. So, in your experience, and particularly maybe in Kinsta, what is the ideal setup for WooCommerce? What is your opinion on that?

Andre:
By standard, we don’t recommend caching plugins if you’re using ours because we also offer a plugin of our own that will manage caching for you. It will delete the cache for a page that you edit—that page alone, not the entire cache for the website. So, in most cases, you don’t really need anything else. However, if you do—because there’s also the possibility that you need to do object caching and other optimizations that our plugin is not going to offer you—in that case, we sometimes recommend WP Rocket, for example, which does a pretty good job. It detects that Nginx is in use right away and disables the page caching feature. But apart from that, just the standard recommendations. It’s usually, if you’re using caching already, don’t add layers of caching because that’s not going to help much.

Marcel:
Right. There are a lot of caching plugins out there that people use, and there are also a lot of tips that one can give about caching. Caching is not all of it—resources are also very important. Do you feel that WooCommerce websites should scale automatically? Meaning, whenever you have high traffic, more memory, more CPU, more PHP workers should be allocated automatically. What is your opinion on that part?

Andre:
It really depends on the case, but I think there should be set limits. It really depends on the case, but in most cases, security-wise, you should have a limit.

Marcel:
Okay.

Andre:
That’s one of the issues there. It’s always convenience versus security, right?

Marcel:
Correct. That’s the point I wanted to touch on because people do think, “The fire is running out, just throw more gas on it,” and if you throw too much gas on it, it may explode. And there’s a similar situation with hosting. Just throwing more resources at a website is not usually the answer, and there are dangers.

Andre:
It’s just a temporary band-aid. Yeah, it doesn’t really help.

Marcel:
Yeah, yeah.

Mike:
You want to be able to identify why resources are running out, and that’s where, again, an APM tool comes in handy to find out which functions are taking a long time or gobbling up the most amount of memory, and then actually going in and patching those and fixing them instead of just throwing resources at the problem, which is, like Andre said, a band-aid solution. It goes back to the F1 analogy. You wouldn’t just keep throwing more gasoline into the car. You’d want to know, “Oh, why is it burning fuel three times faster than we calculated it’s supposed to be?” Right. You wouldn’t just keep throwing gas in there.

Andre:
A good portion of our plans offer a standard limit, which is 256 MB of RAM for PHP. And sometimes I find myself trying to explain to clients that PHP—and this is good for developers to understand, developers already understand, but more so for store owners to understand—PHP is a text processor. It’s just text going through it. If you’re using, let’s say, 1 GB for PHP, it’s not normal because it’s just text, right?

Marcel:
Correct, yeah.

Andre:
So ideally, 256 MB should be plenty for a PHP process in normal circumstances, of course.

Marcel:
Right, right. That’s actually a good point because I do see a lot of clients, the first thing they ask about is, “Let’s just increase the memory, and that will fix it,” and that’s usually also not the case. How different is hosting for WooCommerce in comparison to regular WordPress? What are the main keys? Because we’re talking about memory, 256 MB, we’re talking about not opening up all the resources you can have, but what’s the main source of—or what’s consuming—let me rephrase that question. What brings WooCommerce to the table that requires you to have a different setup on the hosting?

Andre:
It really depends on the website as well because you have websites using WordPress without WooCommerce that use a lot more resources than the WooCommerce site, actually. So, it’ll always depend on the situation, but usually the usage will come from plugins, from a database structure that is not optimized. Usually, what I see happening very often is that a store is running for four or five years without any sort of optimization. The records pile up, especially the ones from post meta, for example. Transients, when it comes to WooCommerce, are also very common for that to happen. So, yeah, usually those are the culprits.

Mike:
And a good idea to do before holiday readiness—the year before, ideally. But the reality is most store owners start around now or a couple of months ago. It’s unfortunate because it’s sort of like going down into the basement that you haven’t been to in four or five years, and you’re like, “Oh, what is all this crap? Do we need any of this?” And then you start going through the different people who are responsible, and it’s like, “Oh, well, that guy hasn’t been here for the last three years. We don’t know if that’s still in use.” And there tends to be a lack of orientation and paper trail of why this script was added, where was it added, was it using a plugin, or did we put it straight into the head, or did we put it in Google Tag Manager? And there’s just a lot of general messiness when it comes to this. And I’m curious, what other recommendations do you have for clients to get ready for the holiday season in terms of load testing, profiling? What would your approach be?

Andre:
Load testing is definitely a good recommendation. Try to optimize the database as much as you can. I cannot say that enough because it’s usually one of the common culprits there. Also, depending on the website, sometimes the order tables pile up. Obviously, you cannot clean them, but usually a good optimization on the database will help quite a bit.

Mike:
I actually have a client who gets 10 GB of orders’ worth of information each season. He sells something related to fashion, so there’s a very specific short sales season. And then when he’s done, he actually exports all of the orders into a Google spreadsheet and then deletes them from the database. He’s allowed to, based on whatever rules he needs to follow for the laws in his country. There are thousands and thousands of products, and all the products are no longer sold after that season. It’s not something that you can buy again. So, he actually deletes all of the products, and we have to delete all of the images for him manually because, for whatever reason, deleting the products doesn’t delete the associated images with those products. So we had to build something for him to do that. But yeah, it is possible to do both, but it depends on the laws of your country. You usually have to retain the order information for at least five years or something. So, I think that’s why he puts it into a Google sheet in case the tax people come after him with certain questions or whatever. But yeah, it’s certainly a good idea because the database keeps growing and growing. And if you have a successful store, that’s a great thing, but you’re also going to need to pay for more and more hosting resources, especially RAM, to accommodate a database of

that size. So being able to export what you don’t need anymore and put it somewhere safe so that there are more resources available on the host for the store, I think, is a really good—

Andre:
Indexing also helps quite a bit on the database—indexing the entries.

Marcel:
We had already an episode where we talked about that, and it’s actually incredibly amazing how that works and how that can fix various problems and long-running queries. I would like to also talk about security, which I think is very important. Have you seen security vulnerabilities happening lately on WooCommerce? And if you have experienced one that stood out most, or if you have any stories around security that you would like to share, what have you seen? And if so, what are the recommendations you have for mitigating them?

Andre:
Security-wise, lately—and when I say lately, I mean the last three or four years—I haven’t seen anything very important. No. And even at Kinsta, usually we do have a team that manages that specifically, so even if that happens, it’s usually the support team that won’t see it because we will see it when it’s resolved.

Marcel:
Obviously, the most recommended action would be always to keep things up to date, and people actually have an issue with keeping things up to date, right? They are afraid of hitting the update button.

Andre:
That’s the problem. That’s exactly the problem. And we’re going to go back to the plugins again because it’s usually due to using so many plugins that they have to keep everything in sync. Sometimes if you update one plugin, it’s going to cause problems with a certain function that another plugin is trying to fetch, and that creates a snowball effect. So usually people are afraid to do that.

Marcel:
Exactly, exactly. I would like to ask two more questions before we call it a wrap today. The first question has to do with headless WooCommerce. What is your opinion on headless setups? I don’t think we can say they are becoming popular. I think there was a phase in the past where they did become very popular, and then people thought, “Okay, maybe that’s not exactly what we wanted,” because it’s even harder to set up than a regular e-commerce setup, I would say. But do you have an opinion on the headless aspect of it, and is it actually more—if it is recommended for people to adopt the headless approach to an e-commerce website or not?

Andre:
It’s also going to depend on the type of website, but I’ve seen quite a few of them. And when it comes to performance, if it’s a simple website, you really notice the difference. I’ve seen better performance on blogs, for example. Not specifically on WooCommerce. I don’t think I’ve seen a headless WooCommerce store anywhere yet. The headless installations I’ve seen so far are usually blogs and personal sites and whatnot, but you can notice the difference, yes.

Marcel:
Right. It’s only been very recently that WooCommerce, the core part of it, has updated all their REST API endpoints so that you’re able to fully integrate WooCommerce in a headless environment. And I’m talking about the cart endpoint, the checkout endpoint, and all of that. Storing the session for a particular anonymous user through REST API calls is not an easy thing to do, and now you obviously can. I also have not seen a very popular website using a headless WooCommerce setup yet. But I do believe that they bring some advantages, as you said, depending on the type of website we’re talking about. And it certainly reduces the stress on the server side because the requests we make on that particular setup are more about very specific parts of the information we need for the website and not the whole website itself. So, there’s a lot of improvement on that part. But yeah, I haven’t seen them a lot. Mike, have you been in contact with headless WooCommerce websites, or have you seen them around?

Mike:
No, I haven’t seen any headless WooCommerce sites. I’ve seen one or two regular WordPress sites that were headless. I’ve seen more static WordPress sites, which I think have a greater use case, especially if it’s a blog where you don’t need to do post requests or anything like that. I think there is a huge benefit there. Then you can just cache the entire site as HTML and serve it with Nginx, and you’re very, very happy—very low resource utilization. But I think headless was one of those fads that a couple of years ago was like, “Oh, headless is amazing.” And then everyone kind of realized, “Oh, this is a lot of work and kind of painful, and we don’t really get why this is supposed to be so much better.” But I never tried it myself, so that’s just my impression. We haven’t heard much about it in the last year or two.

Marcel:
Would you, Mike, charge more if a client asked you to build a headless WooCommerce website compared to a regular one?

Mike:
Absolutely. Yeah, for sure. Anything that adds complexity. When a client comes to me with their slow website and I find out they have a page builder plus a membership component plus WooCommerce, plus—there are certain things that add up, and you’re like, “Oh, you’re going to be five times the amount of work,” and hopefully they have the budget to accommodate it. So, I think it’s important not to overcomplicate things just for the sake of, like, “Oh, look, we did it,” which I think headless might have been at the point of being there, if I’m honest.

Marcel:
Yeah.

Mike:
Yeah.

Marcel:
Well, the actual adoption of the React framework within the WordPress system is also making people ask about which part of the frontend should we make headless or dynamic, or which should hit REST API endpoints rather than load full pages. The filtering system that WooCommerce has has very largely benefited from that as well, I would say, because you just need to get a couple of product details, not upload the whole page for that. And we know how filtering is very expensive on the resources as well. One last question I would ask Andre about is the AI part of e-commerce. Have you seen a lot of people using AI lately to build websites? Or is AI a topic at Kinsta in any shape or form?

Andre:
We discuss it. We cannot be certain how many people are using it, but I believe there’s a large number of people using it nowadays, especially if you’re building a store. If you need product descriptions—and I know this because I did that myself when testing websites to obtain content and whatnot—I guess it’s one of the most common uses for AI at the moment because it saves you a ton of time, especially if you’re the store owner and you need a description for something you’re selling, something that you’re just adding to the website. AI is going to do a great job on that.

Marcel:
Understood. Yeah, definitely for product descriptions and coming up with titles and all of that, I’ve seen that happening.

Andre:
There’s also support, but there’s also support. But at Kinsta, we are not really discussing that at the moment because one of the benefits of being a Kinsta client is the personal support that everyone gets, and with AI, we would certainly lose that. But for certain business owners, it could make sense. You’ve seen that on AliExpress and sites like that—they already use AI. But it’s not perfect. That’s the catch you have—it’s never perfect.

Marcel:
And you’ve also seen it in other hosting companies related to WordPress offerings out there. But maybe where AI could be helpful is for those agents as well, so that they can use it to better understand the client’s issues or propositions or whatever is happening. So, as an agent—as a support agent—to use AI to help better serve the client. Maybe that could be something that could be improved in the future, I guess. Because it’s also very frustrating when you’re talking to somebody on the other side and you’re asking a couple of questions, and they go through all of that basic set of questions like, “Did you uninstall and install?” or “Did you delete this or did you delete that?” Although I understand it is important for those questions to be asked because it creates a context around what’s happening, it’s also sometimes frustrating from the client side to go through all of that process. So maybe AI could help with setting up the context for that particular case.

Mike:
I’d love support query systems to have those kinds of checklists generated by AI or their internal team, and then when they’re delivered, instead—because I think support is one of the most frustrating parts of our job where I know what kind of help I need, but you don’t always necessarily get it as quickly as you would like. And I understand that you need to do these things on Andre’s side. He needs to ask these questions. “I need to make sure you did these five basic things before I get into the more advanced solutions.” Some kind of question list that had little checkboxes that you could just tick inside of Intercom or whatever kind of thing so that the support technician could see really quickly, “Okay, these are the five things we needed them to do.” And instead of writing a five-paragraph response of, “Yeah, I did this, da, da, da,” it’s just like, boom—it took me a second to check. “Steps were already taken, please, let’s go to the advanced

, good stuff where we actually solve the problem.” I think that would be cool. I also have a question for Andre before we wrap up. What is the most memorable support case you have involving WooCommerce—the one that made you go WTF or like, “Wow, I can’t believe that just happened”?

Andre:
I never had a nightmare case, but I do remember a client from last year, I guess it was last year, that I actually helped for a few days. When I say a few days, it was probably a week, because he came from an Apache server, so nothing was optimized for Nginx or caching whatsoever. From what I understood, the client had been hosted on a plain Apache server, cPanel. So I had to manually go through the URLs they were using and make a list—with their help, of course—of cache exceptions and whatnot. Obviously, they were experiencing some difficulties when it came to performance because they were using all the PHP workers after some time when they had a lot of concurrent orders and whatnot. So from what I remember, yeah, that was one of the most difficult cases that I had there. Not difficult, but time-consuming.

Marcel:
And before we go, I have one last question for you, and that is—I’m almost guessing the answer, actually. I’m going to write the answer down before I ask you. It’s a very, very obvious thing to me, I guess. I hope I’m not wrong. But what is your absolute favorite tool that you’ve ever used to help people out with support?

Andre:
I don’t think I have a favorite one, to be honest. Are you referring to tools that we use internally?

Marcel:
Whatever you think is a good thing to share with us. Yeah, one tool that has made your life a lot easier.

Andre:
SSH, to be completely honest. SSH.

Marcel:
That was not what I wrote down!

Andre:
If you take SSH away from me, yeah, I cannot function without it.

Marcel:
That’s actually—yeah, as developers, we would say the same. SSH is a lifesaver.

Andre:
Yeah. WP-CLI, something like that.

Marcel:
Yeah, yeah. I definitely agree. Mike, what is your favorite tool?

Mike:
Well, maybe it’s what you wrote down. It’s probably usually doing performance-related stuff, so it’ll be New Relic or another APM tool. But without SSH, it’s going to limit my ability to help clients. So, if a hosting company doesn’t have SSH, I’m like, “We’ve got to get you somewhere that has SSH and an APM tool, or I—”

Andre:
Because you can do a lot through SSH, right?

Mike:
Yeah, exactly. I mean, you even have WP-CLI’s Code Profiler, so it’s not the same as New Relic, but it gives you something to run off of, and you can’t run that without—

Marcel:
And the fact that you can create scripts that have a looping system, that can go over and over again, do the same thing until something happens or gets solved or whatever. And also for the reporting—if you want to log stuff and quickly build a list or measure the time between A and B, something that is happening—all of that is possible with SSH. And definitely, we should choose a hosting company that offers SSH. And I believe for hosting companies, it’s difficult to make SSH a solid, very well-structured tool to use within a system that you don’t want to accidentally give people access to stuff they’re not supposed to be doing on a server through SSH. But I do believe that most of the hosting companies today now do a good job of not restricting too much so that we don’t have all the tools available—don’t strip too much of the options—but also don’t expand in a way where it might become dangerous and people are afraid of having those tools exposed. Well, Andre, thank you so much for joining today’s episode. It was a pleasure talking to you.

Andre:
Same here. Same here. Thank you.

Marcel:
I also wanted to do a shout-out to Roger Williams for making this happen and for giving us your precious time and letting us pick your brain on all the subjects we talked about today. I hope we see each other sometime soon because we are all talking from the wonderful country of Portugal, and this is me just getting some affiliate money from the tourism department. I hope they’re hearing this. Thank you so much for coming up. Mike, my pleasure. Any last words before we close the episode today?

Mike:
Just thank you for your time. It was really cool to get the angle and perspective of someone who works with WooCommerce on a daily basis from a support perspective—that’s not from a plugin or a theme—working inside the hosting industry. I think it’s really cool, and we hope to have you back on someday.

Andre:
Sure, sure. Whenever you want to.

Marcel:
Alright. Thank you so much for listening. This has been another episode of Woo DevChat, and we hope to catch everybody in our next episode.