From Hosting to Core Web Vitals for Building Fast WooCommerce Sites

Mike:
Yeah, I think having adequate resources for the site is super important. So there’s enough CPU and RAM, using fast SSD drives. There’s room for growth. A lot of the time I see not enough resources being allocated for the database, for example. It’s like having a big enough engine to power that database. Having access for developers like SSH analytics tools, being able to access the logs and scrape those properly for little nuggets of information. Having some sort of application performance monitor (APM) like New Relic is the one that I use the most. It’s pretty popular because you want to be ideally alerted and proactive about performance issues rather than reactive. You don’t want to find out customers are emailing you or blasting you on social media that, oh, you’re trying to check out on this thing again and it’s crashing or slow or whatever. It’s better if you get an alert from your own systems that you have set up for monitoring, etc., to go out and put that fire out and be able to pinpoint the issue very, very quickly instead of trying to play detective with discovering all the clues instead of having the clues handed to you.

Having some sort of CDN integration I think is quite important as well. There are a lot of Cloudflare enterprise partners now with hosting companies, which I think is, if you wanted to build your own Cloudflare network, good luck. That’s a lot of resources, a lot of money. So I think it’s easier to just get a host that already leverages their network for the DDoS protection and the security because sometimes the performance issues I see on WooCommerce sites are actually security related. The site is constantly getting attacked on the login page or good old XML-RPC, which has been around since the dawn of computing and is used but can still be a very common attack vector. And fraudulent orders was one that I saw come up recently. This client had a bot network that was attacking them, making a bunch of fraudulent orders, just taking up resources from real people who are actually buying stuff. So yeah, those are the things I think off the top of my head.

Marcel:
And I obviously think that the very basic part of it, of the hosting, is if you have an audience or a market that is more US-based or European-based or whatever region you’re selling to or providing your services to, that also plays a very important role in deciding which area of the world you’re selling to and then choosing a hosting company that has good data centers or good resources in that specific area. The region of the world is, I guess, the number one thing we should look for when we’re going to choose a hosting company because they all say they are very fast everywhere, but if you dig a little deeper, you will see that they are probably more US-based. So whenever you go to a hosting company and you search for their data centers and where they’re located, some of them, even when you spin up a hosting service, they will ask which area do you want to cover.

I think some of them are more US-based, some of them are more European-based, and we have Asian ones. For example, if you want to go to the Asian market and sell in China, Japan, and other countries, it’s far more challenging to choose the right hosting company than it would be to sell in Europe or in the US. So that would be probably my advice: choose a hosting company that has all the services you talked about and all the little details that they care about, specific for WooCommerce, but also where they are really strong when it comes to providing the fastest services in the region of the world you want to sell. Number two, I would say, is the theme. When we talk about the theme, do your clients go more with existing themes and then change that, or do they have custom themes?

Mike:
It depends on the size of the client. I work with a range of small businesses to enterprise clients. One of the Shark Tank clients I’m working with, they were using a very popular commercial theme that had a lot of extra bloat and unnecessary stuff they didn’t need. I told them, you have the budget and the resources, go custom. It’s hard to compete with the performance of a custom-built theme, and if you have resources available to maintain it going forward, absolutely it’s the way to go. I generally find that smaller businesses, when they’re just starting out, they don’t know if what they’re going to build and try is going to have legs, is it going to work, is it going to make money?

So they will tend to pick a theme that is pretty, has predefined templates that will work with WooCommerce, and has a bunch of features. As time goes on, they probably also use a page builder or two or three I’m sure we’ve all seen, and other components. That will tend to, of course, slow things down. I tell them during consultations that if you’re using a certain combination of theme and a page builder, I would start with removing that and then if you’re still not happy, we can look further at what’s slowing things down. So I’d say it’s a mixture. Whenever I see a custom-built theme with a cart, I’m like, oh good. This means that I don’t have to have that difficult conversation of if they’re really in love with their theme or the design that the theme provides, and you tell them, hey, you have to get rid of this. It’s like taking a toy away from a child that they’re very, very happy with. Then I tell them, no, no, no, you can have the same design and features, just rebuild it with lighter components.

