Why website performance matters

Hello, everyone, welcome to yet another Buddy webinar today, we are going to talk about one of the most important things when it comes to the web performance. And we are going to talk about why this website performance matters so much and how we can improve it. I have Henri with me Henri, say a few words about yourself.

Hello, everyone. Hello, I'm so glad to be here. I don't know, how do I start about myself? You know, because I could spend the entire webinar talking about myself. I'll try not to. But let me see. So I'm a developer in the greatest city on the planet, which is Toronto, Canada. In case you didn't know, not Toronto, Kansas, because it is Toronto, Kansas. But yes, we're here to talk about web performance, which happens to be something that I love chatting about. And I'd love it so much that I started to work at a web performance company. So for anyone that's not heard of Web Page Test, we're going to talk about it today. But I am on the webpage test team. By catchpoint. It's a fantastic web performance monitoring tool, or assessment tool. We're going to talk about it today. And yeah, that's about it. I mean, I'm happy to be here. I like to run. Oh, and I collect and collect toy cars. I don't know if you can see that. I don't know. Yes, yes.

Yes. And my name is Maciek Palmowski. I work here at Buddy as a WordPress ambassador. And apart from this, I'm your regular webinar host. And okay, so before. Before we will start let's do a quick summary of what we'll talk today. So first of all, we will talk about what is web performance, we will then discuss a bit how we can measure it. Because there are many tools running lighthouse is not the only way we can do it. We'll talk well this core web vitals and what we can do to fix this, this performance on our website, because there are some tricks that are quite easy. And there are some tricks that really involve kind of redesign of your application because you just did it wrong from the beginning that suddenly this happens. And also, if you like our webinars, don't forget to subscribe to our YouTube channel, you will have the chance to get all the latest info about upcoming webinars. And join us also on our Discord channel, because we will have a chance to discuss what performance even after this webinar. Okay, so with this out, Oh, and one more thing, if you are on Youtube, remember, we started the poll right here. We will we are asking you what is your favourite image format when it comes to the web? So what is your favourite image format?

Man? Oh, man, that's a fantastic question. And, you know, potentially a political one. So I don't know, I'm gonna have to be careful how I answer this one. I mean, my favourite one is certainly going to be modern, you know. So we can suddenly disqualify a lot of image formats at that point. I don't know. You know, I think there's a lot to discuss there. You know, I can give you a friendly answer, I can give you one that I absolutely think suits my needs best. Probably the similar Tamala web p is the best. You know, it certainly does have. Oh, here we go. It certainly does have qualities that we need right now. And I think we'll be able to talk about that at some point today. I hope. I'm sure we will. But you know, what P is one that suits the needs of the web. And this is something I like to sort of joke around with sometimes, and I've given talks about this. You can't spell web performance without Web. P. So it's, you know, I'll leave it at that. But I think there are a lot of things to consider, and all things considered, and a kind of a global scope of what we want out of the web, which is compatibility, which is fast loading. And, you know, and some of the sort of details that we like, out of web formats. Yes, where p is one that you absolutely have to consider, you know, you're always gonna have the, you know, the edge cases, you know, like, hey, you know, I want 12 bit, I want 10 bit, I want this and that. And yes, there's some formats that might be a little bit better in terms of image quality. But we are looking at like the bigger picture. Pardon the pun. Yeah. Which is, again, the compatibility the opportunity to have it load on on every browser and stuff like that. So you have to consider where p as one of the potential favourites.

Yeah, I mean, if I would have to vote out also select with P. And during when you are responding to the question about what P, you also responded, by the way, a bit to a question that I wanted to ask you right now, about what is what performance and you already started talking that it's about the speed, not? Performance, it's not only speed, is there much money, there are many aspects to cover?

I mean, it's funny should say the cover, because I'd say the umbrella is ultimately user experience. I remember when I was sort of discovering their performance, and you know, you know, we like numbers, right? We like to know that, you know, something moves from this point to that point, in this much time, you know, there's a reason why the 100 metre race is the most, you know, sought after and washed race at the Olympics, you know, because people love speed, they love to know that, you know, someone can run, you know, 100 metres and 9.19 seconds or whatever it is. But when it comes to web, certainly, speed will always have a play into it. You know, we know what slow is, that's without a doubt. But we also know what a good user experiences. And that being said, I think wet performance is kind of like an inexact science, you know, it's a mixture of user experience, is going to be a mixture of of speed and performance. And ultimately, you're trying to measure something that is potentially intangible, like someone's mood, you know, I know when I don't have a good experience at a site, because certain things aren't loading fast enough or properly, or they're jumping around a page that is hard to measure. We're doing our best in and, you know, there's some very smart engineers out there who have been, you know, banging away trying to get that done in terms of like, what does it look like? How did you quantify a bad experience? But we certainly know how to quantify a slow experience, you know, because we can just measure that. So web performance ultimately, is a mixture of user experience. It's a mixture of speed, which is really under user experience, umbrella. And it's one that we try to have some control over. We try to create some best practices in trying to create this experience that's not going to, you know, ruin our mood and want to make us throw the phone away. And we tried to kind of like, make sure that it's as smooth as possible, you know, and there are so many reasons why we've come to this point, you know, I just mentioned having to throw the phone away? Well, that's because we are experiencing the web now. And I won't say exclusively, but predominantly on head handheld devices, you know, I believe it was 2016 and fall of 2016, you know, plus or minus a few months, generally, it was accepted that the data came out that finally, the web was being experienced more on the handheld device, the phone than the desktop. That's when that point, they kind of crossed the inflection point, as they might say, and we've never turned back, like, we're never going to go back to desktops being the predominant form factor for the web, it's always going to be the handheld device at this point. And in fact, you know, I'm sure you may have seen this. But you know, there are some territories where the web is being experienced on the handheld first, there are some people visit the chance in their entire lives, they may not touch a desktop that much, you know, there's a very good chance of that happening. So,

