What are we learning about today?
Joining me again today is performance expert Sabrina Zeidan, she specialises in speeding up WordPress websites. Sabrina will be sharing valuable insights and practical tips to find out what’s slowing your site down, and how to fix it.
In this episode, we dive into a very interesting case of high CPU usage on a WordPress website. The website in question is a fundraiser platform where each square represents a WooCommerce product. We will explore the steps taken to investigate and resolve the issue.
Initial Observations
Stephen, the website owner, reached out to us with concerns about high CPU usage on his server. After analysing the error log provided by the hosting support team at SiteGround, Sabrina discovered that the website was making frequent requests to itself, resulting in a significant CPU load. This indicated a possible issue with the caching system or a malware infection.
Troubleshooting with Health Check and Troubleshooting Plugin
To narrow down the cause of the high CPU usage, Sabrina recommended Stephen to use the Health Check and Troubleshooting plugin. This plugin allows you to deactivate plugins and switch themes without affecting the user experience. By activating the Query Monitor plugin and systematically activating each plugin one by one, Sabrina was able to identify possible culprits.
Uncovering the Culprit
After activating the SiteGround Optimizer plugin, there was a significant increase in the number of database queries, reaching a staggering 1,645 queries. This raised concerns about the caching system and potential conflicts with other speed optimisation plugins installed on the website.
The Pitfall of Multiple Caching Plugins
It’s important to note that using multiple caching plugins for the same purpose can often lead to performance issues. In this case, the combination of the SiteGround Optimizer plugin, the website’s built-in caching system, and other speed optimization plugins created a complex caching setup that was not playing nicely with each other. This resulted in increased CPU usage and a lack of efficient caching.
Auto-Loaded Options and Heartbeat Issues
Further investigation revealed issues with auto-loaded options and the WordPress Heartbeat API. The size of the auto-loaded data was within acceptable limits, but the number of database queries triggered by the caching system was a cause for concern. Additionally, we noticed inconsistencies in the caching behaviour, with some pages being served directly from the server instead of the cache.
Next Steps
With these initial findings, Sabrina advised Stephen to review the caching configuration and consider streamlining the caching setup to avoid conflicts. She also recommended optimising the auto-loaded options and addressing any issues with the WordPress Heartbeat API. By addressing these issues, one can reduce the CPU load and improve the overall performance of the website.
In the future, Sabrina will be analysing user-submitted websites for free during the show, so make sure to visit wpbuilds.com/speed if you’d like her expert evaluation.
As always, remember to share this episode with your colleagues and friends who are interested in improving their website speed. Let’s dive right into our conversation with Sabrina Zeidan on how to ‘Speed It Up.’
Mentioned in the show:
Health Check and Troubleshooting plugin
Overview:
- [00:00:04] Introduction to the podcast and the Speed It Up show with Sabrina Zeidan.
- [00:03:15] Farewell to David. Nathan announces the departure of David Waumsley from the WP Builds podcast after 7 years.
- [00:09:05] Investigating High CPU Usage. Sabrina discusses the high CPU usage issue on Stephen’s website and the initial findings from the error log.
- [00:19:05] Using Health Check and Troubleshooting Plugin. Sabrina explains how she used the Health Check and Troubleshooting plugin to identify the problematic plugin.
- [00:26:38] Identifying the Caching Issue. Sabrina discovers that the SiteGround Optimiser plugin is causing high database queries and caching issues.
- [00:30:00] How to Check if a Page is Served from Cache or Server. Learn how to check if a page is served from cache or the server using Chrome developer tools.
- [00:31:00] Investigating the Cache Issue. Discover the steps taken to investigate the cache issue, including checking headers and multiple cache layers.
- [00:33:52] Debugging and Enabling New Relic. Find out how to enable debug logging and use New Relic to debug cache issues.
- [00:38:20] Troubleshooting and Optimising Performance. Learn how to troubleshoot and optimise performance by deactivating plugins and monitoring resource consumption.
- [00:36:30] Resolving the Cache Issue. Discover the solution to the cache issue by turning off the SiteGround optimiser plugin.
- [00:37:27] Investigating Conflicting Caching Layers. Understand the challenges of multiple caching layers and how they can interfere with each other.
- [00:42:12] Further Investigation and Troubleshooting. Explore additional steps to investigate and troubleshoot the cache issue, including adjusting settings and testing different configurations.
- [00:46:25] Conclusion and Final Thoughts. Wrap up the episode with final thoughts and recommendations for resolving cache issues.
[00:00:04] Nathan Wrigley: This episode of the WP Builds podcast is brought to you today by Omnisend, the top rated email and SMS marketing platform for WordPress. More than a hundred thousand merchants use Omnisend every day to grow their audience and sales. Ready to start building campaigns that really sell? Find out more at www.omnisend.com.
And by GoDaddy Pro, the home of managed WordPress hosting that includes free domain, SSL, and 24 7 support. Bundle that with The Hub by GoDaddy Pro to unlock more free benefits to manage multiple sites in one place, invoice clients, and get 30% of new purchases. You can find out more at go.me/wpbuilds.
Hello? Hello? Hello. Once more. It is, the, I think seventh, I can't remember. I think we're on episode seven. It's seventh. Wow, you've remembered. Yeah. That's brilliant. It's episode seven of the Speed It Op Show with Sabrina Zeidan. Hi Sabrina. Hi Nathan.
[00:01:16] Sabrina Zeidan: Hi.
[00:01:16] Nathan Wrigley: Hi everyone. you are, you are in familiar surroundings.
I, I recognize where you are from a long time ago. Do you want to get into that? Do you wanna tell us where you are or not?
[00:01:27] Sabrina Zeidan: I'm back at home in Kyiv. I'm super happy to be here. That's all I have to
[00:01:30] Nathan Wrigley: say. Yeah, that'll be fine. Yeah, that's, perfectly Okay. Sabrina is joining us most weeks. We had one week where we had technical gremlins and so we didn't do a show, but on most occasions, Sabrina's gonna be here at 3:00 PM UK time, live on our.
Live page, which is WP Builds.com/live. I might as well show that on the screen because I've got a caption for it, there it is. WP Builds.com/live. If you fancy sharing that and dragging some of your friends relations. I. In. Feel free to do that. Please do. Yeah. Yeah, exactly. And over there, there are several ways of making comments and we love it when you make comments.
I can see that somebody, Steven, in fact, has already made a comment. We'll share that with you in just a moment. But if you want to make comments, that's brilliant. Over on the right hand side, if you're on a desktop, if you're on a mobile, it'll be underneath. But there's a box with YouTube comments in.
And obviously in order to put your comments in there, you need to be logged into some kind of Google account 'cause it's YouTube. Alternatively, if you look inside the video and you go to the top right, there's a little button, I believe it says live chat or something like that. And for that, you don't need to be logged into anything.
You can remain completely anonymous if you happen to be joining us from Facebook. you've gotta go through one additional step. You've gotta go to wave video or slash lives slash Facebook, and that will allow Facebook to give us your, your avatar and username and things like that. You can, of course, stay anonymous on Facebook.
We'd just appreciate it. If you tell us who you are, that would be really nice. Yeah. But, yeah. shall we, actually, firstly, I've got something a bit sad to say. First, do you mind. No. Okay. About two hours ago, he said, with a tear in his eye, I released a podcast episode. And after seven years of doing the WP Builds podcast with David Waumsley, he's gone.
he's left us. It's, it's a sad moment. we released an episode today called Bye-Bye. And it's, the farewell. But for me and David, he's, he literally joined me on more than half of the episodes. It was always a, an interview David. So it went and, he's moving on, but fear not.
Because there's a bit of a surprise. We'll leave it until the new year, but something is afoot. hopefully we'll be able to continue our relationship, but no more. He's, he's decided that, hi, him and WordPress are gonna go in separate directions, but I just wanted to memorialize. That moment and, and offer up my great and sincere thanks to David for all that he's done for the show.
I did it in the podcast episode, but I'm doing it again because I feel overwhelmed. So there you go. Thank. Thank you. David
[00:04:24] Sabrina Zeidan: May speak to David too because I really WP Builds a newsletter Weekly, weekly, podcast and I always was looking forward to listening to you and David, both of you.
[00:04:39] Nathan Wrigley: Yeah, he's, he was a, he still is.
He'll remain a great friend. It turns out, by complete coincidence, after doing many, episodes, he lived, he was born about five miles away from where I was, and he used to get the bus past my house every day when he was a child, and we didn't know. And then one day we just were chatting offline and it was like, where did you grow up?
He was, no way. That's where I grew up. What anyway, we're not getting into that. I dunno why I hijacked the conversation. But first of all, thank you to Steven. Hello. pleasure to have you along. As I said, Steven, if you fancy share in the URL and getting some people in, feel free to do that. That'd be great.
If not, don't worry. Let's get stuck into today's show. What have you got for us, Sabrina? How are you gonna speed things up today?
[00:05:26] Sabrina Zeidan: Oh, so for today we have very interesting case because. our previous episode, wait a second, for everyone who is watching us for the first time, this is all about performance.
We talk about performance. Yes. Here, WordPress performance. And, we ask and invite those who are watching to submit their websites with their performance issues. If you have some, if you think that you have some, or if you don't have some. Submit your website and we'll look at it in the show. And our previous episode as we didn't have a website submitted to us, we were talking about, backend performance, leaks, backend performance, issues, and we were talking how to investigate that.
And after that episode from the previous week, if you're interested to watch it, it's episode number six. We had, someone, it's, I think it's not Stephen, but Stefan, as, Stefan is, from, Austria, sorry if I'm wrong. so I was referring to him as Stefan all the time. He submitted his, he, a website, that, he, built and it's a website for charities that, is absolutely voluntarily, built.
And this website had issues similar to those that we were talking about in the previous episode. So this episode, we'll be looking at the website that, is having. Was having, backend issues and it's kind of part to a practical part to the episode that was last week. So if you join us today for the first time and you would like what you're seeing, make sure to go and check last week's episode because all the theory is there.
And today we'll look at in practice, at the website that is having such issues.
[00:07:31] Nathan Wrigley: Perfect. Nicely summed up. Yes, and we should have said that, shouldn't we? just to Sabrina's point there, if you would to submit your website, go to this url, WP Builds.com/speed. There is a form over there. It'll take you no more than a few minutes.
It gets sent directly to Sabrina so she can then communicate with you. And I believe that she has been chatting with Steven. it is Steven. and Steven is Irish, or at least he's living in Ireland, Gotcha. There we go. yeah, so thank you Steven for that. First of all, thanks for sending in your site and thank you for joining us.
Appreciate it. Mike is joining us and he says, good afternoon. all from a cold, wet, and very windy aisle of man. He's roughly halfway between me. Steven, depending on where Steven is. Yeah, in the middle of the Irish C so thank you for joining us, Mike. Shall we crack on with it? Do you want me to share your screen?
Are you ready for that moment? I.
[00:08:29] Sabrina Zeidan: Sure. just, to give a little bit of, background, we have these emails going during the past week and I cut pieces of those emails and put them in the document to refer to. I will retell the story in our episode and I will show the website, but the main purpose, the, main goal of today episode.
What I want to do, I want just to share the process. How we were approaching the task of investigating what is happening on the website because, it's important to understand when you are investigating issues. It's important to understand where to look, which tools you can use, and, To identify the issue.
I'll show how we did this with this website.
[00:09:21] Nathan Wrigley: Perfect. That's great. So it may, we, the intention of this episode is not to fix everything. It's to demonstrate how you might go about exploring what the problems are and tools to use and all of that kind of stuff. Shall I share your screen? Are you ready or are we gonna go recursive image of death?
no, we're all good. There we go. Perfect. All right. I can see a Google doc where you've probably put the emails between you. yeah. And Steven ideal.
[00:09:48] Sabrina Zeidan: Yeah. and just to go back to what you just said, Nathan, that we are not, going to fix. it's not our purpose to fix everything. we were able to fix this, but what I want to say that in my work in performance optimization work, there are a lot of times when it's not possible to.
Fix the bottleneck in the way I would like it to be fixed. You know what I mean? Uhhuh, many things. many things don't depend on you as a developer and to fix something, you need to, identify what fix. Means to you to make it work and to make it, stable or to fix it. Really, we were touching on these point previous time a little bit.
If I write emails to plug in developers or I let no themes developers, when something is bugging their product, yes I do, but sometimes, often when you find something in the theme or in plugin that is causing issues to you. Your way would be to let them know, but meanwhile, while they are finding for stable solution, you will find a walkaround to make it work and to make it, manageable for you.
So let's see. What was wrong with this website? Oh, lemme see. lemme show you the website first. This is, I'm opening it in private. our issue here, this is a fundraiser, right? And this a soccer field. You can see. square is a WooCommerce product. You can buy a part on this field and join a fundraiser.
What nice idea is that, isn't it?
[00:11:48] Nathan Wrigley: That's very cool. Nice. Yeah,
[00:11:51] Sabrina Zeidan: this is, absolutely cool. So this, this all is done with WooCommerce and, custom post types. And, every, basically every single, square is a product. We are not touching front end performance here. we're not looking at core work vitals here.
The problem that, this is a third party, theme that is responsible for displaying this. So I'm just opening to show how it works while I'm talking. Okay. The problem that, Steven encountered was high CPU usage, on his server and it's not highly attended website. And the problem was that he wasn't able to replicate it and wasn't able to figure out where it was coming from.
That's why he submitted a website to us and I looked at it. So let's start from the very beginning, what we know High CPU usage. And what else I knew in the beginning is what, Steven, sent to me a part of their conversation with hosting support. It's side crowned. And a part of that conversation had an error log.
Let me show you, the error log that give, that gave me some hints. this is the initial email. And the problem was, look at this, I checked in detail and for the last 24 hours, the website, let's go Astro, thermos town.com. This website used that many CPU U seconds. Okay? this you might not tell a lot, to the person.
Far away from CP two seconds, but this is a high number it seems. The server IP and then the server AP made almost 40,000 hits to the website for that timeframe. So the website, what we know from this lines, the website was requesting itself. its all pages, frequently, many times the request.
There were a lot of requests. That consumed a lot of CPU and those requests were coming from this own server. Wow. Okay. This is a hint. It could have been some Or malware, something like that. It could have been that. But also this might be happening when caching is not right. When caching system is trying to build cache, it requests the data from your website and when something goes wrong, it might be requesting it again and again.
And what they were saying in the email, look, there are requests here and, from which IP it was made, the response it got, but use. But look what there is here. That what attracted my attention from the very beginning. It says, miss means that this page wasn't served from cash. And then we see this skip cash set cooking.
I didn't know at the time what does this mean, but I can clearly see that these requests are not cached. And they're not cached because there are headers telling the server, passing cookies, to the server saying that, do not cache this page. That was a hint that something might be wrong with caching system, but it doesn't give us a lot of answers.
And also it's important, to mention that recommendation from, hosting provider from SiteGround was to switch WP P chron to real, chron job, Linux chron job, which is, A good thing to do, but this recommendation, I just want to talk about it separately. It's often recommended by hosting providers switch from w like you come to them and say, and tell, Hey, I'm having a problem, and they're telling, that might be Crohn's switch from, WP Chrome to server.
It's very rarely, it's really rarely that WP. Is the cause of the issue. And when you switch, the issue will be fixed. It's more often the wron just multiply the issue that is the original one. Got it. And when you switch to server chron, you don't fix the initial issue. You just. Get to some same level, but you are not solving the initial issue because it's very rare that it's crone itself causing the issue.
It might be chrome tasks, yes. That are not cleaned properly or they are not ending, one chrome tusks. Starts, and it's not ending and it's time to start the, same task and the server starts the same time again. It's not ending. And it might grow as a snowball, consuming CPU and memory.
and by switching to cro, you might. Cut off one level of the problem.
[00:17:52] Nathan Wrigley: Okay. But not fix it. Not the problem.
[00:17:54] Sabrina Zeidan: Okay. Yeah. Yes. So to everyone who is watching us now, by the way, if you are watching us now, please say hello in the comments to us. We would know who us. So if you're watching us now and you have.
This recommend, just remember, if you have this recommendation switch from Omicron to Scro, in some time, at some time, at some point in future. it's not a bad thing to do, it's a good thing to do, obviously, but just remember that. Most likely your problem is not solved. The problem that was the original problem.
It's not solved. You have to investigate or it'll hit you in the most unexpected time, the time that you don't want to be hit. So these were our, like, initial information. And what, What I, my suggestion, I looked at the web. What I did, let's start with what I did. There is a very cool plugin called Health.
Ah, what, Steven did before he tried turning off, he followed the recommendation that I gave in our previous episode. He turned off. Plugins, and switched back to custom theme to check what was happening and if the issue is gone. So he did this and, the issue was gone. he was. Thinking, he had some hints that it might be either main WP plug or something connected to it that was causing the issue.
He switched it off for a while and then we were waiting if it would be triggered again, but it wasn't The issue went away when all plugins were deactivated, but at that point, Steven wasn't able to figure out which plugin exactly and in what way is causing the issue. I just want to share this, plugin, this really cool tool that I use.
It's called Health Check and Troubleshooting plugin. Oh, I have it installed. Let me show you how it works. it comes from, it's community build. and it's what it lets you do. Plugin, plugin manager, plugin plugins, over here. Let you, turn off plugins and turn them on. Without interfering the experience of other users on the website.
So I can go to the website and using this plug in. Troubleshooting. Troubleshooting. I check in troubleshooting, I can deactivate all plugins and switch back to original theme and then try to activate plugins one by one without, If you go to the same website at the same time, you won't see any difference.
It would be the same website for you. I think this is a cool feature. and now you see all plugins got this, oh yeah. A little
[00:21:23] Nathan Wrigley: troubleshooting icon. Yeah.
[00:21:25] Sabrina Zeidan: Yeah. Health.
Let me show how it works. Troubleshoot.
So I can go by activating this plugin, I'm going to, troubleshooting mode. And for me, for my user, I can see this. So what I did, I'm not going to do all the steps right now. I will tell what I did just to make it quicker. So what I did, I activated query, monitor, plugin. It was the first one. I deactivate everything and then I activated query, monitor plugin.
And then I was using this one, I was activating plugins one by one looking at query monitor data. Okay, let me, do it anyways. It'll be easy if I show, so I activated. It's activated query. Monitor. Should be, yeah. no, actually no. Wait a second. Troubleshooting mode, available plugins. query monitor.
Yeah. Yeah.
[00:22:38] Nathan Wrigley: It's weird, isn't it? I don't see that. Yeah.
[00:22:41] Sabrina Zeidan: No, it's not here. I'm not sure why. Ah, show of 17 remaining. Anyways, I used this plugin troubleshooting and hhealth check to gointo this troubleshooting mode. Then I activated query mo into, I deactivated all others and I started.
activating them back, trying to figure out what's going on. And the initial memory consumption was 40 megabytes, of, memory. when everything was turned on, I started to turn on, with, I activated WooCommerce, and tool set, plugins plugin first, and in immediately memory consumption went to 100 megabytes.
Which was, 90% of that is WooCommerce, of course, but it's normal. It's normal, it does it for everyone. So it wasn't our problem. And I started to activate in all this heavy stuff that we have, pop-ups, side carts, all these features and everything. And it was growing bit, by bit, but not very much, but.
Before. Before that I noticed that there are a lot of plugins that are responsible for speed optimization, and here we have a few plugins that are doing their own caching stuff. So it's side ground, uses their side ground optimizer, plugin that is doing caching for you and it optimizes JavaScript and CSS and so on.
But also the website itself has quite a few. plugins that are responsible that, that are supposed to make your website fast. And this is a good example. I want to point this out, that, using few plugins for the same thing, for the same purpose might be,
[00:24:58] Nathan Wrigley: Overkill is a
[00:24:59] Sabrina Zeidan: word. Overkill. Overkill. It might be, it might make the performance worse than without anything, because especially with caching, when there are a lot of layers of caching, it'll be interfering one with another and.
Each caching system wouldn't know how to update, when to update if one is updated. should we update to how often we should check if that layer is updated, which, which priority we set to cache if this one was updated, should this one be updated? The more layers of caching you add, because for example, DV has its own inline caching and page caching.
side ground has its own. Then this website has cloud fla. then there are some, performance optimization plugins that, that are doing something and it's, Then was playing nicely, one with another. So what I asked, let me tell you how the story was, developing. So what I figured out, I messaged this back to Steven saying that I was, activating plugins one by one, but, and everything seemed fine.
But then I activated speed ground optimizer and it brought the number of database query from three hundreds to 1060 something. Let me show you the nice picture. I made a screenshot. So 1,645 queries.
[00:26:49] Nathan Wrigley: Okay. That's a lot.
[00:26:53] Sabrina Zeidan: That's a lot. And what I also noticed here, you see this, w below all options function.
that were impacted 730 rows. And though it was, it was, performed quickly, 730 rows. I didn't like that. So what I was thinking, what, from what I saw, what I can check here, I can check, autoload options. The, we were talking about this in the previous episode. I was referring everyone to the post on Ssta, how to check the, amount of autoload data.
So I asked, Steven for, access to PHP, my admin and checked. The size of Autoload data, and it turned out that the size of Autoload data wasn't very high. It was 300 kilobytes. Okay, so these questions, we marked it. No, it's not the culprit. I also noticed there we're. Issues with heartbeat. Query monitor.
Again, query monitor. Super cool tool for this, for investigation. I love it. I recommend it always. there were some issues with heartbeat. I didn't know it was connected in some way or no, but definitely like this 106, 1,600 queries were telling us that there is something about Cion system. Triggers in cognitive mode. Ah, and another thing that I noticed, I visited a product page. This is a product page in cognitive mode, and let's see what we'll see now. But when I visited it before, it was a miss. It was served directly from server, while it should have been served from cache. Let's see. Ah, it's my second visit now.
Let's see. It's heat. this is another thing. Okay. How to check. I'll explain, how to chip. If you are seeing a cash version of the page, or it's served directly from ero, what does it mean if served from cash? it doesn't take resources from your server. It doesn't take CPU, it doesn't take gram, it takes, but very, little.
and if it's served directly from your website, it means that all PHP stuff and database queries and everything should have happened to serve you the page. That's why we want, that's why we are doing our caching. That's why we're doing different layers of caching so that we can use. What, reuse data that hasn't changed that, will allow you, will allow us to save resources.
So how to check if it was, saved, if it was served from, cache or from the server. You can do, open developer tools. Chrome Developer Tools, control shift. I. Let me, oh, it's control shift I, o on, PC or right click developer tools. Inspect. And then you can go to second Ah-Huh? So you need to load the page so that you have the log here, and then you would need to go, here are all the resources.
That are loaded by this page, the very first resource here, as it should be, because sometimes, it's not the very first resource. The very first resource is the page itself, the HTML page. So if I click here, I can see headers and in headers. There are different ca headersheaders that are past with page.Check what we have here. Is it, hit? Is it miss? Because right now we can see Xbox Cache is hit, but for me, when I visited, it before The first visit was Miss and I was updating and updating. It always was missed. so it was requested directly from the server that gave me the idea that something is happening.
Something might be happening with the server and let me see, and. I was, that was my plan. I asked Steven for the access to PHP, my admin to checked up with the options. And also, that was my, guess from the very beginning that multiplication layers are not in sync with each other together they add to the compound effect of higher ram consumption.
So I asked him for access. To HP my admin, and also asked him to add these lines to debunk, in, WP WP Debunk. True. WP Debug, lock True so that all issues will be locked in the file. And WP Debug display falls so that it's not displayed to the, site visitors. That was, a part. We could have had that information that said ground support sent to us before, if we had that on before.
And just to make it clear, if you turned on the bug debug, log logging, to investigate something, do not forget to turn it off. Because debugging itself, especially on the websites, that are highly visited and where all things are happening, debugging can be a, huge CPU u consumption, consumption source of CPU consumption as well.
Especially if you have, this is debug log, right? But some servers, they have access log, also, and they, some of them they have very deep. Access logging. So if you have a lot of things happening on your website, it might consume a lot of resources to write down what is happening there. Just saying it's
[00:33:39] Nathan Wrigley: not.
yeah. Yeah. Very good advice. Yeah. Do not leave the debugging on. Do not.
[00:33:46] Sabrina Zeidan: Yeah. Let me just, ah, and I asked Steven to, enable New Relic because, okay. From this point, we know that after we turn on speed guard or speed ground, optimizer. there is a huge jump in database queries, but we don't know what's happening.
Exactly. And I asked Steven to, activate to set up New Relic on his website. I mentioned that in previous episode. You did? Yeah. Yeah. New Relic is a cool, tool to debug such issues. But the problem is it's not very easy to set up some hosting providers. like WP Engine, they have, just toggle, like enable.
In New Relic for this website, you just toggle it and it automatically enables it for you. SiteGround doesn't have it and to set up New Relic on site ground as, on many others. This is honestly, it's not the side ground is, very bad. No, a lot of costing providers don't provide it out of box. So on many hosting providers, just like in this case, to set up New Relic for your website, you would need to do curl.
Comment on your server. You would need to walk into a survey in, SSH mode and, do a comment to let New Relic access the data on your website. But if you have server access, it won't have, it won't be an issue for you. So this is what, I asked for. And while I was writing these emails, Steven sent me an email saying I've just seen, huge spike, in CPU consumption just now.
while I was writing that and that confirmed that indeed it was related to the caching because I just. Purged the cache. Ah, okay. Yeah, I just did it. And we saw the spike and there was no spike during the previous four days before that. So purging the cache that was built by speed guard. and because is my plug, side ground optimizer, created the issue, the plugin.
From side ground that is supposed to improve performance was the troublemaker in this case? Just, in defense of this plugin and side, ground. Ground, I want to come back to, with what we started, there are multiple LA layers of cash on this website and. How we resolved this issue. The last email that Steven sent to me was that, I looked through your email early emails highlighted c and also there's, speed, side ground optimizer plugin.
Once I turned this off, I-C-C-P-U seconds use drop straight away. I think it has been the so in this case. side ground, optimizer plugin would be turned off and this would resolve the issue. But just to understand what is happening here, it's not that the plugin that side ground build is bad and is bad for everyone and you should, it's not what I'm saying and it's not what's happening here.
it's not the conclusion that we should make from it. The conclusion it could have happened to any other caching system. The conclusion that we should make from this situation is that. It is possible when you have multiple layers of caching. And most of the websites, they have multiple layers of caching because their hosting provider caches, do some caching on their side.
Then they might have, caching plugin, then they might have, CloudFlare, and it's without installing additional plugins. It's just like basic. they might be not, playing well with each other, and when they are trying to sync with each other, this is a load on the server and to investigate issues like this.
What you can do is what we did firstly, you can use that plugin to, go into troubleshooting mode. You can captivate everything and ah, and important thing that troubleshooting and health plugin it. Tries to deactivate caching that what they're saying in their description, we will attempt to deactivate caching on the server.
So it might not always work, but that Trying to help you to investigate this. So what you can do, you can switch back to the default theme, turn off all plugins, start reactivating plugins, starting with, heavy things that, the things that are forming, shaping your website. If it's WooCommerce store, it makes sense to activate WooCommerce from the very beginning.
If you have advanced custom fields in activated early, tool set, anything that. Shapes and then you go from big things to smaller things, but leave all performance optimization plugins. to the end, do this while having query monitor on, and you will see how the consumption of memory and the number of queries are changing.
It'll give you a hint.
[00:39:49] Nathan Wrigley: I'll just, just pause you there because Steven has come back with a. A variety of comments, so I'll just raise those so that you can see them. The first one is, he said he's gonna check, I'll just read it verbatim. He said, I'll check what caching is set up.
There is what site ground plugin is doing. There is caching on CloudFlare as well, so that's another piece of the jigsaw puzzle. He also says there are some things related to CSS and JavaScript in divvy settings as well. Yes. So that is not set up in the site Ground plugin. Yes. other plugins installed like asset cleanup.
there yes. Turn off things like recapture on pages where it's not needed. So that's the end of Stephen's commentary. And then Mike just said, yeah, it's interesting that in this case, the plugin that is actually supposed to speed things up is making things worse. But again, our stress, what Sabrina says, it's a, confection of things happening.
It's not that the SiteGround plugin is bad, it's just in this scenario it's conflicting with other. Things going on at the same time? Yeah. what I
[00:40:49] Sabrina Zeidan: can think of, for example, there is a theme CSS optimizer say something that optimizes CSS coming from the CMD with optimizer that optimizes CSS and it saves its it, in line and, as a separate file and.
For some reason it decides that it needs to be updated. It's updated, and then you have another plugin that is clean assets or something that is doing something, knowing that something has updated. And then you have this, SiteGround, plugin that is trying to understand when they need to update all.
Page, all pages cache. Yeah. Is it important to update it right now? Is it does do these changes trigger to update all pages cache on all side and if it's, so it's a lot of load and CPU. That, what can be happening and to investigate. We didn't get to New Relic yet, to, so to investigate situation like this further, what we can do, we can just try to figure out it's.
I don't know to be true the programmatic ways or template or like instructions, how to find out the exact setting that would solve the problem. I would probably go to side ground. Plugin, we identified that it's tree, it triggers whole cache update, right? And this causes the CPU usage. So I would probably go to side ground plugin and try to find, they have some settings controlling when it should be updating and.
Seeing other settings in the theme in my optimization plugins, I will try to bundle that together. Together what triggers what, and maybe, I will be able to find the setup where one doesn't interfere. Another, maybe I would try to turn off. All optimizations turn off all optimization plugins and turn off all optimization in inside the theme and leave side ground activated only.
Okay. And see from that impact, yeah. If the cache rebuild happens, but it doesn't consume as much CPU as it used to, maybe I will try them to activate something. And rebuild cash again and see how that impacts. It's, there is no straightforward answer
[00:43:52] Nathan Wrigley: to this. No. Steven's added some more commentary though, just For, reference, he said, normally he's got the same setup on other sites, which don't seem to experience the same problems. So one thing that he's tried is he said he re, he deleted and reinstalled the site wall. Of the site ground plugin, just in case that it some in some way got corrupted. I'm guessing that maybe didn't fix it.
But, then there is also something called file-based caching, which is turned on inside the site ground plugin. And that speaks to what, Sabrina was just saying. It sounds like that may be a problem. good point. And then he says, yeah, good point. Oh, I can't make that, Chat, go up. Hold on. There we go.
Where's it gone? There we go. good points. Site ground only. It's a minefield. Yeah. Go back to site ground and try that. Just isolate that all by itself and see if that's fixed it. So that's the end of the commentary that we've got so far.
[00:44:52] Sabrina Zeidan: I'm just, just looking now at the squares that we have, and I'm thinking it might also be a thing that one cache layer thinks that this should be cached, and now that cache layer thinks that it shouldn't be cached.
the variable products, the, query, query arguments that are added. To the main, URL, to the product. So this might be also another thing. There is no way other than to try things out. And again, I want to get back to the point that hosting provider, made like switch to, server chron in this case.
Again, it's not a bad thing to switch to server chron top instead of wron, but in this case, it wouldn't solve the issue. It would just, mitigate the, our original issue. So maybe the c few seconds wouldn't go that far up, but it's, if you have to switch to s. from WP Chron, not because you want just to do things in more performant way in general, but because you are already having issues, just investigate the issue too.
Don't stop on switching to Chron's job only. This is my point. And another one.
[00:46:25] Nathan Wrigley: Okay. Steven, I guess that's what Sabrina's got. hopefully there's some tips and tricks in there that you can use. Sabrina, have I jumped the gun there? Did you have more that you wanted to say or was
[00:46:37] Sabrina Zeidan: that No, I think this is it.
I hope that this. Case would help someone else maybe not to resolve. There are no two same cases. This is for sure in performance. There are no two same cases, but I hope that this episode would someone, would help someone who is having issues to investigate to, to understand the logic. behind investigating to understand where, to look and what they can
[00:47:14] Nathan Wrigley: use.
I think so I think that was really useful. And obviously if you view these episodes, you view the f the previous six and you view the remaining ones that we haven't made yet as a whole. They will give you lots and lots of interesting and new ideas. So first of all, thank you to Steven. For submitting a site, obviously, Sabrina, for having a look at it.
Just so that if you want to submit your own site, you can do that. if you would like to do that, we've obviously got another show next week, and Sabrina, I think would like another site to have a look at. WP Builds.com/speed. One more time. WP Builds.com/speed. if you know of anybody like, colleagues or whatever, if you wanna point them in the direction of that, could be really useful.
we don't have to, do it next week, but that would be. Great. The other thing to mention, of course, is that Sabrina, she does this for a living. That's what she does, and you can find out more about Sabrina at her own website, which is sabrina zan.com. S-A-B-R-I-N-A-S-Z, sorry, E-I-D-A-N, Sabrina Zan dot.
Com. And, just to round it out, there's a few little comments that have just arrived. Let's quickly put those on the screen if we can. let me just have a look. Okay. So there's a question now, which is coming in from Steven and he's saying, if I'm using Psych Brown Cing clashing, should I disable any CloudFlare caching?
Yeah,
[00:48:43] Sabrina Zeidan: I would do, disable CloudFlare caching disable. All cachings inside the theme, performance optimization, everything leaves side ground only. And then try to turn on those, perform performance optimizations in theme and maybe you'll see what triggers. And it doesn't mean that when you see the, Pair that is triggered. Okay, I, enable this. And it triggered speed, ground, optimizer to consume a lot of CPU. Again, it doesn't mean that you need to disa just disable, that, theme in the theme or in that optimizer, try to look at side ground, optimizer and figure out which, feature which setting inside ground.
Can be turned off or adjusted to play nicely with that feature from that another plugin. And after everything is done and you figured it out, CloudFlare will be the next layer of caching. So after everything is figured out, it would be nice to bring CloudFlare back at that point. Not clear
[00:49:55] Nathan Wrigley: yet. Okay.
Thank you. That's great. Helpful. Hopefully to Steven. He, he says thanks very much for having a look. He'll continue his troubleshooting journey, but also, Henrie Stewart. Hi there, Henrie. she says she's still catching up with the previous episodes and very happy to hear. I'll be more Henrie if you want to, you know what to don't you?
If you want there to be something of yours on there, I'm gonna show it again. submit your site, WP Builds.com. Forward slash speed and that's the way to get that done. okay. So I guess that's it for today's show. Sabrina will be back next week. We don't know what it'll be about exactly, because, maybe somebody will submit something, maybe they won't, in which case it'll be, the ball will be in Sabrina's court to, and what was something.
But, you're gonna be, you're gonna be where you are. Staying put for a few weeks? Are you staying exactly where you are? Okay, so staying Sean, we'll be in a familiar scenario. Familiar surroundings next week, Sabrina, as always. Thank you so much. Thank you so
[00:50:55] Sabrina Zeidan: much. Thank you. Everyone who watched us join us next week.
It's lovely to have conversation like today's that we can actually speak, not talk not only to each other. Sorry, Nathan. It doesn't mean the term board from you. I just want other people to participate.
[00:51:10] Nathan Wrigley: No, that's of course. I understand. Yeah, there's a couple more. Just come in. Camie. Hi Camie.
she says bye. Happy. There are many more to come and final. Cheers from Steven. Okay, on that bombshell, we will knock it on the head and we'll see you next week. Take it easy from the Speed show. See ya. Bye bye.
If you’re here looking for the live show, and the time is right…
JOIN US LIVEIf you’d like your website examined by Sabrina, you can submit it…
Submit your siteSupported by:

and by:

Discover more from WP Builds
Subscribe to get the latest posts sent to your email.