Marcel:
And usually as a developer, when you have a client that is using an existing theme and they start having these ideas about, oh, what if we could change this page and make the image appear on the right side instead of the left side, or we need the description to have a bigger place now let’s move it down, or now we need an extra tab for this or for that. And then you suddenly end up having so much customization on top of an existing theme that you start asking yourself or challenging the client, this is becoming so cumbersome to maintain all of these changes. It would make more sense to build a custom theme. I would say if you have the resources and if your client has the resources, a custom theme may seem like very hard work at the beginning because you have to do all of those standard pages, the 404s, the search page and all of that, but it will compensate in the end because if you have full control of everything that is being loaded on a theme and usually when you go with an existing theme, you don’t need all of the features that they offer, you have a lot more control over performance.

So if you’re starting out, fine, but if you want to invest in something that is very important to the performance, I would say the theme is the number one category where you should put some resources because we’re talking about web performance and we’re talking about key metrics that we can measure. The theme part is one of the most important components because it is responsible for the front-end part. When we talk about key metrics, we talk about LCP (Largest Contentful Paint), we talk about the First Input Delay (FID), we talk about Cumulative Layout Shift (CLS), which is when the page loads and things start moving up and down because the images are loading or different parts of the page are loading and they’re shifting up and down, which makes it very confusing for a user to follow. That is all the theme, or mostly the theme’s responsibility. From the key metrics, what is the most important one in your view?

Mike:
I think Largest Contentful Paint (LCP) is a big one. So related to conversion rates, time to first byte as well. I know it’s not a core web vital, but…

Marcel:
I forgot to mention that. It’s an important key metric as well.

Mike:
Everything else, the Largest Contentful Paint can only be as fast as the time to first byte. And there’s also Interaction to Next Paint (INP), which you mentioned in the introduction, right? That I think replaced FID, the transition because when you click the button or whatever and you don’t see something happening within a few milliseconds, we get confused or frustrated and keep clicking the button faster. That’s a common human thing where we think clicking the button harder and more intensely will make it work. Maybe you press your mouse button extra hard or…

Marcel:
Multiple times.

Mike:
Yeah, like clicking the elevator button faster and faster…

Marcel:
It’s not coming. Let’s press again.

Mike:
I think that one is really important for stores because of the add-to-cart checkout flow. It’s important to signal to the user that they’re making progress towards their end goal and with their journey of trying to get this product or service that you’re selling. That one is more difficult to measure in, not in the wild, but to pinpoint where the INP issue is coming from is not as difficult as Largest Contentful Paint, for example, which is well established for being very related to the revenue conversion rates. There’s a cool calculator that Google put out a long time ago that they deprecated for some reason. I don’t know why, but we took the code and put it on my website. I think I’ve sent you the link before too with this LCP Premier calculator.

Marcel:
And I would recommend everybody to take a look at that because it’s very interesting how much you can estimate the increase in terms of conversions just by tweaking some of these key metrics in more performance.

Mike:
It can help a lot to put things into perspective for the clients. It’s not based on a specific niche. It’s aggregated data that people and Google Analytics opted in to allow Google to track. So it’s from all niches across all different industries, and it gives us the best idea of if we can improve the LCP from X to Y, and if you know your average order value, the amount of customers that come

per month, and one other piece I can’t remember, you can see how much more revenue you will get if you make that improvement in the LCP. It can help shortcut some of the conversations about price. If you’re saying, oh, it’s going to cost $10,000 or $20,000 to do this reworking of the site or whatever, and they can see, oh, that sounds expensive, but if you use the calculator they can see, oh, that’s going to mean half a million extra in potential profit from a business perspective, it becomes a much easier decision.