yeah, there are even many countries like this. I remember at some point, I think even China is one of one of such countries, because of many reasons. But yeah, and this changes the experience totally, because at some point, we were used to that we are using our our desktop, our laptop as

the main floor.

Yeah, exactly. And at some point, everything changed. If I remember that for it, at some point when I worked at the company, when we are taking care of content websites, we saw this moment when it the the thing that you said when it switched from, from desktop into into mobile at first, it was just I remember it was mostly during holidays, when we know that people were sitting on their phones dining, yeah, and dining together and on their phones, checking what happened on the word. And, and this, this totally changed everything. Because phones, especially at the beginning, weren't as fast as desktop. So that experience had to be totally different at first, when I remember that we had separate websites for for mobile. Yep. Just at some point. Exactly. Just at some point when everything started changing, when it comes to, to the battery life to the CPUs and everything on the mobile phones, we could think about going responsive, because responsive was for sure, a bit more power draining for mobiles, rather than a separate version just for mobiles that was lacking many things like it had less images, less styling, plus everything.

Yep, yep. Yep. It's, you know, the web has been around, we'll see, like, 30 years in a little bit more actually. But, um, there's so many things that are just discovered along the way. You know, I'm not saying that everything is a first. But you know, we are, you know, pushing the web, and the web capabilities further and further. But we're also making discoveries as we go along, you know, so I think these things are very important. And, you know, understanding that it's like, holy smokes, okay, this is what we need to change now. Or we can now do this. And so it's really, really important that people understand that there are some challenges along the way. And we're still making discoveries, even though we seemingly have been on the web forever. You know, let's go back to images very quickly. You know, we are hitting this turning point, and it started probably a couple years ago, where capabilities are now really manifesting so that, you know, we're able to sort of make these new image format discoveries, which is, you know, leaving some people a little bit uncomfortable, but this is technology at work, you know, there's nothing you can do about that.

changes it, everything just changes and it is

what it is, you know, what I mean? And, and this is potentially the, the, the sort of rough part of the transition that's taking place right now, which is, you know, we're moving from particular resources to other resources. And, you know, we're going through that potential compatibility challenge that 10 years from now we're gonna laugh that But we're just experiencing it right now.

I mean, probably in 10 years, we will be going for some other change. So maybe, oh, probably only the format will change. But at some point, you mentioned that this was, this was really interesting that we are trying to measure some things that are really hard to measure. Because, and this is true, but I mean, I think we can look at performance in in two aspects. Because there are some things that are quite easy to measure, I mean, the weight of our website, it's exactly in kilobytes or megabytes. If it's in megabytes, then you're probably not doing the best job. This isn't the first thing but yeah, but also there are things that are more difficult, but still, they are measured in some way. So how how we can, how we can measure it, how and how you should and how we should look at those results. Because it's not so obvious. It's suddenly it's not that if the lighthouse is showing us that we are green, that's perfect. And it's read that it's horrible, because it's not that easy.

Yeah, it absolutely is not. And, you know, I've talked about this before, and I'm sure you know, you've recognised it. And you know, we're not the only one sort of discussing this development is actually let me start with a quote. In fact, if I could remember this word for word, I'll be so happy. But Douglas Crockford a technologists programmer had compared, how did it go? He said that the front end is the most hostile territory, something along those lines. And it's so true, you know, and I'll even take him back to a little bit more history. Steve Souders, who, for the better part is known as one of the most, one of the earliest supporters of the idea of web performance and everything that was involved in having a, a site load fast, he essentially made a discovery that the majority of performance issues were in the front end, you know. And once you start to have that understanding, and the resources that are involved in, you know, in managing a load, and in managing a, a viewport that has to show you information, you see all the touch points, right. And everything that has to take place in sync, like a symphony, you know, if someone's off beat, or the note is wrong, you're like, what's going on, they did not read his music sheet properly, what's happening, the same thing is happening with a page load. So things have to happen in a very perfect order to have that perfect user experience that I talked about. So once you start to see that the order of a resource loading or resources loading can affect web performance.

That was sending, because some are blocking and some are not. And this is, I mean, when you will understand this simple fact of that some resources are blocking and some are not. Yep, this is one of the most important discoveries you will ever get. For example, CSS is always blocking.

