In a Woo DevChat, I asked Sabrina Zeidan and Uros Tasic to give their insights into WooCommerce performance. One suggestion that Sabrina made was that they come up a a few step for a developer who is not performance expert but they notice or they feel like you feel like the website is acting slow.
They don’t know whether it’s fronted or backend. It was fine a month ago and now it’s acting weirdly.
Using a Query Monitor
The first thing I would recommend is so easy. So this is not a developer tool, but it’s easy if you can add a plugin that is a query monitor. It can show you if there is some error on the site or if there are some slow queries to the database. So again, I know that there are developers going to say you can see slow queries, MySQL queries on the server. So that is advanced thing, the simplest thing, add a plugin and track, not the best thing, but you can see there if there are some issues.
Checking the Logs
If a query monitor doesn’t reveal anything or important, then I would suggest now depending on your hosting and server provider, you can check logs.
Let’s say for the people that are not experienced, there are two types of logs. One is the error log and another one is access log. So if you don’t know when something is happening or what kind of are pages causing it in access log, you can see that. For example, in the last hour you got 1000 views of specific page on the website that has a newsletter and some feed or something and then you can assume that something on that page is creating a problem and continue from there. In that case you can create test page with only one block or with only feed to see if that is going to behave slowly and then you can eliminate one by one. This is if the page is making a problem. Then you can see also if there is some current jobs or W-P-C-L-I commands and then you can address those.
For example, in multiple cases if you have a big database doing a backup, it can slow down the site because the database will be locked and then the site cannot do anything. So again, you can move backups, but you can see those details in the access login error log of the website. Again you cannot see everything there.
Using More Advanced Tools
If you want to go more advanced and I want to be actively doing on performance, there are tools that I would recommend that you can use New Relic, you can use Xdebug or you can use Blackfire. All those three tools are testing your code performance. You can record the whole page and then it’ll tell you exactly how many queries, what function is called, how many times the function is called, which file is, and how it’s behaving in the background for you.
From there you can then pick saying, okay, this plugin is taking five seconds to load on this specific page to I really need this plugin or can this be changed? Can I introduce some caching plugin, can I? But those are a little bit more advanced tools but I would spend some time to get familiar with those similar tools.
So just once more, this is Blackfire, New Relic and Xdebug. Some of them are free, some of them have a paid plan. So again, you don’t need all three but you can start with at least one. And then again, if you want to test the front end and just the Google Page speed, you can use Lighthouse or Google speed may have some suggestion.
To sum it up, first one is query monitor, easy, and there are good things about it. It’s pretty user friendly. You can just see what’s happening and if something is red, you know that strong. So it’s easy to find the bottlenecks.
The second one would be check the logs on the server, both access and error logs and then PHP errors or something like that.And the third one is use one of the tools like Blackfire, New Relic or Xdebug and again you’ll find issues with plugins but then this is awareness I’m talking about. But yes, what would your steps be?
Sabrina’s perspective as a performance engineer
I will share the steps when I’m hired to work on a websites, but steps that someone who is not performance expert but just a developer can take to identify what’s happening and if something is happening because this is the beginning of the process. So let’s say you just notice something is off. I would recommend to start with narrowing down the problem if it might be overwhelming for the person who is not used to a lot of performance information.
Google search console
I would recommend to first identify if the problem exists and if so where it does exist. I would recommend to go first thing to Google search console and check your core web vitals data and see if there are any issues there. Google Search console is place where in page size there is a small thing where you have core web vitals assessment. This is real field data from your website, but it comes from the bigger source of information and the more detailed report can be found in Google search console.
There is a tab there called core vitals. You can go there and check if your website is passing core vitals assessment. If the website is passing core web vitals assessment, especially on LCP and first input delay, which will soon be replaced with INP interactive to the next paint. So if it passing on this two, it means that real users don’t have problems with speed on your website on front end, but if at the same time you have the feeling that something is off, something is loading slowly, I would try to differentiate probably if it’s happening only when you locked in, if it’s happening for locked in users and it’s not happening for locked out users and then you will have the answer.
If it’s not happening for locked out users, there are no issues with core web vitals, then this issue most likely will be connected with something on backend that is cached or mitigated by something on front end for locked off users. Okay, this is already a lot of information for us. We already know that we should be looking in the backend because it’s happening in the backend and from this point I would recommend install query, monitor and looking there. But again, when you install query monitor, there is a huge amount of information there. If you don’t know where you are looking at, it’s easy to get lost. And some websites have a lot of issues. This happens to my clients a lot. They see that the website have a lot of issues, there are errors, there are slow queries, there are a lot of sales and scripts loading.
There are so many issues I would recommend to pinpoint what is the most easy thing to fix and the most easy things to fix are usually basic ones, First it’s PHP version. It would be so easy to, it’s really, really easy to fix. You just upgrade server to a higher PHP version test there. If all plugins play well with it, you keep it going.
Memory limits
Now the thing that is often overlooked, there is a theme that we have in WordPress that is called Ability memory limit and by default it’s set to 40 megabytes and I see a lot of cases when this default number hasn’t been changed. For years the site was surviving somehow, but now it’s not because 40 megabytes, it’s very, very low number.
But it happens often. I see that they are upgrading their hosting, they’re paying for say two gigabytes of RAM on their hosting, but there is a limit set in their WordPress to 40 gigabytes. So they never use what they’re paying for. By the way query monitor is showing that thing. So if memory limit is set to the default to 40 megabytes, you’ll see that in query monitor. That would be another very easiest thing to fix. This is something that you should be able to fix yourself and if after that the problem doesn’t disappear, that that is a sign there is a problem that this is a sign you should seek for help.
Misleading object caching
Object caching can be a very good idea and query monitor might be showing that as well. What it shows you sometimes can be misleading. In query monitor it says object caching plugin is not in use and it’s a little bit misleading because you should check numbers next to this line seeing so many hits and so many cached and if you have from 100%, you have 95% cashed, that’s fine. It means query caching is working. It’s just you’re not using the plugin to manage it, but it is working. There is nothing to worry about. So my recommendation would be try to figure out if it’s frontend or backend by going to core web vitals. Then going as locked in user and trying to figure out if it’s backend or frontend. If it’s backend, it’s still query monitor, look at query basic things like WP memory limits.
You can listen to the entire episode WooCommerce Performance Optimization with Sabrina Zeidan and Uros Tasic.
Leave a Reply