Marcel:
And clients do have sort of the first impression that they get when we present them these numbers and we talk about this specific calculator you’re talking about and they go, oh, that sounds too much or that sounds too good to be true and all of that. But you’ve done that. You actually have some cases on a website where you improve some clients’ websites and it really turned into more profit. So that’s something that clients will notice after you do performance tweaks and it’s something that is absolutely incredible how they suddenly start believing in you and suddenly start seeing how important performance is to their funnel and to the sales and conversions and all of that. It sort of makes you feel a little bit like a magician or a special god of some sorts when you get to that point and then that client is hooked to you forever, I would say.

Mike:
Yeah, it’s a very effective way to establish trust for the long-term because a lot of this stuff when it comes to performance is unknown for a client. We all know technology is unreliable, unpredictable, we can have the best intentions, we can make all these plans and then something that we didn’t anticipate can mess things up. And so I think even if you have these case studies and you have lots of proof and stories, clients are still a little bit like, ah, but maybe that won’t work for us. So when it does, I can see the struggle in their faces and that hesitation like, ah, they’re taking that leap, jumping off the cliff and spending the money where things could not get any better. That’s one of their main concerns, that it’s not going to provide the return on investment. Fortunately, when you follow a specific methodology, and I’m sure this is true for anyone who’s worked with performance, if the client is getting enough traffic, if the user experience of the site is otherwise good, their business model is sound. When you’re improving the performance, it always makes sense within reason. Of course, once you get to a certain point, unless you’re Amazon or Walmart or a very large client, spending an extra $500,000 to improve performance is not necessarily going to make sense. But for smaller clients, the initial performance tuning is pretty much always worth it.

Marcel:
I guess being aware that it is an important factor when you go online and do sell products is step one to admit regardless of your size. And I’ve seen other big brands in Portugal and the companies who were selling online who initially didn’t give that much of a thought about performance and their websites were being slow and inconsistent and they were difficult to navigate. And since some time back, a couple of them have been actually working on their performance side and worrying about all these different key metrics we just talked about. And guess what? They’re selling better. And you usually think big companies and big brands, oh, they must for sure know about this. And you probably also think, oh, my client has been online selling this product for more than 10 years now. He heard about performance, he’s done everything that he can. Surprisingly, many people do not know about it in a way that affects immediately their conversion rate.

I wanted to talk also about plugins and the importance of plugins and especially the number of plugins that people install. They think they’re essential and they’re not. So my experience is more in terms of whenever I get hands on a website, it is performing very slowly. 30, 40 plus plugins are installed. Oh, when we start doing the audit and ask, do you need this plugin? What is this for? We certainly get rid of 10 immediately just by talking two minutes into the list of the plugins. And just that alone already cuts down the time considerably. And all the other plugins that are installed there are usually because there’s something missing on the e-commerce out-of-the-box features that people don’t have. And we’ve also seen WooCommerce iterating and adding some of those missing features into the core installation. But the number of plugins is also another thing that is very important to talk about, and that means also you need to update them and the more you have, the more security issues you have. You certainly also have multiple plugins that do the same function, or at least in their feature list they offer the same things and you just add things to the website that are absolutely not necessary.

So when it comes to choosing a plugin, it’s also important to know about their performance and how they affect performance and if they are built in a way that shows the concern of the author of the plugin was performance or not. We usually use plugins to do image optimizations, maybe to do caching as well. We’re going to talk about caching next. We use plugins basically to change features and to add features to WooCommerce. So plugins are very important. What is your experience with plugins? And you mentioned page builders. Page builders are plugins, but there are other nightmares that we can talk about when it comes to plugins and performance, right?

Mike:
Yeah, I mean my approach is similar to yours. It’s remarkable how frequently you ask just simple questions, why do you have three forms plugins or what is this for? And they say, oh, well we haven’t used that in six months or a year, or we don’t use that plugin or feature anymore. And I tell them what you said, every plugin is a security liability and a performance liability. So as soon as you don’t need it, treat your website like an F1 car. There’s nothing on an F1 car that doesn’t need to be there. If it has a specific purpose and provides some value in some way, it should be there, otherwise, there’s no reason to have it. But otherwise, I would say the plugin quality is much more important than the plugin quantity. So I have seen websites that have 90 plugins and perform very, very well.