Quite often it can be you know, but if you do it, you know, with due diligence, you can sort of manage that resource, you know, loading. Now, you mentioned the blocking, you know, how do you measure blocking, you know, that, that that's one of the metrics that, you know, you're talking about, like web performance, like what happens. And, you know, these are things that, again, these very smart engineers have been able to sort of, you know, quantify. So it gets down to some of these, you know, new metrics that I'm sure we could talk about. And sorry, I'm just looking down because I saw some, some stuff in the chat come up. But, but yeah, you know, these are the difficulties of the modern web development landscape. And, you know, so we talked about, you know, simple things like, you know, loading a to b, we know, you could just use a stopwatch, but how do you measure, you know, something like TBT, which is a metric of one of the six main metrics that you that you get, and which is total blocking time, you know, these are things that had to be sort of like, you know, figured out and measured and you have to understand that too. Little blocking time will also sort of like push your load time further, and then ultimately affect this user experience that we're trying to manage, you know, how do you, you know, we started talking about things like, I don't know, like time to first byte, you know, very old metric. But these are things that you want to keep in mind, you had to measure how long it took for that first byte to come back to the server, because that really can set you off to either good experience, or a bad one, you know, we start to talk about paint metrics, you know, and people like paint metrics, what's going on there, you know, and I'm still remembering, you know, some of the early discussions are being had, and I was following this, like, intently. And, you know, we have the first Contentful, paint the largest Contentful, paint, there was actually a third metric at the time. But it became so hard to manage, and, you know, this saw, like, little errors in its implementation, so it essentially got removed. But, you know, these are things that, we now also have to measure. And, you know, something like the largest Contentful paint, you know, the Think about, it's kind of like bizarre, but you start to understand what it means to have a good large, Contentful paint, once you start to, you know, get a bigger picture. And, you know, you and I talked about this already, the idea of web performance literacy, you know, understanding the significant parts of a performance, symphony, you know, getting back to the music that I talked about, and how everything has to be in sync. And once you start to understand that you start to look at, and sort of, you know, development differently. And understand when you look at these numbers, like when you're doing say, like a profiling or webpage as you're like, Oh, I see something weird happening here. Or better yet. The waterfall that we talked about, again, you know, people I don't think, are extracting the most information as, as they can out of a waterfall, because that could also be very telling in terms of what's happening with your page, right? Yeah, I mean, I don't know, I may have gone in circles there. But there's so much to talk about. And I do realise that people can get seemingly a little frustrated, but it's really sitting down and sort of understanding what each part what each metric represents. Looking at a waterfall, and understanding what can be taking place when you start to look at things that are in line. But that's also why, and again, I mean, I I'm not here to necessarily plug webpage tests, but we have a set of tooling and some features that can visually help you identify what some of the issues are, right? You know, so and before I move, we move on. And I just want to give you a quick example. I talked about, you know, the 100 metre race, you know, if I look at one person, because you know, it's eight lanes, right? And if I look at one person go from like the start to the finish line, I'd be like, Oh, I think that person's fast, looked fast. You'll have a better idea once you see that person versus seven others. And then you'll start to see and understand who's faster. And you know, when it comes to getting back to the waterfall, you can see what loaded quickly, and what did not, you know, so I get back to the idea of just kind of like having that literacy, and being able to, to look at some charts, data, performance data and just understanding it.

Yeah, and by the way, I was also I'm still also a big Web Page Test fan, because as you mentioned, those tools are really great, because the moment when you start comparing websites all together, sometimes you can see that until some point, your website is faster, so it's easier to find which things worked and which were done better. With some other frameworks, other tools because we already can see the difference. Even looking at the waterfall in the waterfalls, which framework was used because you quite often mentions on Twitter that especially many JavaScript frameworks behave in a bit different way rather than typical hT hT HTML, because because with HTML, we can see that all the things appears, one after another. So we can see that first the tax laws, then the font changes, images, start loading, and so on and so on. And what happens with many JavaScript frameworks?

Well, I mean, I think that with any platform, whether it be Gemma's JavaScript framework, or CMS, or anything of the sort, you know, part of the decision making, I mean, there could be a multitude of reasons why you may pick one over another. But the one thing that we tend to keep an eye on in web performance, our patterns, you know, are, you know, repeating patterns in terms of, you know, understanding that a particular framework has a tendency to react like this, or react like that. And this is no attack on React, but I just thought it was a very interesting, you know, choice of words. The point I'm trying to make is this. You know, we talked about all the things that you want to make sure you sort of understand. And, you know, if there's one thing I want to make sure that you take away of the few things, but the one thing for sure, I'm going to say is, you have to understand that where performance is an auditing, you know, to understand what's going on on the page. It's a bit of a dark art. But ultimately, it's like investigative work. Consider yourself a, you know, like Sherlock Holmes, a police officer, and you're trying to piece together the scene of the crime, you know, and some criminals have particular patterns, you know, because they tend to, you know, rob the bank at the same time, you know, right, before they close, you know, and you start to see these patterns, well, particular frameworks will sometimes act in a particular way. And you can start to see these patterns, you might be like, Hey, this looks like such and such, or they're loading, you know, a pile of this. And I know, framework X operates like that as well. So, this is why, you know, again, I get back to you, I did this investigative work. And, you know, frameworks tend to have sometimes these particular, you know, patterns that you can start to recognise a fantastic performance engineer by the name of Andy Davies. He was on a podcast years ago with a former coworker who actually had on a stream a few weeks ago by the name of Simon hertz and Simon Hearn, pardon me, I'll talk about that afterwards. And they did a podcast together. And I think they did like two or three episodes, these two work with this company called the NCC group that worked in performance into actually, but I never forgot this. And Andy mentioned something about the, you know, well regarded performance engineers and people who audit, the good ones will recognise patterns, because they've done so many, and they can start to pick out what the issues are, and where they come from. These are the patterns that I'm talking about. You know, you mentioned earlier that you work in, specifically in the WordPress environment, ecosystem. WordPress has particular patterns, you know, exactly, and you start to recognise these and, you know, I'm gonna throw some out real quickly, you know, for everyone in the chat, and I know, there was one question I want to get to in a hot second, but, you know, everyone listening and watching, for example, like the the median Lighthouse score across the web, around like 8 million sites is 41. Which Yes, folks that is a failing grade. But the median One for WordPress is 26, if I'm correct, and that can be for a number of reasons. But once you start to look at some of these sites individually, you start to see patterns. And these are things that we talk about. I'm actually working on a presentation around WordPress and performance specifically, and I'm going to deep dive in some of these patterns and numbers to start to connect the dots, you know, because, you know, we could talk about the median amount of resources that a WordPress site has, and we can start to connect the dots to the particular performance score, or the the sort of anti patterns that that take place that end up in this sort of like, low score, right?

