 to those in the room. Hello, wake up. I hope you've had at least your second cup of coffee. And to those at home streaming, hi. Again, I'm Santana. I'm your emcee for track one bright and early. I've only had one cup of coffee this morning. So if anyone wants to deliver one to the front of the stage, I would really appreciate that. Next up we have a super interesting talk. Our friend Slobodan Manic is going to join us. He's a website optimization consultant and he specializes in e-commerce optimization. This talk I'm really excited about for you all to hear. It's going to be on how to improve website performance, so everything from site speed and image load time, et cetera, et cetera. So this one's going to be one for minority friends. I think I'm excited. Please welcome Slobodan to the stage for Word Camp Lishko. Thank you. Okay, thank you, Santana. Thank you, everyone. Thank you to the organizers who put up this amazing event. This is my first speaking Word Camp, so be kind to me. How do I follow up a talk about AI with something as boring as front-end performance? Well, I do my best, so let me start by showing you this number. Can anyone even try to guess? It has to do with WordPress. What this number means? A wild guess. That's the number of lines of code in WordPress, the CMS. When you add things according to WordPress Foundation website, so I believe it's true. When you add a theme that does everything, when you add plugins that you can install freely from your dashboard, that goes to 400,000, 500,000, whatever. Now, the reason I wanted to highlight this number is in any given WordPress website, more than 99% of lines of code will never be seen by anyone involved with that website. Developer, the person assembling it, the manager of the website. To me, that's scary. I'm a former WordPress developer. This is a scary thought that you have no idea what's happening and basically no one is in control. So, today I want to talk about how that affects front-end performance in WordPress and what you can do about it. And I will do a talk that shows you three reasons to care about front-end performance. I will give you two of the biggest issues that affect WordPress websites. And then, finally, I will give you one very, very simple recipe that you can follow to avoid facing these issues in your websites. So, a little bit about me before I start. My name is Tolerant Manic. I am a website optimization consultant at NoHack's Marketing, the agency. I also co-host NoHack's show, a weekly podcast about website optimization, SEO, technical SEO, content, CRO, all of that, where we talk to really smart people every week. I'm a former CTO at Search Engine Journal and this was a very transformative work experience for me because that was the first time I was not working with developers. I was the only developer in the room. I was working with SEO people, marketing people, and the way they see websites and use websites is different than the way we do it, or developers do it. I discovered WordPress in 2007, first as a blogging platform, which I then wanted to tweak and optimize, and then I started developing and writing code. I'm a theme author, plugin author, team review team member, and a five-time core contributor. So, a lot of WordPress experience over the years. Now I don't really develop. I mostly optimize websites, as I said. So, the three reasons why you should care about front-end performance that I want to share with you today. Question, does anyone in the audience enjoy slow websites? Are there such people in the room? Fast websites? Okay, good. So, the first reason is the people who are going to be using that website. This is the most obvious thing that you can hear. Of course, no one likes slow website experience, and there are countless studies that will show you that slow websites don't do as well as the fast ones. So, I just want you to highlight these two numbers. 70% of consumers admit that page speed impacts their decision to buy something from a website. And the second one, even more interesting, this is from an unbound study. 50% of responders said they don't care about the fancy graphics that we put on the pages. They just wanted to work fast and work really well. So, this is something that's really, really important. We put all those images, we put those videos, we embed YouTube videos. Most users, or half of the users don't really care about that. Now, this is a great quote by a comedian that just applies to anything and everything online. So, before you marry a person, you should first make them use a slow internet connection to see who they really are. Yes, you should. And in 2023, this is as applicable as ever, but it's not just the speed, it's about the loading experience, you know, the whole core web vital thing, how the page loads, how it moves around when it's loading. Is it interactive? So, websites can divorce people in more ways than you can imagine in 2023 and we need to be careful about that. So, the second reason, number one is the people. Second reason is the non-human users of your website. And that's the crawlers, that's the bots, that's everyone that's interacting and that needs to understand your website is not a human. So, anyone who does SEO here, or every person who does it, you know what Googlebot is, right? Okay, Googlebot is a software that runs on, I guess, thousands of computers that just analyzes and crawls every single web page on the internet and creates the Google index based off of that. I'm sure Dave will say this will change and it will. This will be a huge shift in the SEO community with AI and everything, but currently Googlebot is the one that needs to process every single page and then put it in the index. So, slow and heavy pages take more time to crawl, simple as that. If it takes a long time for a human user to load a page, it's going to take a lot of time for the Googlebot and other crawlers to crawl it. And with Googlebot, with Google, there's this thing called the crawl budget and that is simply the number of pages Googlebot crawls and indexes on a given website within a given time frame. So, let's say in a day you get four minutes of Googlebot attention. Let's put it as simple as that. It's not as simple as that, but you could say that way. And if you follow Google Search Central blog, if you don't, you should. But something they said and they tied this page speed and increasing crawl rate with the user's experience. So, according to Google, and this is from a few years ago, according to Google, better user experience, meaning faster loading times, will also increase the crawl rate and will make Googlebot crawl your website faster and more efficiently. So, crawling a thousand slow pages is going to take more time than crawling a thousand fast pages. So, if you have a website that has thousands of pages as new content all the time, if they're slow, your new pages will take longer to index, your updates to the content will take longer to be shown in Google Index. So, it's really bad. It's really bad to have a slow website if you want to do well with organic search. Now, the third reason, this is the most interesting one to me, is the environment. This is according to a study that BBC did in March, March 5th, 2020, is when they published it. We know what happened the week after that, the world changed forever. At that time, the internet and all the supporting devices and systems accounted for 3.7% of global greenhouse emissions. That is a staggering number. That is before we went even more digital with the pandemic, never to look back. And that is the same amount as the airline industry at the time, which to me is mind-blowing. Of course, this is not all WordPress, this is all different websites and streaming services and all that. But this number was also predicted to double by 2025. I would bet it already has. So, let's have a look at what front-end performance is and what it takes for the browser or use a device to display a page. This is the oversimplified diagram of what happens when you type in a URL in your browser or your device. So, it starts with the HTTP request that you make from your browser. There's a DNS lookup to find out where the website is hosted. The request goes to that server, give me that page. The server returns either a static page or a dynamic as in WordPress. There's some files on the server as well, assets, CSS, JavaScript, images, all of that. The response in the form of an HTML document is returned to the browser and then the browser needs to do all the hard work with that page, with what was returned. Now, some of the assets are going to be on the same server, that's the first-party assets. Some are going to be on different servers, those are the third-party assets. So, if you have something like a Facebook pixel or Google Fonts file, that's somewhere else and you need to make a connection. The browser needs to make a connection to that server as well. So, this is what happens when the page is returned and let me just go back. Frontend performance is what happens here. So, the response, what it is and how browser interprets it. How long it takes for the server to return the page, yes, that affects how quickly you will see the content in the page but that's not frontend performance, that is something completely different. So, this is a very complex diagram of what the browser needs to do before it can show you the page. When you type in the URL and when it gets the document back. So, everyone knows the DOM, like this is a work camp after all. Everyone knows what the document object model is. The HTML document is converted into this three shape structure that has the HTML tag at the top and then it has head and body and all the tags inside. Fairly simple but if you have complex HTML it could be problematic, it could take a little bit longer. At the same time, the browser constructs a CSS OM. So, basically that's all the CSS styles in the page from all the external files embedded internal or whatever inline CSS and it creates this thing called CSS OM which is all the styles that override each other and what gets to be applied in the page. So, when those two are done the browser combines them into what's called Render Tree and that is the visual representation of the page and after that it calculates the layout, where each element goes, what it's going to look like, all of that. So, that's a lot of work if you're making it complicated. If the HTML is complicated, if the CSS is complicated, all that. So, we're not really helping by introducing complexity into everything we do. So, the HTML is usually more complex than it should be, the CSS as well and if you look at the chart from HTTP Archive, you can see that mobile page weight has gone up in the last 12 years by 1,300% which is just staggering and that is 55.9% images in that page weight on average and 30% of the pages are now JavaScript which is horrible for front-end performance. So, WordPress ecosystem. Here we are, it's a work camp after all. But let me recap, the two things that are not good for front-end performance are complex HTML and out-of-control assets, CSS and JavaScript assets. So, that happens in most WordPress websites, doesn't it? So, the biggest problem with WordPress websites, I'm never going to say WordPress is slow because WordPress CMS is never slow. It's about as fast as any CMS out there but WordPress websites and WordPress ecosystem, that's what it's about. When I say too many chefs, let's play a game again. I want you to raise your hand when you agree with me. I'm going to say five plugins is too many plugins for an average WordPress website. Does anyone agree with that? 10, 20, 50. Oh, keep your hand up. 50, 100. Okay, that's the number. Those are the chefs and in most WordPress websites, no one is controlling what the plug is they're doing. We install something because we need this small feature and then there's all the other junk that comes with the plugin and it does horrible things. I'll give you an example later to show you what that looks like. So, let's look at the two very common problems with WordPress websites and a reminder, complex HTML and out-of- control CSS and JavaScript. Those are things that are horrible, bad for WordPress for front-end performance and that you need to solve if you want your website to perform well. So, example number one is, or problem number one is complex HTML. Let's look at this element. This is a screenshot from an actual website that I was working on a few years ago. So, this is a section of a page and how many HTML elements should it take to render this? If you have the section, you can have two divs so you can have it responsive, image, H1P and then the ATAC for the button. I think that's all you need. You can get more complex than that, but that is basically what you need. This is what it looks like in real life. This is the code that is used to generate this. And it's a code builder, not a code, it's a page builder, sorry, it's a no-code solution. I'll just tell you that a no-code solution means that you don't know who wrote the code. It doesn't mean there's no code. It's simple as that. And Lighthouse, the page auditing tool has a flag for the pages that have more than 1,500 DOM elements and elements that go and pages that have 32 levels of depth of those DOM elements. So, this one, this tiny section, 26 DOM elements, depth level of 10. This is crazy. This is not the entire page, by the way, this is just a small part of the page. Another thing for SEO purposes, text to code ratio, so text here and code everything else should be 25% to 70%. This is how you get in trouble with Google. And then the second problem, and this is the one that I've optimized, performance optimized, a lot of WordPress web is over the year. This is the one that kills every single one. The WP and Q family of functions and the numerous blog posts saying it's as simple as this, just use this function and you can queue your CSS and JavaScript file. There are WordPress developers here you know what this function does, right? So, basically it enqueues a CSS file or loads CSS file and a JavaScript file in every single page of your website. You never need it in every single page of your website, right? So, I set up an experiment. Two WordPress websites that I tested using a web page test. One has a basic WordPress installation with zero plugins. Sore front team and zero plugins. The other one has these seven popular plugins. So, it's not 100. You said 100 is too many. No one betted an I when I said 10. So, this is not a lot of plugins. This is seven plugins. The most popular ones. So, five million active installs, five, five, five, one, two and so on. So, I tested the pages using web page test and I got this wonderful view of the pages. Obviously, the simple one is on the left. A lot more going on in the one that has the seven plugins. These are not bad plugins, by the way. These are popular, good, well written plugins. And to put this into numbers, the first page, the simple page, made 18 total requests, including the document, 17 assets and the document, five CSS files plus the Google Fonts external third party CSS file which storefront loads for some reason. Three JavaScript files, six render blocking requests. Now, render blocking request is an asset that the browser needs to download and process before it can show the content. So, it's not just about downloading while showing the content. If it's a CSS file, the browser needs to interpret all of that before it can show the content. And the page started to render after 1.8 seconds and the LCP event, which is the largest element in the page, was displayed at the same time, 1.8 seconds. So, page number two. 38 requests total. So, that's more than double. 12 CSS files, 11 were 100% unused in this page just because I installed plugins, nothing more. 15 JavaScript files for some reason, 15 render blocking requests, one third party render blocking request, the same one, the Google Fonts. Started to render after 3.2 seconds, so almost double LCP the same. Do you want to see the pages? They're the same. It's a hello world post. I just installed the plugins and did nothing with them. I didn't even configure them. I didn't do anything. This is the scariest part. This is the thing that needs to be solved in every single WordPress website. The out of control CSS and JavaScript files that are just loaded everywhere in every single front-facing page. So, I promised you one simple recipe. It's not a tactic. It's more of a philosophy and approach. And here it is. What you need to do is to be very intentional with what you have in your pages. So, remove the stuff that is not necessary. If you have a plugin that is loading, let's say you have a contact form plugin that's loading the CSS and JavaScript file in every single page. Why? You need to remove that. And you can do something like, I think it's called WP plugin manager to kill it off in certain pages, so it's only loaded where you need it. Remove what you don't need. That's what that means. Use a lighter version of what you do need if it's available. And that could be a different plugin. It could also be replacing Google Analytics with a lighter solution, more privacy-focused solution that's going to have a smaller footprint. And then optimize delivery of everything that's left in the page. So, what that means is defer the JavaScript files that you don't need early, defer the CSS files that are not needed for above-the-fold content, lazy load the images, facade load, YouTube embeds, all of that. Just optimize the order and end the prioritization of how everything else is delivered. So, that said, I want to give you some tools and resources. First, the tools. The most obvious one is Chrome Dev Tools. If you're a developer, if you're working with websites, not just a developer, you need to get familiar with Chrome Dev Tools because it will give you everything you need. You can profile your page better than with any other tool, I believe. The second one is Google Search Console. This is a great one because it gives you a high-level overview of your website. It tells you these pages have a problem. That page has a problem with LCP, with Core Web Vitals, mobile, whatever. And then you have to test the page with a proper tool to see what the problem is. And those tools are Web Page Test, which is my favorite. Page Speed Insights, which is Google's sort of a lighthouse-using tool. And then the open source lighthouse, which you can use as a command line tool. Node module, you can use it in your build process. You can check the pages before you publish them. Finally, the continuous monitoring tools, like Debug, Bear, or Rump Vision, they can definitely be useful if you're working for a large website and you need to monitor how it degrades over time. And some of the resources that I think are really good. Number one, this guy, Harry Roberts. If you want to learn about front-end performance, just start with him, because he's sort of the godfather of front-end performance. And there are two really good resources by Mozilla and Google. Google has a web.dev website where you can learn anything about accessibility, about UX, about performance, about SEO, of course. And the documentation website for Mozilla developer network is really something that you should bookmark if you care about these things. So that was that. If you want to get in touch with me, you can find me on LinkedIn or you can check out the podcast that I mentioned earlier. Any questions? Round of applause. Round of applause. Thank you so much. I found that very interesting. I saw a lot of heads nodding along. We have five minutes for Q&A. So start thinking about your questions. If you have one, raise your hand. Our friends in the yellow shirts will bring a microphone to you. I'll kick us off. One question that came up for me as you were talking, what is the most common mistake that you see folks make on their websites that contribute to poor site speed or poor site performance? Good question. It's really the assets. It's really what the plug-ins are adding to the website. And I removed that slide this morning. We had a meme, the Will Smith Chris Rock meme. I love memes. Not enough time. 20 minutes. So basically, WordPress is not slow. You're making it slow with your plug-ins. And that's the thing. And most users who are not WordPress hardcore people who go to conferences, they don't know that when you install a plug-in, it affects everything. They have no idea. I was talking to a person a few weeks ago working on a client website with 700-something plug-ins. I've never heard of anything like that. And he asked the person why. And the answer was, but they're just there. They're not doing anything. So we have to be aware that the average user has no idea what will happen when they install 100 or 200 plug-ins. Maybe there could be a better plug-in experience, plug-in install experience in WordPress where after 20, it tells you, whoa, you're going crazy here. Or average number is 24. Are you sure you want to have 67? So maybe that would be one solution. That's a great idea. Questions? Do we have any questions? Really. We got one here in the blue shirt. I think it's blue. It's blue-ish? Yeah, it's blue. Hey. As a WordPress contributor and plug-in developer, do you see a change in the environment to make more page-speech-friendly plug-ins? Because, for example, contact form is a plug-in that most sites have. And they always load the CSS and JavaScript. And there's no obvious way to remove that. Do you see the community is moving towards that? Or are we going to have inefficient plug-ins for a while? That's a great question. And I'll just say no. I'll be honest. No, I don't really write plug-ins anymore these days. My last core contribution was, six months ago, it came out, but it was something I wrote in 2014, because that's how track works, I guess. So no, I don't see anything changing. And my advice to people who care about this, if you use a plug-in that does things that makes these mistakes, just email the author. And why wouldn't they fix it? It's in their interest as well. There's another one. Great question. This will be our last question, folks. Hello. So I use a recipe of a couple of plug-ins to address these issues, and in order to have a top performance of 100% of score. So you use something like your own recipe about you use the kind of plug-ins that you use in your projects to address this? Well, that's a very difficult question, because every website is going to be completely different. But if I clean up plug-ins, let's put them that way. There's a plug-in that I think is called WP Plug-in Manager, where you literally tell it, don't load anything, PHP, CSS, JavaScript in these pages. So you only let it work in the pages where it's needed. That's number one. There's a bunch of Asset Manager plug-ins that just blocks CSS and JavaScript files from loading in pages where they're not needed. So that is a great start. That is always a great start. And you saw the two examples, two pages side by side. It's a massive difference. And just killing those CSS and JavaScript files will let the browser interpret and load and show the page to the user much faster. That's a great start. Oh, great questions. Thank you all so much for those questions. Thank you. And a big thank you from WordPress. But I'm told I have to give this to you in the middle of the stage. Come with me.