It’s absolutely possible, but it’s usually these heavier plugins that have lots of bundled features, 80% of which you don’t use, and then you do that 10 times and you can see them in the profiling, code profiling, tools, plugins that are just finding out, do I need to run or running unnecessarily on pages. For example, a client I mentioned earlier, Bingbot. Bingbot was crawling a product archive page and it was triggering the membership plugin to see if the Bingbot had access to the particular pages of products on that product category page because the way the plugin was configured was to grant access based on categories and I was like, it’s ridiculous. First of all, a bot isn’t going to log in and take any courses or download any products, but there was literally no reason for the membership plugin to execute. So that was down to code quality in my experience and making sure that plugins, pretty much most plugins I see, do not have the logic to find out, do I need to execute here? Do I need to do anything here before it starts to process its own code? And I think that’s why when people complain about WooCommerce being slow or WordPress being slow, it’s not the core of WordPress being slow, it’s all the other extra stuff that you added usually that is causing those kinds of experiences.

Marcel:
And when it comes to choosing a particular plugin that has a particular feature, you obviously have a bunch of different plugins out there, and usually what I tell people is, well, you could hire a developer to make a more informed decision about how the code quality is and how the plugin works and how it performs, but if you don’t have the resources to hire an expert when you buy these plugins, basically, I guess looking at the plugin’s reviews and seeing what other people are saying or maybe just trying to get a feel of if you see a plugin that is promoting bundled features that are 30, 40, 50 and they are expanding way beyond whatever the core function of the plugin is, it usually means that they are bloated and they’re not very specifically oriented to the feature that they were talking about. When we did plugins for other companies here at our agency, some of them wanted to expand to other areas that were not the core focus of their plugin initially.

So for a developer, it’s very hard to keep consistency and keep the code in a shape that is solely focused on the core feature it was intended to be in the first place. So if you start doing other features and start adding other elements to the plugin, for the developer or developer team who is responsible for making it perform well, it’s going to be very hard for them to just focus on that particular feature, so that is very important. Next on the list is caching. We talked about caching. There are three main techniques of caching I think we can say. There is page caching, which are static versions of pages that are stored usually on the hosting side. We have object caching, which caches database queries so that they do not need to be executed every time somebody gets into a page. And we also have browser caching, which is telling the browser to store certain resources locally and not have them transmitted all over again. Caching is probably one of the hardest things to manage and to talk about because most of the hosting companies already say, we have the best caching solution and technique, just come with your website and host with us, and you’re going to have the latest caching technology. Then when you dive in and want to control some aspect of the caching, you usually have no idea what they’re doing behind the scenes and they don’t tell you what resources and what techniques they’re using behind the

scenes. So this is a very important topic. It’s a very difficult topic as well from a developer’s perspective because usually people think, oh, we just throw in a bunch of plugins like WPRocket or WP Total Cache or whatever other plugins there are, and the site will be faster, and then you hire a developer and the developer goes in and starts thinking about what is going on. We have all this caching going on, and what do you think about caching? Is it up in earliest as an important part? And also it’s important to talk about the different pages that we have within WooCommerce. We have the checkout, the cart, we have a catalog, we have the first page, so not all of these pages are treated equally when it comes to caching. Right?