Yeah, exactly. Especially that one of the things with WordPress is the fact that many users use plugins without without thinking, which, which, in result gives them lots of unnecessary JavaScript CSS files, which in results, give gives us this 26, right. Yes.

And that's it, you know, I never want to lay immediate blame on folks. But I get back to what I mentioned earlier, which is the literacy element of web performance, right? You know, we can talk about literacy of the web in general, you know, and understand how the rep, the web operates, how it functions, how it functions best, you know, so, you know, we talked about the history of web performance. And, you know, I want to touch on this real quickly. Some of the earliest documentation that came out, and I mentioned his name, one of the authors, Steve Souders, who worked at Yahoo, I believe, at the time, but he came up with two well regarded books, both about web performance, the worst, the first one being called, I think it was high performing websites, or high performance websites. And the second one was called even faster websites, I think it was called. But, you know, the first book, he had a set of rules, you know, and I hate to call them rules, but you know, we could just call them best practices, actually. And, you know, he talked about some very sort of, like, you know, simple practices that 15 years later today, because this book came out around 2007 are still the case, you know, so for example, you know, we have a famous saying, and where performance, which is the quickest request is the one that's never made. Right. So, if you don't need the request to be made, don't make it. You know, some of the fastest websites are pretty light on requests, you know, and the ones that aren't, you'll see these long waterfalls that look like wallpaper, you know, in some of the audits have done over a webpage, as with some guests, we've seen something like 700 requests on first load. Do you realise what that means? 700 requests? That's a lot.

That's a lot. And I mean, a lot a lot, and especially, okay, now with HTTP two, it, it's a bit easier to, to do something with this, but before it is when we had the limitations of, of parallel connections, it was a disaster.

Yeah. And, you know, you mentioned HTTP two. The very interesting part of that, is that, yes, it was welcomed with open arms, you know, after decades, it seems of HB one, and all its limitations and, you know, the six connections at a time Max and all that HTTP two came around with what people believe the biggest feature which was multiplexing, you know, being able to open one connection and just stuff all the resources down the pipe as he could. But that came with its own challenges and shout outs to I think it was Andy Davies, and Mr. Patrick, meaning who discovered that, you know, servers had to be tuned to work with H HTTP two as best as possible, and not a lot work. So Um, you still had some challenges and limitations with h2, that were actually eye opening. And so we went from like many years of h1, got one to h2 for like five, five or six, maybe even seven years at this point. And now we're definitely in this h3 conversation, right. But every time we're just trying to make things as quick and as friction free as possible, you know, and we're talking about zero RTT. Now, round trip times, by the way, so things that seem as instantaneous as possible. But again, you know, all of that to improve that user experience. I mean, I'm gonna I want to go down and answer this one question here. Because I think I remember it came up quickly from

from Nikolai. Yes, exactly. Why this? What do you think is the next steps in the web evolution, like with handheld devices evolution that you've mentioned?

So? You know, that's a great question. You know, and it's funny, because I thought about this recently, again, for a couple reasons. So the first evolution is the fact that we are absolutely in a handheld world, you know, you have to, like that is your baseline, you know, you're not designing for the desktop, you're like, you know, we are in a handheld world, it is what it is. Now, what ends up happening is that you have this massive delta between the devices that are on the network right now, you know, believe it or not, I'm on an iPhone seven. You know, I know people are whistling in the chat right now, like, Ooh, what are you doing with that old phone? Either? And, yes, some people on the iPhone 13. But there's some people who are on the iPhone five, you know, and one thing that I discovered in some of my research, and, you know, thank God, there's some people out there doing this research I can read it is that, you know, we tend to in more or less developed, you know, world tend to get a phone. And when we're not happy with it anymore, we just put it down, and we get a new phone, you know, and the old phone, we might, we might sell it, but sometimes it just sits around, you know, in some territories, these phones used to get passed down, you know, to friends, family, kids. And so you end up with these old phones on the network. And people are like, what is this phone doing here? You know, it's still operating because of the web should work. And it probably does on some of these older devices. You know, so what you ended up happening, you end up having is this massive range of devices that are not web, some that are handling the web, as it is fairly well, and others that are not, you know, and, you know, we are keeping this in mind. There are a couple of things out there that really made me realise that, you know, the web is a phone first. Sort of, kind of content. What I just mentioned, no phones getting passed down. Also, it never really worked, and didn't sell well. But I don't know if you remember that. That Samsung Dex thing? Where Yeah,

your phone could be your computer.