Mike:
There’s also two other little pieces of caching too. There’s fragment caching, which is rarely used but handy to cache partial pieces of the page and CDN caching, edge caching, I would argue. Yeah, but I know that those are typically not considered under the umbrella in the same way. It’s not the ones that pop up first in mind, and I think with object caching too, you can also cache the results of API calls. I think we’ve done that before for clients with really slow calls that need to fetch something from some API that takes a couple of minutes, and instead of doing that every page load, we store it in a transient. But yes, caching is very, very important. I think in terms of the order that we discuss things, the hosting, the theme, plugins, caching, they’re all really, really the first points of call when it comes to doing audits and making sure things are running well. I think page caching is probably the most important one to get right because everything else will, like you said, the LCP will depend on your time to first byte, which is tremendously improved once you get page caching working, and if you again can leverage edge caching on top of that, you can save usually another 100, 200, 300 milliseconds, which can speed up the other components.

Marcel:
Especially the initial page. The homepage is probably one of the easiest pages to cache, and because it is the point of entry to the website, it just gives you the first impression that we’re looking for it to be fast and clicky and all of the links that go from the first page to specific products and maybe category pages and all of that, those are very easily cacheable pages, right?

Mike:
Yeah, yeah, exactly. Like the pieces where there aren’t dynamic components that need to do post requests or fetch something from the database particular to that visitor, that kind of stuff. I certainly encourage people to build their homepages like that so that they’re very cache-friendly and we don’t have to worry about users seeing something they’re not supposed to or those kinds of things compared to if you have product category pages where you have something with facets where you can filter and drill down, you’re fetching a lot of information straight from the database, which I noticed…

Marcel:
Even with those pages, you can still cache them. Usually filtering options that you have on the website, in the cases where the number of combinations are not in the millions, if they’re in the hundreds, it’s not difficult to cache all the different variations when it comes to filtering and having fast filtering is one of the biggest challenges in a WooCommerce store. But if you’re small and if you have the knowledge and if you can hire a developer to do that, we developers have the resources to cache those filtered pages as well, right?

Mike:
Yeah, absolutely. Yeah. I think you even built something for, I forgot the name of it, but you built a filter plugin for a client that is actually selling it.

Marcel:
Well, in that particular version we did a little, the client had this awesome idea to just provide the browser with the initial results of the filtered products, but it wasn’t directly related to the caching part, but here’s the deal, it benefits greatly from page caching because the information that comes with the page source is already enough for people to feel the filtering to be very fast. It’s the perceived part that we talked about at the beginning, but it’s not caching everything, but it’s caching just enough for people to think this is super fast. And yes, that was one of the techniques that they used, but even if you don’t have that, even if you have a page caching system where the first customer goes in is the one who generates the HTML for that particular cache, and then the second one that does the same, the same filtering options will be served the cached version of it, and that’s…

Mike:
Possible, and I think with filtering too, you get, so you can do both page caching and basically object caching is what I would call it when you are storing them in the database or if you can cache the query string, get parameters from, if that’s how the facet plugin is working, then you get to leverage Varnish or Nginx or whatever other caching plugin you might be using, and that’s one cool way to do it. But then if that isn’t cached, it fetches it straight from a transient inside the database is the next best thing. So I know some people don’t like having layers of cache because you can have stale cache and you don’t want the user to be delivered expired data, but I think if you get things configured correctly, everything helps boost one another. It’s the same thing with page caching locally on the host and page cache on the edge with Cloudflare or a similar solution.

It’s always better if Cloudflare wants to cache your homepage that when you deliver the page to Cloudflare, if you can give a cached version that’s way faster than taking two to three seconds for time to first byte to then deliver it to Cloudflare. So I think it’s important to consider these aspects in the performance strategy and get things, there might be some little fine-tuning or issues to iron out as you’re rolling out caching, and a lot of planning is usually a good idea with clients asking them what’s the typical user journey? What different types of users and avatars do we have on the site? How do they navigate through the site so that we can make sure we’re considering all types of users? Also for employees, the customers are the ones giving money to the WooCommerce store, but the people who need to work on the backend processing orders, support tickets, that kind of stuff, I think it’s important they have a good experience as well, and you won’t be able to use page caching as much for them, but there’s certain object caching and similar techniques you can use for their tasks daily that can make it a better experience.

They get more productive, store owners are happier and all of that stuff.

Marcel:
And then you have the cart pages and the checkout pages, which obviously cannot be page cached. Maybe parts of it can be object cached because there are elements in there that are repetitive for all customers, but then it goes back to what we were saying before about hosting, right? For those pages, you need to rely on the quality of the CPU, memory, SSD and all of that to render those pages fast enough because it’s not just enough to do a fast homepage and category pages and product pages. If people get to the cart and then to the checkout and the page takes 10 seconds to load, you just basically lost the client right there.

Mike:
Yeah, yeah, exactly. And it’s something to really get nailed down. I think it’s okay for the final checkout when people press after they’ve added their billing details, credit card number, all of that, pressing that final button, it needs to communicate with the payment gateway or API calls back and forth. I think people accept and understand that that could take a bit of time…

Marcel:
Like that everywhere in every single site,

Mike:
But getting to that stage shouldn’t take long. I think especially with mobile browsers nowadays, you can autofill pretty much all of the fields and WooCommerce is so popular and widespread that unless you’ve done a lot of customization to the fields or whatever like the Google Chrome Safari or whatever, I think we’ll be able to figure it out. We can’t cache those pages, but it’s still, so maybe you might be able to do some fragment caching if you still have the menu in there and it’s a mega menu, super complicated. We could cache that, so that’s not taking up unnecessary time. I don’t think that many users are going into the menu at…

Marcel:
That point. Yeah,

Mike:
Or you might have a footer, I’ve seen this before. We have a footer widget or some piece that is contacting Instagram or doing something else blocking the right page and the user isn’t even going to see it, but it still is preventing the checkout flow from progressing…

Marcel:
Quickly. Yeah, I was going to take the last minutes that we have for this episode. Just to sum quickly, so we have chosen our hosting company, we have chosen our theme and we have a set of plugins that we chose. We learned about caching and what the different caching versions are, and now we’ve installed everything and we run the website and it’s slow. The website is not moving at all. Then we need to talk about, and we’ve already talked about core web vitals, so we have different diagnosing tools that we can use to understand why the site is slow, because if we followed all of the advice that we’re given, we’ve chosen the right hosting, the theme is not big, the number of plugins is reduced, and we only have the ones that we really need. We’ve tweaked, we spent hours tweaking the caching and the site is still taking two seconds to load the homepage. For example, core web vitals are the first thing to go to and to measure. How do you do that? How do you measure core web vitals?

Mike:
Yeah, there’s definitely using a front-end tool like Google PageSpeed Insights, GTmetrix, WebPageTest. We’ve seen those at the perf now

conference…

Marcel:
PerfNow Conference. Yes,

Mike:
They all run some piece of Lighthouse nowadays. You used to have to use Google PageSpeed Insights, it’s called I think something else now. Anyway, web.dev/measure. So they all just have different ways of running Lighthouse and then presenting the data to you differently. So I like WebPageTest the most. It’s the geekiest, so it could be quite overwhelming for people. I think GTmetrix does a really good job of presenting the data in a more digestible way that isn’t overwhelming and it gives you a good amount of insights and Google PageSpeed. I think because it’s the official Google tool, people like to use that and it feels like it’s more credible, trustworthy…

Marcel:
And it will tell you also about SEO because you want to appear on Google results and at the top eventually, and that particular tool will give you more information about that specific part of the performance.

Mike:
It tells you if you’re failing the core web vitals for that particular page or for your entire website, depending on how much traffic you’re getting. I believe WebPageTest does that as well. It has the crux Google Chrome user experience metrics, but that’s only Chrome data, which is important to remember. It’s the same thing on PageSpeed Insights that it’s not collecting that information from other non-Google Chrome browsers. But yeah, those tools, I mean we can do a whole workshop on those. There’s a bunch of courses on them, so advanced and rich in what they can do. But yeah, that’s why a lot of people, they come to me and they say, Hey, I ran this and it’s slow. I don’t understand this report. Sometimes those reports are oversimplified where there’s a lot of pieces that they miss or that they say, oh, the LCP element is this, and it’s like, well, why is it taking eight seconds? Usually it’s JavaScript related or something else, but it could also be the time the first byte was six seconds, so that takes someone who has experience and to decrypt, I think, or understand things more.