I thought I was like, something's going to happen here. Because if you could get like $100, you know, monitor and just drop your phone on there. And this suddenly have like this home desktop thing, but it's still the phone as the guts. You know, to me, they're onto something. But, you know, in the spirit of trying to sell phones, they kept it to like higher and higher and, you know, phones and whatnot. And that could have been a couple of reasons. But that made me think a lot. And I actually also found a patent application by Apple. That was, imagine a empty a laptop that was like an empty shell. And then you would just put the phone in it and turn it into a laptop. And I remember seeing that and my mind was like it's over. It's a phone world. So, you know, to get back to your question. No, collect it, this is where it's going. And this is why resource loading is super important. You know, if you ever get a chance, someone like Alex Russell, who has been the biggest proponent of resource management, especially JavaScript, in light of what JavaScript does to the experience and devices in general, you don't you start to realise how the best experiences have the JavaScript resource loading, managed? Well, you know, because JavaScript is that one resource that will just lock everything up on your phone. Yeah, you know, you can tap the screen and nothing's happening. JavaScript, you know, exactly, total blocking time, quite often enough JavaScript. You know, I know you mentioned core vitals, you know? So even though you know, there are three figures, right, so you have your LCP, which is your largest Contentful paint, you have your CLS, which is your cumulative, cumulative layout shift. And then you have your fid first input delay, which they're playing with the idea of potentially not having that anymore, we could talk about that afterwards. You know, and, you know, because they're talking about a responsive responsiveness metric right now, we could put that in the show notes. But, you know, shockingly, you know, fid a first input delay that has like a little bit of sort of, you know, a JavaScript element to it. Shockingly, it's a score that people seem to hit relatively well. But I also believe that they're not sure if this is the right metric to use. Because the way JavaScript can affect the page and lock up, the CPU thread is absolutely toxic. You know, if you look at some of the results when you do a audit, and you'll see that, you know, total blocking time, sometimes it's just like, off the charts, you know, and again, these things don't tend to manifest that much on a desktop, because that's what we're using to test a site. But on a person's device. That's not going to work. Well. You know, yeah. So that's why we talk about like, the the sort of like the management the the would there say earlier? Oh, my God, the arts gonna come back to me anyways, keep going.

Yeah. So what do you think has the biggest impact on on performance? Because we mentioned already, loosely, a few, few things. But you know, the numbers, you know, the numbers, you did a lot more audits than the right. So what are the things and how to how to fix that?

Absolutely. Well, I mean, let's look at the, you know, I talked about the core of vitals. Let's talk about the core vitals work very quickly. I mean, I was just reading a couple days ago, and I was looking at some data from myself, we were in April right now. Right. So the march data, Crux data, the March Crux data, by the way, which is Chrome user experience report, and they come up with data indicating like what they're seeing on the web, and across, like about 8 million sites plus and a man maybe I should pull it up. Let me see. I don't want to, you know, screw up this stream, but I might be able to see if I could find it again. Or it might be on a different laptop. Okay, you know, I'm gonna come back to stream door. So I mentioned the three data points of core vitals, so large content for pain, fid and the CLS. The one metric that sites fail consistently is the largest content for pay. And I believe under 40% of sites have good It LCP and if you are, you know, understandably, someone who may look at your Lighthouse score, and say, Okay, what's going on here, your logic content for pain is going to be worth. And I don't want to sit there and say like, this is how you have to look at it, but I want you to understand it, it's going to be worth 25% of your score. You know, so if you're failing that will say you're, you know, at 40%. If you do the math, that's about 10 points out of 25. Right. So right away, it's not looking good. And and that has to do quite often, with a few things, but quite often enough with images. And so if you start to mismanage things, like images, and especially your hero image, a lot of things can go south. And very quickly, I had a I ran a couple, sort of, I don't want to call it conference, but it was like an extended meetup around images. And I've had two talks, presentations around it. And one by the name, one developer, by the name of Patrick Hall's shout outs, Patrick. Yes, a talk called This Is Your LCP, on images. Which I think it was a cute play on the, you know, your mind on drugs, whatever. And he tells you, you have the very limited, you have a narrow window to get that image, right, it's got to be I think, under a particular amount of kilobytes. Before you start to lose points, if you want to look at it that way, you know, before your LCP starts to just, you know, go go south score wise. And, you know, there are several ways to fix that. One of them is to make sure that you manage that resource in particular, because if that's going to be your biggest resource loading in the viewport, which is essentially what your largest Contentful paint is going to be, you want to make sure you manage that well. So if you haven't your image in the viewport that comes in early, you want that to come in fast. So there are ways of handling that through some resource loading tricks. But you also want to optimise the images best as possible, a modern format, and, you know, make sure that it's sized properly. You could also do something like have your large Contentful paid be text based, right? There's no reason why you have to have an image in the background, because it's going to be your biggest resource loading, it could just be text loading. And generally, largest Contentful. Paint, that's text base, is probably going to come in fairly quickly, if you're slick about it. Because you know, you can preload that, and pre loading text tends to, you know, be a less of a burden son burden, some endeavour than an image. And that will come in very quickly, you know, again, adding to the user experience that we want, because users gonna see content on the page coming in fairly fast. And it's like the headline, you know, I don't know, it could be anything, and it's like, okay, now I see what's going on, and adding to the user experience there that we talked about, and so you can get like a good LCP. So those are very low. I shouldn't say low, but those are relatively low hanging fruit in terms of getting your LCP up, which in turn, will lift your score in general. And I say that and I spent time on the OCP. Because, again, I get back the fact that, again, we could put this in the show notes that the LCP is the one that developers seem to be screwing up the most. And that's just the data. You know, this is not hocus pocus magic, you know, I'm just sharing the data with you.

Okay, to be honest, this is this is interesting. I never thought that NCP is the one that is failed the most. But on the other hand, what else? What else?