Marcel:
Do you have a favorite tool?

Mike:
Well, no, it’s basically just the ones that you talked about, but what I think is the most important one, I don’t want to say there’s a most important one, but I do feel like the Google’s tool is a good starting point for people to understand a little bit what’s going on because they also give, I don’t want to say simple instructions on how to fix those because they’re not, probably not simple when they say to reduce image sizes or when they say to lazy load some scripts and all of that stuff. Usually as a store owner, you don’t really know what to do, and even as a developer, you suddenly think, oh, so if I just lazy load all this stuff and I just delay all the loading of the JavaScript, that will fix it. But then I start thinking, oh, how do I determine which ones are not necessary and how do I determine which ones the clients need if they change something on a homepage? Suddenly it’s the script that does this funny animation or has this slider going on. So it’s very hard for people to understand, and I think Google’s tool is the one that gives you a starting point to start figuring out what’s going on. They do this coloring with red, yellow, and I think that’s all the colors, the important colors they use to pinpoint all the most important parts of it, and if you manage to figure out some of those points, you’re already in a good starting point and then you can use all the other tools you mentioned to just fine tune specific parts of it. But once you have the results and once you have some indications on the website specifically what’s going on, being it a section of the website, an image problem, JavaScript problem, whatever it is, then it basically comes back to the theme setup and how to properly set up the theme.

Usually if you go with an existing theme, there are options that you can turn on and off and by those on and off, you will then obviously maybe not load some of the scripts if the theme is done properly, if they have taken care of just not loading scripts they don’t need for that particular page. This is where page builders come in very handy, and that’s why I’m a huge, huge fan of Gutenberg and all the Gutenberg experience because it’s very performance-focused. But then again, you will optimize the heavy scripts, the styles, you will disable some theme features. As we talked about, mobile performance is also something that you will fine tune and then you suddenly… Let’s move on to the story and end with this. Then suddenly you realize, okay, I’ve fixed all of these problems. I have a faster website. I have fixed most of the problems they were told to me to fix. How do you keep record of the website’s performance and how do you go about making sure that this first initial tweak that you did is going to keep up with your website and you’re going to maintain all of that performance throughout the whole existence of the website? What is your tip as a final tip on how developers or clients can diagnose the performance throughout the whole time that it exists?

Mike:
Yeah, I’ll make it short. I think it’s important to focus on both lab tests, which are these synthetic tests you run through GTmetrix and other tools, and then also look at the real user metrics, which is what actual people are experiencing, and then diagnose as much as you can using those tools and having some kind of performance budget in mind in terms of what kind of space do we have for, what are we going to allow for the LCP to be? What are we going to allow for the time to first byte to be? How much JavaScript, what’s the overall payload for the entire front page that we’re going to allow to be not larger than 500 kilobytes, for example, would be great. Sometimes it might be way larger and sort of tracking with a spreadsheet or screenshots or whatever you can, and sort of dating those to make sure that things are staying within your thresholds that you’ve defined, I think is a good starting point unless you have a whole performance team dedicated.

What we’ve seen at the conference, these big companies like IKEA, they have dedicated performance teams whose job is to make sure everything is running smoothly and they interface with the departments. I don’t think that’s realistic for a lot of companies, but we can still take some of the ideas and sort of track things. I think that most importantly is don’t just assume that once you’ve made a change performance-wise or whatever, that it’s going to persist indefinitely forever because the website is usually a living, breathing thing. You do updates to the plugins, etc. People tend to add more features and sometimes a plugin update can introduce a new performance bottleneck and it’s important to match that…

Marcel:
Or changing the homepage, or you have a different hero section, you have something different in your homepage and you suddenly think it looks way better. I’m going to sell a lot more, and then it suddenly affects one of the key metrics, for example.

Mike:
Yeah, exactly. If someone has hired a designer to implement something and you’re like, oh, this is beautiful, but the page has increased to five megabytes and all your metrics are way, way off, now aesthetically it might be better, but you’re going to end up losing money. In my experience, so I think having it in your workflow, whatever size company you are, to do some kind of testing to make sure that the performance is still good after you’ve made major changes or even minor ones. I think it’s important because people, business owners, will always check the money side of things and when they notice all of a sudden that conversion rates are down or have been trending downwards over a few months and they feel it in their wallet, that’s a very frustrating position to be in and it’s nicer to catch…

Marcel:
And they usually probably think, oh, it’s something with my marketing or advertisement, or there’s something with the products or reviews and they usually don’t think it might be the performance part of the website that is damaging their sales.

Mike:
Yeah, exactly.

Marcel:
So regularly monitoring the site performance is our advice as a last piece of advice for today’s episode. New Relic, it doesn’t store information that much, but it is a tool that you can use to just analyze regularly your website’s performance. Google PageSpeed Insights is something that some of the hosting providers have embedded in their system and some of them can also give you some notifications if you reach certain values that are not recommended. And I think GTmetrix, I’m not sure, is the one that you can also buy a subscription and have it regularly measure and analyze your website and send you insights to your inbox for you to be aware of…

Mike:
Yeah, GTmetrix actually even lets you, if you pay them a subscription, you can have it alert you if certain metrics have exceeded. If you say, I don’t want LCP larger than 2.5 for your product category page or whatever, it will actually send you an email and alert. And that goes back to the proactivity aspect, right? Where it’s better to find that out and do something about it immediately rather than finding out three months later. And revenue is down, morale…

Marcel:
And it also provides actionable recommendations as well. All right, so we talked about a bunch of stuff today. CDN, database optimization, image optimization, lazy loading, plugins, themes, performance key metrics, all of that could be potentially a bunch of other episodes that we’ll talk about. And actually it would be cool to bring somebody else as a guest to talk specifically about some of these key aspects. As a last recommendation, I think we can also talk about the PerfNow conference that happens in November in Amsterdam. You’ve been going to the conference before and you’ve recommended that conference to me last year and I went there last year with you. And

although within WordPress and WooCommerce we’re only used to go to the WordCamps and the different versions of those, PerfNow has… I haven’t seen the word WordPress ever in their website, but it has so much to do with our work and it has so much to do with the development work we do for WordPress. So I definitely recommend people checking out PerfNow. It happens in Amsterdam in November, it’s a conference that is not as big as any WordCamp, Europe or US or Asia that we’ve seen. And you get out of there with the will to just go back to your clients and say, hey, I’m going to make your website a lot faster now because I understand performance there. Would you recommend PerfNow as well?

Mike:
Oh, absolutely. The people who build the tools that we use and they’re pioneers of front-end performance and are sharing these incredible stories, a lot of them work for big companies and they give you real case studies where we’re talking millions of dollars at stake from making certain changes. And it always reinvigorates me every time I go where I’m like, oh, I need to build this now and we’re going to introduce this to clients and make everything better for them. If you’re a real performance enthusiast and love this stuff. I haven’t found a conference that’s more exhilarating than PerfNow and the people are super friendly. The vibe is really, really cool there. When we were there last…

Marcel:
And just being able to talk to the people who built all of these tools, they actually have something to say about what’s coming next and give advice on the evolution of all of this. So it seems also like you go to that conference and you’re in the future for the next one or two years and see what’s going to happen, what’s important. And the fact that you as a developer can offer that to the client and make money out of it and sort of turn yourself into their magician and do stuff that nobody else can do, that is super important.

Mike:
Yeah. It sets you apart for sure.

Marcel:
All right, this is it for our episode. Thank you so much for listening in and I hope to meet you guys in the next one.