I just think it's managing resources as much as possible. You know, you can't improve what you can't measure, you know, so if you know Hey, so Chris Boyer, would, every so often would say something like, oh, you you say it's such and such, we'll prove it, then, you know, and and from some, from time to time, you'll see me on Twitter get cute. And I'll say like, oh, you're fast, we'll prove it. Show us the webpage. You know? And that's for you, not just so much for me, it's for the developer to understand, like, you can't go around saying that you're fast. And when you're potentially not. And, you know, I encourage everyone out there to just go out and, you know, there are a bunch of ways. So, you know, you're you deployed, you live, I'll get tested, you know, see what's going on, look at what, what's loading, how there's some things that will escape you, that's without a doubt, you know, and you'll be able to make the appropriate changes. It's about testing as well, you know, being able to look up particular resource strategies, and maybe they're going to work well, maybe they're not, conflicts happen under the hood, you know, browsers by the way, I wish I could find this quote, and I'll probably put it in the show notes. Someone had said, once the browser is the greatest piece of software, bar none. I actually agreed. Because if you start to understand what the browser's doing for a page to look nice, on your phone screen, like you'd be shocked, you know, so the browser's as smart as they are, they have to make a lot of decisions very quickly. And sometimes, you know, they might override something that you mentioned, you know, that you coat it in, but other days, they will not. And then you spot these mistakes. So, you know, testing is going to be important, because you're going to be able to see what the issues are. As you test, the only way you can see the issue is to have that literacy that I talked about being built to read that page and be like, Okay, I see that this is wrong. So I gotta fix that. And you know, what? Adhering to some very, you know, simple principles, you know, like image management, you know, years ago, that didn't seem like a big deal. But it absolutely is right now. Because you're on devices, you're on, you know, ordinary networks, you know, yes, you may be on 4g, and sometimes 5g in certain cities, map to policies of metropolitan cities. But, for example, and this, I read this today. You know, apparently Netflix is in trouble. You know, they're not getting more, they're losing subscribers and stuff like that. Oh, no, no, no, it wasn't Netflix. It was another streaming channel. And someone in the comments in ad said that they're in small town, America, and they don't have good bandwidth. And you know, people were making fun of this person. But this is absolutely true. There are parts of the world, even the developed world, where bandwidth is not that accessible.

Yeah, exactly. I mean, and we are talking as a set third world countries that are just outside the big cities. Yeah. Yep. Sometimes it's very, it's been very closed. It's just there's no cable. There is no 5g Nothing. Yep. It just happened.

Absolutely. Listen. Here's another stat for you the top three countries for low end devices, you know, so not immediately, iPhones. What do you think? Pretty countries.

I think that they're low. And I think there were something from from from Europe. There were some, if I remember, right,

so I believe number one was India. And this is from about this data is about three to four years old, you know, because I remember I was watching our presentation. Indios one surprising to me, I believe number two was Russia. Bad word around here now so but number three was America, United States.

This surprised but still, it's an enormous country. So statistics,

values, you know of like low end phones being sold. So these things start to like open up your eyes, right? And you start to understand that you know, it, the average person may be carrying a very average device. And in fact, you know, I could probably point to this in the show notes. So you'll have to remind me of everything that I've been putting in the show notes. A good friend of mine, Aaron, what's Aaron's last name, he works at fastly, Turner, Aaron Turner, real life experience, he talked about not having the most disposable income, and being given a very low end phone, but it was a phone nonetheless, that he could use. And he talks about that experience in a talk that he has. And it was just as low as it got $100 phone, but it was a phone. And there were a lot of these phones being distributed. In America. You know, it was part of a programme where people could could be given a smartphone. But it was like the lowest of the low ends. So these things are around. And so that's why, you know, web performance is important. Web performance is the resource management of things that are loading onto the page, because or into the viewport, because like I said, you don't know what the how powerful these devices are. And you want to make sure that they're given just the resources that they need for this page to, you know, populate the viewport as smoothly as possible.

Yeah, yeah. Overall, this is just a very interesting thing that comes from from from the things that you mentioned at the beginning. Many people think about before performance as numbers, illustrates numbers and the thing that you talk, especially now about those cheap phones, and that yes, this is not an exact science. I mean, yes, we can talk about use modern formats. Remember about setting the correct headers and using the correct server? And yes, of course, this will have a huge impact, by the way, always remember about using zip or using? Yeah, I mean, they've been brought, there are hundreds of tutorials. Which configuration will be the best for your technological stack, because it will look totally different, depending on which server will you use are which application you are using are many, many other things. But there are so many things that are so either hard to measure, or for many developers hard to imagine, because we also have to remember that we as developers, mostly work on better computers on vendor phones, we have a totally different perspective on it. I mean, yes, we statistically earn better. So we are spending this on tools on which we work because this very well. Exactly. But on the other hand, our end users, there's enormous chance we'll use something exactly opposite, yet we have so so to be honest, your your way of using an older phone. It's a very practical way to test the performance all the time in some way. Just an older phone. That's it.

I mean, it's the reason why, you know, whether you look at webpage tests, or even other applications, like lighthouse, whatnot, their base testing model is usually about 3g. Connection, you know, so you can exactly synthetics, 3g connection, and a moderate phone, you know, so the CPU is throttled, the connection is throttled. So, you know, you want to convey that experience as much as possible. Because, again, the old adage that, you know, we're on a desktop computer and, you know, that's already powerful. And then, you know, we have amazing internet in connection, like, I'm hardwired right here, you know, I don't do I don't do Wi Fi. You know, I'm a snob. But but the reality is having a phone outdoors, you know, the the network connection is anything can happen. You know, how do you how do you replicate walking in between buildings? brick buildings in an Amelia, these are things that happen like you walking in and out of a building and you know, being in the middle of a transaction, you know, you can replicate that in, in a sort of closed environment. So that's why have you tried to make things as friction free as possible and that means, you know, loading resources as they're needed, and not dumping everything down the wire, right. But you're not going to notice these things without testing, you know, without exactly doing an audit built without understanding what is taking place on your page, you know, are you, you know, loading images that you don't need, you know, because, for example, the majority of people don't go to the bottom of a page, if that even exists now. It'll be like, pages don't end now. Right?

But the infinite scroll Exactly.

But you want to make sure that it's not the infinite load. Right, you're not loading all these images that are just, you know, coded into a page, you know, you don't want them loading, if they're not going to be part of the viewport, you know, so lazy loading, you know, and, you know, I, we could have talked about, you know, the browsers what they're doing to help us out with that all these new performance API's that are out there, specifically to address these issues. Because again, these are discoveries that are made a long time as the web has matured, right? lazy loading wasn't available to us 10 years ago, at least I don't think so. You know, but we realised it was an issue. And it went from lazy loading libraries to now lazy loading been baked into the browser, because we needed it.

Exactly, exactly. By the way. lazy loading also created some some problems, because lazy loading an image that is right away, in our viewport will be loud, will also cause Yeah, so this is this is also one of the examples that there are no simple solutions. We have to test it, we have to test it because just because we

absolutely well, and that's it, you know, you won't realise that you've added a lazy loading attribute to your hero image that is, you know, part of your LCP score. So, you know, I compare it to, you know, driving with the handbrake on, you know, you're just, it's just not going to work.

Exactly, exactly. We also have two questions to answer questions that we got from from from people who, who added them during sign up. So we have one from James assuming QR going to mention the Webcor vitals in the webinar, is there a way in Buddy to monitor test those on site? So, yes, there is. But Partially, because we have a lighthouse action. So you can have, you can test the lighthouse scores as a part of your pipeline, which is a very good practice, because you will know every time when something changed. But we don't have all the metrics, we are working on it. So at some point, it will be released, I hope it will be released sooner than later. So just more questions to me. And for you, why does the site performance need to be monitored? Like regularly, I have noticed that if the site is left for too long, it performance decreases. And this is a very interesting question because it, it can have many answers.

regressions happen, actually, it's funny, you should mention that because, you know, as was mentioned earlier, by myself and yourself, and you know, if you've not noticed my handle on the page, I'm at WebPagetest. And which actually just, I was supposed to release this, this little video with one of our team members. Shout out to Mikhail ready. She talked to one of our engineers about regressions, you know, and why it's important. And you know, why it's also important to have performance budgets, you know, that's again, another topic we could probably dabble into, at some point, but regressions happen, you know, people get on, you know, you have a code base that potentially, you know, several like an entire team is working on. And before you know it, you know, some some updates are made and, and, and if they're not tested regularly, you may not notice these things, you know, and you talked about automation there So many ways to get that notification. Now, you might get a Slack saying like, hey, you know, those are aggression here what happened, you know, come back. And these things can happen, like, you know, we talked about. So we do a bi monthly, or is it bi weekly, I think it means the same thing. So twice a month, we do a stream, usually. And the last stream, we had a gentleman by the name of Simon Hearns. And we talked about third parties. And we talked about how the ad network, and we briefly went into how that works, because I wasn't that well versed in it. But once you have these arrangements with these ad network companies, what loads onto your page is completely unknown to you, you just know that you have a deal. You know, you've signed the dotted line with a company that says, I'm going to provide ads on your page, and you'll be able to make this, you know, extra money. Well, you know, once you start to see what's happening behind the curtains, under the hood, with these ads that they even don't know, are coming up. It's bad news, you know, so you start to understand that monitoring what's happening on a more consistent basis is required, you know, and regressions can happen, you know, if you want to maintain a, you know, a load that's going to be under a mag, a lot of things can happen for that to not stay at where it's supposed to be. I was just going to give you an example. And I just forgot. Let me see, I was going to talk about Simon Hearn, and stuff loading onto a page, and we don't know what's happening, anyways. But, you know, this is, this is basically what can happen. And, and, again, I get back to third party and the advertising levels. Here's another example that just came to mind, the same site may load completely differently in America. And then in Europe.

Yeah, exactly the server from from from which the testers it's happening, can can change everything. Also, let's not forget about one more thing. The lighthouse scores also evolves and changes, I remember that the first day they introduced the car with vitals, most of the scores when went down, or on the other hand, when at some point, I don't remember which was, which was exactly, but they introduced the something from HTTP two as a standard when it comes to testing. And suddenly, scores went up. So we didn't change anything, nothing went bad. Just the algorithm, the way they are testing changed, and, and our score just can change overnight without any any reason, but also the fact that you mentioned, because there are many unknowns on our website on those third parties.

Mm hmm. You know, just

providing the dynamic URL, and the file on the other hand can change. And

we have our pictures, we have this integration with this tool called Request map, you know, which essentially shows you what is taking place at a page load, and everything that, you know, gets requested in the background, some you're aware of, but a lot you're not, you know, and this can change again, depending on the your, your your arrangement with your ad network can change without you knowing, and, you know, what you believe should be like a, I don't know, one and a half Meg load page load could be like, five because some, you know, an ad is now the one that, you know, a seasonal change to an ad now on your page, an ad that wasn't optimised properly. And you have actually companies, you know, that have teams that work with clients to optimise their ads as best as possible because that's another layer to a problem, right? So and that's all connected back to your site that you feel

because we already know from from many research that the faster the site loads, the bigger channel that we will buy something

absolutely like, you know, we could talk about that E commerce, the E commerce element to that whole experience because you know, you don't want to lose a potential customer to, to what, like a third party that you had like no control over. Shout outs to Tammy Everts. She had written a book. I believe it was called. And we'll put this in the show notes to again. I don't mean to give you all this work, right? I'm like, Yeah, sure. No stone on shownotes. But I think to call the time is money. And she basically talks about how web performance is connected to commerce, you know, today, in fact, somebody tweeted me about something. And I brought up something else that we'll put in the show notes. It is WP o stats.com. is a website that she curated with a coworker of mine, Tim cadelec. And he talked about the connection of commerce and performance. And they are case studies, a, a set of case studies where companies talk about, you know, the positive impact of web performance on their bottom line. You know, so something that you want to check out as much as possible. But yeah, let me superduper important. It's the reason why Shopify has a performance team. You know, a dedicated e commerce site, or ecommerce provider, has a dedicated team that looks after performance. Consistently, shout outs, Colin Bendel in the building.

We also know how much money Amazon invest in investment, because they were the first that started talking about it. I don't remember anyone before them. So

Amazon. In fact, you know, as you say that, because I talked about that case, which was on the WP awstats.com website. I brought in someone else into the conversation because Walmart had also published a very famous study around that, around that concept of making sure that they were fast. And I could put that in the show notes too. You know, I've talked about the idea that I would spend time on amazon.com not to buy anything, but just because I knew it was a pretty fast experience. And I could just browse and not be annoyed, you know? Yeah. So yeah, that certainly has a lot to say and do around performance.

Okay, I think that we talk about so many things. But the bad news is that there are still so many things left, because performance is such a wide topic. Do a special episode on on E commerce. optimising some exact cases. So if if someone is interested in listening to them, just tweet us or or contact us in any way. And we will think about how to pursue the topic next. Because yeah, it's very wide. And it's much more than just numbers. So

I mean, if yes, you know, I don't know if you know, I mean, I think there could be compatriots. The good people have view, commerce, view, view, commerce, view, Congress,

view, storefront storefront.

They are big supporters of the idea of having proper web performance at the EECOM level. So it's the probably have a lot to say there as well.

Yeah. So we have like, a lot of topics to cover in the in the upcoming webinars. So for sure, we will be back with the with the with the performance topic. For now, a really big thanks for sharing for sharing everything. I mean, not everything because I know that you know, a lot more but sadly, we only had this one hour to talk about it. And I wanted to mention about a few things because I can mentioned start, we mentioned the poll about the favourite image format you use on your websites and web p one, and on the second and second place was to buy JPEG, PNG and SVG both on the no one wanted to use a wave. Yeah. So okay. Bunches, maybe in a year or two, we'll see that a beef will be fighting alongside with what P R, who knows what? What will happen? Apart from this? On May the fourth so it will be really we have to do a Star Wars edition of. Yeah, because it's my May the fourth with the Pantheon multi Dev and body integration, we will talk about the perfect WordPress development combo together with Hausa from from from the pantheons. Awesome developer DevRel. Team. Apart from this, remember about our meetup group, you can sign up there and be informed about upcoming webinars. Absolutely. Like I mentioned before, if you like what we are doing, if you like to listen more often to subscribe guests as we subscribe to our channel. So so we know that you like to do like our, our work our webinars, and you want more. Also, we mentioned in all the chats on on Facebook, LinkedIn, and YouTube, our Discord channel. So if you would like to still talk a bit about web performance, join us there and yeah, and I think, yeah, I think that's, that's everything for today. I hope that soon we will, we will see again, and talk a bit more about about some louvred farmers,

I mean, what I'd love to do is, when I'm done a little bit of that research that I was talking about, and for a target of coming up, I'd love to potentially come back and deep dive and share some of the findings, which would be specifically WordPress, and performance related, like nothing else. And everything that's well, I shouldn't say everything, a lot that's involved in that conversation. But we

could try to automate some fixes for for the problems. And this is, yeah, this is what we have to do. This is

so absolutely. And you know, the next thing I was gonna say is, I definitely want to make sure that we have that conversation. We've hashed up already, but you know, the the API conversation and having potentially a demo of how that can be fixed for automated for sort of the WordPress developers out there who kind of want to take their performance testing another extra step further, with web pieces, and, and the kind of like the pipeline that we might be able to create there. So we certainly want to do that have that conversation? And if I don't, you know, see you before your big talks, I guess people know that you're having a big talk in Europe.

It sure I, I mean, I already shared this info Twitter. So, so the few people now so and yes, during during this workshop, I will I will be showing the ultimate WordPress CI/CD pipeline, of course, there will be a step of measuring the performance because this is one of the most important things right now. We will live in a in the strange time when we have so many the most important thing in web development, because we have to focus on so many things. But yeah, performance is really one of those that and it really better performance can really in an easy way convert to to money, just like this.

And who hates money? Go hand? I can tell. I don't see us. I don't see a hand up. Exactly. That's what I was gonna say is, with regards to some of the data that I said I was going to share the one data point that I did share, which was around the median Lighthouse score for WordPress sites. That was all collected from the HTTP Archive, if anyone's familiar with that, and we'll put that in the show notes. But that came back from the their annual Almanack that they put out where they share some of the most interesting web data that's across our fantastic internet right now. So and they pull and go through like eight and a half million sites. So it's fairly thorough in terms of what you see out there. So if you're interested in more that information,

okay, so I think it's time to wrap everything up. I thank you again, thank you again. It's been

such a pleasure. Thank you. You, like everyone involved with having me here? You know, I think it's a fantastic opportunity, you know, to connect worlds apart. You know, I'm here in North America, and you are in Europe and Poland. It's like, hello, you know, and I think it's great for everyone to be able to watch and see and get some of this information that we have to share.

That's That's exactly true. So, so thank you everyone for watching guys and see you in two weeks. We will really have to think about some Star Wars theme might be interesting. Yeah, I hope so. Maybe I will find some costume or something. Okay, so thank you, everyone.