 I think I'm going to get started. People might still be struggling in. Before I get started, I just wanted to clarify there was a request for people to provide URLs for the websites to analyze that somehow didn't get fully processed in a way that people could actually submit URLs. I probably should have just given you my email address with something to send it to me. So I didn't get a chance to analyze anyone's websites. So I took the WCEU website as my example and we'll look at that. But I see everyone has your laptops out, which is great. I hope during the talk you just start using these tools that I'm talking about. Hopefully the internet will hold up and you can try to check out your own website or whatever website you're trying to work to optimize. So just really quickly, what I'm going to do here is go through just some basic understanding of what I'm talking about when I say blocking and also core web vitals, show of hands in the room, core web vitals, everyone's heard of that? Pretty good, okay, the word has gotten out. And we'll, like I said, try some analysis. I don't think I'm going to try it live, but we'll see how much time we have. And then I'll definitely have some time at the end for Q and A. Besides myself, my colleague Barry is in the room and he is an expert, a real true expert on web performance. I'm a semi-professional. So I might call on him to get the nuances right, I guess. I also have this Slido thing going. So you can QR code that and there's a poll already running and I might swap my screen and change to a different poll at some point and ask you to do it again. Just kind of some questions about the audience, trying to make it a little more interactive than just me standing up here talking the whole time. I'm gonna leave that up just for one more second. All right, so blocking. I did build this talk is stop blocking my thread, but that was mostly just because it was a really catchy name and that's the best way to get your talk accepted. I'm gonna really, I'm gonna expand that a little bit to talk about just blocking as a concept. So not really just thread blocking, it's also gonna be render blocking. So we're talking about the two main sources of blocking in the browser, which are JavaScript and CSS. Other things potentially you could argue are blocking, but we're just gonna focus on those. So why should you fix blocking? It's the same reason that we need to address performance. It's gonna give you better results on your website. This is just a very recent post from Wikipedia about their efforts to improve their, reduce their blocking time and then the results that they got from that. So if you need to make an argument to someone who, in the C-suite, so to speak, someone who pays the bills is deciding what to focus on. A really good argument for focusing on performance is it's gonna improve business results. There's also the sustainability angle, but for this, I think just business results is the main thing. And there's all kinds of data about this out there. People abandon sites when they come and they don't respond. There's just so many options for people on the internet. So if your website isn't a good experience for your visitors, they're not gonna come back, they're not gonna stay there. They're not going to do what it is that you're trying to get them to do. I'm hopeful that we're gonna get some more of these case studies in the WordPress ecosystem. I haven't really seen too many of those. A lot of them are like big companies like Amazon or Wikipedia, but hopefully we'll start to see more as performance is becoming more important to the WordPress community. We'll see more people sort of publishing the results and that'll help sort of build the momentum. By the way, there's a lot of links in this slide deck and I will have a copy of the slides posted up later so you'll be able to download all those. I mean, find them all. Don't feel like you have to capture them all as I whiz through these slides. And I'm just realizing as I said that I don't think I've done that yet. So I'm gonna have to post that up right after the talk. So what typically blocks, what is render blocking? And we're gonna start with render blocking. So the browser renderer is what's building the visual output of the page. It's taking all the HTML and CSS and JavaScript and then rendering out the page. So if you've got JavaScript up in the header, the browser has to kind of wait before it can continue that rendering process and that's why it's called blocking it. It blocks that process from continuing. There are ways with JavaScript to defer it and with CSS, there are also ways to kind of split up your CSS so that you don't have so much of it in the head. But that's gonna be the main focus of this is like how do you figure out what's blocking on your site and then how do you approach reducing that? Yeah. And JavaScript obviously can kind of do anything so that's the important thing to understand that the browser can't just skip over JavaScript because it doesn't really know what's gonna happen. CSS is typically gonna be blocking. If it's up in the head, the browser doesn't know how to lay out the page until it has the CSS. There are some exceptions to that so you can add a media query to CSS and then you'll only get the CSS for your device. And the other thing you can do obviously is try to split up the CSS so that you don't have so much. And of course, if it's inlined, that's going to reduce probably that blocking because it's actually isn't gonna block. It's gonna just be parsed immediately. The part of what's blocking about these things is that it takes another request. The browser has to go out and request this additional resource and then wait for that resource to come back. So what about thread blocking? That's typically JavaScript. The thread in your browser is going to be handling things like user input and if the thread is busy, if the browser's busy processing JavaScript, trying to render the page, whatever the JavaScript is doing, heavy JavaScript, the browser's just gonna pause and you're gonna get that poor interactivity. And you'll see this warning in Lighthouse, reduce unused JavaScript and then you always get this sort of very generic recommendation about just take JavaScript off your site. That's probably good advice, but... There's probably a little more detail that you can get into about exactly what JavaScript and how you could maybe just reduce it without eliminating it entirely. One interesting fact is that when we look at old versions of WordPress, they tend to perform very well, not because WordPress was fast, but because those sites are very, very simple, the people who haven't upgraded, say from WordPress 4.0 and they're just stuck out somewhere in the wild. Besides having tiny images, they also don't really have much JavaScript. The CSS was very minimal at the time. Now we've sort of gotten to this world where everything has gotten much larger and that's created a challenge that we now have to try to address. This is just showing all the JavaScript on a single page, and I think, oh, this was just a test site that I did, but one nice thing they've added recently in Lighthouse is the attribution of sort of where each of those things come from and it's more organized in that way, so you don't have to quite dig in as far to figure out what the source of this is. You can see, oh, this is coming from Tag Manager, this is coming from Analytics or whatever the source of the JavaScript is. Sometimes it's not actually obvious if you've built a site where JavaScript comes from because one piece of JavaScript can inject another piece of JavaScript or you might install a plugin and it fires off lots of different JavaScript tags that you didn't realize it was gonna do. There's a great metric called total blocking time. It's maybe a little misleading because it's a very, very specific measurement, so it has to do with when the page becomes interactive. It's the time between the first Contentful Paint, which is like when the page starts painting and when it becomes interactive, which means that the main thread has sort of paused long enough that it can actually handle user input. So you see like during a load you'll have these kind of long JavaScript tasks that are consuming the browser thread and until all of those complete, the browser is essentially not ready. And so the total blocking time is the sum of all of those, well not exactly, there's like a, it's a sum of all of them that are over 50 milliseconds, that over 50 millisecond time is summed up. So it gives you a really good measure of kind of how much blocking you have going on in your JavaScript and it's definitely something that if you can reduce, you know you're making progress. It's not the only thing to consider but it's definitely a great metric to look at to understand blocking. One other thing I just wanted to say before, I think I skipped one thing before, before I get into the Core Web Vitals, is one of the reasons to really address blocking as a website owner or developer is that it's in your control. There's parts of performance that you actually don't have much control over. If your host is slow, your time to first byte is not gonna be very good. And you could maybe introduce caching or whatever but there's a limitation. You're relying on your host to deliver that HTML fast. But blocking time is all about what you have on your page. So it's in your control, I'm assuming you are website owners or developers and therefore it's up to you to decide what to put on your site. And everything you add to your site, every bit of JavaScript and CSS is going to have some kind of performance impact. So it's a trade off between the features that you're trying to add, the styles that you're trying to add and the performance that you know you need to have. Oh, I think I'm gonna stop this and I'm gonna start the next. This is very professional. I just started another poll. So if you wanna go back to the poll and vote on your knowledge of Core Web Vitals, you can do that. It's the same URL but now there'll be a new poll there. So everyone's other familiar but I'm just gonna do a quick review of Core Web Vitals just so you have the basics again. Three main components, like is the page loading, is it interactive and is it visually stable? And so that's the spinning thing while you're waiting for anything to come to the page. The interactivity is about when the user clicks on something or tries to do something on the page, how quickly does the browser respond to that? And obviously if you've got a lot of JavaScript running and it's consuming the resources of the browser, then the browser won't be unable to respond to user input and that's reflected in that metric. And then visual stability is when things pop in and the page shifts around and that can also sort of be caused by something that's blocking and then eventually it loads and then things change. So those are measured right now with LCP, FID and CLS and like I said, blocking essentially can impact all of these metrics. One important note here is that FID is going to be replaced by a new metric called INP. This was just announced a couple weeks ago. If you've ever looked at the Core Web Vitals for your site, you probably noticed that your FID was great. I think something like 95% of WordPress sites pass Core Web Vitals for the FID metric which sounds good except it doesn't really help you make your site any better. If you're already passing everything, then there's nowhere to go. With the new INP metric, the goal is not to measure the first interaction of the user but all of the interactions over the life of the page. And there's some subtlety there. It's not actually all of them, but that's the general idea. So it's again trying to measure how quickly does the page respond to the user's input and it's gonna be critical to address blocking for this metric. And finally, just a point of clarification about the metrics. There are lab metrics and there are real user metrics or run metrics. So lab metrics is probably mostly what we're gonna be looking at today. That's when you run a report in a tool like Lighthouse or in DevTools and you test the results. And you might try to simulate how a real user would experience this by turning on throttling. Most of these tools have throttling built in where you can simulate being on say a 3G network and a low powered smartphone. But what rum data is is actual data from users in the wilds who have visited your site. And for larger sites, this data is available in the crux user database. And you can actually go query this using BigQuery. For smaller sites, you probably won't be in there. For privacy reasons, it's only available for sites that have enough traffic that the data can be anonymized. But you can collect this data on your own. So we'll talk about it a little bit in the details later, but you can add a script to your site that will collect it or there's actually run providers that will collect it for you. Like service providers, essentially where you pay them. And yeah, I think that's... And I guess the most important thing about this in terms of blocking is that metrics like First Input Delay or the INP that's gonna replace it are really only testable in the wild because you can't really simulate users interacting. I mean, you could try to write something automated, but it's not the same as actual users visiting your site. And of course, how quickly your site responds is gonna depend greatly on the power of the device and the network conditions of the user visiting your site. If there's a lot of latency on the network, each of those requests is gonna take longer. So the more requests you have, the slower it's gonna be. Same thing with devices. A lot of us are, I see, have MacBooks. We tend to have high-powered devices as developers because we wanna get our work done quickly. That doesn't necessarily mean your users are gonna have the same experience that you have. So it's really important if you're working on, especially working on a site and trying to improve the performance of a specific site that you try to collect data from your actual users. It'll help you pinpoint where their problems are. Not the ones that you might see when you test it on, say, a local machine or just in an isolated environment. Okay, I feel like I should pause and ask for questions at this point. Is anyone, is everyone following along? Yes, no one's staring at me wildly. Okay, if you wanna interrupt me, feel free. Just raise your hand and I will, but I will do questions at the end as well. I'm gonna take a pause here and sip some water. This is the WordCamp Europe 2023 website. We're all probably pretty familiar with this. Check in the schedule over and over. So I decided to use this to just run some tests, see if there's anything blocking on this. And yeah, so how do you go about doing that? Well, I mentioned RUM data. We're gonna talk about PageSpeed Insights, which is a great tool. We're gonna talk about the Chrome DevTools performance panels and also how to use them to identify critical CSS. And then lastly, I'm gonna talk about a third-party service called WebPageTest. There are many services out there, so this is not like an exhaustive list. These are just some tools that I like to use and I think are really good, but I'm not promoting them. I'm not telling you this is the best thing to do. I'm just saying, check these out for possible usage. So for the RUM data, there's actually a great site, the CWV tech report, and you can use that to actually see if you're a product developer, if you have a plugin, you can see how your plugin is performing compared to, say, sites that run WordPress that don't have your plugin. And it detects all kinds of technology, so it'll break down the metrics depending on whatever you put into the filter so you can drill down into different things. And they're actually working on an updated version of this that will have even more kind of control. If you are in Search Console, that is a really good way to get data about your Core Web Vitals. So Search Console is what you sign up for with Google Search and they will kind of give you a dashboard that you can see. They even send out email reports, I believe, and they have a section with Core Web Vitals. So that's a really good way to kind of keep track of how your performance is going. I mentioned the Crux data set. There's a whole tutorial that's up that, again, all these links will be available to you at the end, but you can actually build queries against this data yourself and really drill down into what's happening on your site. There's a great extension that the Web Vitals team released called WebVitals.js. You install this on your site and it collects real user data and sends that off to the data repository of your choice, like you can send it to your analytics account or basically anywhere that accepts data as an endpoint. And then, like I mentioned, there are real user metrics or RUM providers. So PageSpeed Insights, pagespeed.web.dev, this is the time that you can, if you haven't already done it, go ahead and pull that up in your browser and type in your URL and we'll see if we can bring down the internet. But run a report on your site if you haven't yet in PageSpeed Insights. And this is the report I ran on the WordCamp Europe site. So the first section up at the top is actually showing you the real user metrics if you have them. So if your site is in the data set, then you will see this section. If not, you just won't be there. And just to point out too, there's mobile and desktop. So those are typically very different in terms of performance, so you definitely need to look at both of those. And then you get down to the lab data, right? So that's what appears right below that. And it's gonna help you diagnose stuff. It's gonna help you figure out. I'm actually not gonna do that one. So the next one is the Chrome DevTools Performance Panel. Is everyone familiar with Chrome DevTools? Who's used that? Okay, pretty good show of hands. So there may be some things you haven't seen in there, but go ahead and bring up your site. You can open another tab if that PageSpeed Insights thing is still running. And open up the performance panel. That's the first one. And then you can try to run a performance test on your site. You can see in the screenshot here this sort of one that's identified in red. You'll actually see the long tasks identified in the kind of main section below the timeline after you record your results. They're actually highlighted in red so that you can see them. And if you haven't done this before, you kind of need to scroll to expand that view. It's gonna kind of start out very, very compacted. But when you scroll, you get this nice view where you can see the task. And then it actually, these sort of green things below there are showing like the call trace. So it shows you which functions were called and that can lead you back to sort of where the problem came from. In addition to the performance tab, there's also a couple other tabs that are really useful. Performance Insights is probably the best. I really love this one. I think it's relatively new or newer. So definitely if you haven't checked that out, there's also a Lighthouse tab and a Recorder tab, which can be very handy. And also just to point out all of these have the throttling features. So you can set your CPU to like a low-powered device and you can throttle your network. And that's gonna be pretty important for this kind of testing because if you run things at the highest speed, you probably won't even catch any of the blocking stuff. In the Performance Insights panel over there, oh, I'm gonna have that in a minute. So Lighthouse is also built in right there and that's gonna give you the kind of overall performance score, but it also has the total blocking time. So you'll see that metric in there just as a way to kind of regularly check what you're doing. Like is your blocking time good? Is it bad? Is it changing? And you'll get in there, in the Details section, you'll get this kind of list of exactly what is consuming the thread. And it can be just evaluating scripts, takes the browser some time. It has to parse the JavaScript before it can even run it. So there's a cost to any JavaScript essentially that you're running. The Performance Insights panel, again, like here you can see I'm throttling to run the test. It has this really nice section you can see over on the right over here. Yeah, okay, cool. Where it's actually showing you each render blocking resource as it's loaded. And if you click on those, they're highlighted back over in the timeline and vice versa, like you can connect them. So this is really a great way to drill down to figure out exactly what it is that's causing blocking in your load process. So again, if you have your browsers open, you can switch to that tab. It's just over there all the way on the right. You might have to scroll over depending on your screen size. And then again, you just click on the record button and it'll run the whole test and then you'll get the results. So check that out. Hope you have a couple tabs open by now. Yeah, and the tasks are highlighted, like I said, in the waterfall and on the sidebar. So you can kind of get a list and then you can also drill down. This is a really useful tool. It's under sources coverage. So it's in the sources panel and then you have to go down to the bottom window and you'll find coverage. And you reload the page with this on and you will get a list of all of the resources that are loaded showing you what is used and what is unused on your page. And this is gonna get to how we fix these problems, right? It's really gonna be about removing the things that are not used. There's no reason to have whatever this is, react, DOM, I think the number's off because it can't possibly be 112%, but clearly like 90% of the JavaScript in that file is not being used. The whole thing has to be loaded and only a tiny bit of it is used. jQuery is a common culprit. Often see websites where they've loaded the entire jQuery library to handle like a single click action or a form submit or Ajax request or something. And back in the day, that was something we definitely needed to do because browsers had so many different incompatibilities that jQuery solved all of our problems. That's no longer true. So jQuery probably could just be removed entirely. And not only that, but there's also load-ash which is like a jQuery replacement just right next to jQuery. So there's a lot of extra JavaScript going on on this page and that's really not helping with the performance. And also CSS, it shows CSS as well. So you can see which CSS files are causing, are including, this is actually not showing which are blocking, but it's showing you sort of what's being included that you don't need. Okay, and finally, webpage test. So this, yeah, question. No, I don't think there is a way. I mean, I think like with load-ash, they made that possible. I think probably with jQuery, if you really need some functionality in there, I would, my recommendation would be just to go take that code out of the jQuery library and put it in your JavaScript file because that stuff has not changed in years. It's not like you need the library to be updated or you're gonna fail to get some security update. Typically you're talking about one function will be like 20 lines of JavaScript or something that checks some condition and that does something in one browser and something in another browser. I hope that makes sense. I guess it would depend, yeah. Yeah, right, right. That's a good question. I don't know of a tool that kind of does that for you but I guess I would say like, if you have a gallery on one page, the CSS for that should not be on the home page. So it really should only be present on the page that has the gallery. So I wouldn't think you would remove it from the home page because it wouldn't be there in the first place. Okay, excellent, thank you. On Lighthouse, okay. Web page test. So this is a third-party service. I think it's free to use. They definitely have a paid version that I pay for that seems to be worth my money but if you haven't tested it out, I think it's webpagetest.org if I'm not mistaken. I don't have the URL up but try that out, load it up in another tab in your browser. I'm gonna see how many tabs I can get you guys to open today and put your site URL in and just do the initial, like just accept all the defaults but you will notice as you do it that they offer quite a bit of different options for how you run the tests. For example, they allow you to test them from different geo locations, all the different devices that they simulate and that kind of thing and the network throttling. Another really nice thing about this tool is that it saves all of the tests into your account so you're logged in so you can go back and look at previous tests. You can also compare two tests so you can have a test, make some changes and then do a comparison. It's got a great waterfall and what the waterfall is showing you is the sequence of events happening in the browser as they are loaded, right? So this is sort of like the history of the load represented visually and it does go on and on. So there's quite a bit to look at but it will help you figure out again sort of what is taking so much time before you're getting to the page being rendered. And I'm sure there's something to their color coding but I don't know what it is off-hand. I think, oh, there's long tasks. You can see the long tasks are highlighted at the bottom. So we're gonna get on to the fixing part. Any questions? So by now you probably are alarmed at how much extra JavaScript and CSS you have on your website and how much blocking is going on and you're like, how can I fix this? And I think what Lighthouse tells you is you should install an optimization plugin. And I'm not gonna tell you that's a bad idea. That's actually probably a really good idea in WordPress at this point. Optimization plugins are great. I highly recommend you have one optimization plugin. You don't need two or three. They don't stack. And just to be clear, there are kind of page caching solutions. That's not optimization. It is optimizing for performance but what I'm talking about is plugins that will actually sort of alter your page after it's been generated. So they're trying to maybe do critical CSS or they're defying JavaScript. They typically give you a lot of control over those things. And when I say control, I mean literally like options in their control, in their dashboards where you can try different things out. Oh, I should say, I missed that on the webpage test. One other thing I really like about webpage test is their, oh, maybe that's just in this section. They have an experiment feature which does just that, where you can test out different ideas for how to optimize and then run the test with those. And it's sort of on the fly modifies the HTML. I think actually do have that in here. So I've got a magic wand here and that is, there is not a magic wand so just erase that from your memory. But there are some things that we can do to make things load faster. I mentioned optimization plugins. Another thing that I like to, that I think is exciting is switching from using plugins for everything to instead using block plugins. So if you're not familiar with block plugins, if you are in Gutenberg and you type, and you go to insert a block and you type the name of a block that does not exist as a default block in Gutenberg, it will go out to the block plugin directory and do a search for you. So, and then it will install it directly into Gutenberg. There is no separate install screen or anything. And these plugins are quite limited in terms of how they work and they have to be primarily JavaScript and they tend to be very isolated in their features. One of the issues that we have in our ecosystem with performance is that our plugins tend to have many, many features in them. And similar to the jQuery example, we don't really tend to use all those. So I really like to pick on the form plugins. I don't know why. But it's a good example where I just wanna have a contact form on my website. Just a simple place where people can put their name, their email address, a little comment and click a button. And so I install plugin X for my website but that doesn't just come with that. It comes with a multi-path option where you can have multiple pages and you can upload images and there's an embedded map. And it has all these features that I really don't need and will never use. And that's kind of the way our plugin ecosystem has grown up because the plugins are kind of competing with each other and they tend to compete on features. Block plugins, on the other hand, tend to be very single purpose. And at this point at least, tend to be a lot smaller in terms of their impact. So I really encourage you to think about, if you look at your website, to think about what functionality you have, what plugins you have, and maybe what you could remove. Maybe you can disable some of those or literally remove those plugins from your site and instead just use a block that does the same thing. The contact form would be a good example of that. I have a deferring of scripts here. So this is something that optimization plugins will do but if you are like a plugin developer or a theme developer, this is something you need to do on your own. And this is a way of enqueuing JavaScript that will not block. So it tells the browser, you can delay the actual processing for this script until after everything else has been done. And that's the kind of defer. There's also async, which is a slightly different approach, but in general, both of them will let the browser kind of get to other things first. Yeah, and the webpage test experiments, this is what I was talking about before. So you can actually, with webpage tests, you don't actually need to modify your website at all. You can just tell it, I want to experiment with deferring these scripts, try deferring all the scripts. Let's see how that does. And it will sort of reload the test and kind of modify the HTML of the site on the fly. And it has a whole bunch of tests built in like that are just kind of good ideas to test out based on what failed on your site. But you can also write like custom tests where you have it manipulate specific things. So it also, once you do the test, it gives you this nice comparison. So this is just to show you like, I did very quickly ran the work MPU site through and I had it kind of do the move all the CSS to being inline and defer all the JavaScript. So this might have broken something like I didn't actually test to see if that was a great approach. I think it does a couple of other things with CSS, maybe even does like critical CSS. But you can see like already pretty much everything got better. The total blocking time actually got worse. And I'm not sure why I didn't dig into that. But that is something that happens often with performance is you can perform, you will improve one metric and it'll have a negative consequence on another metric. There's sometimes unexpected results like that. But it gives you this nice view. You can actually see like the film strip, you can run them against each other. So you can actually see what's happening. Strategies for CSS, inlining is a great approach. But you don't wanna go overboard with that. Again, there is the flip side of that where you're increasing the page weight. So the overall page weight is increased. We have an example right now in WordPress Core where there's a little bit of CSS that was added to accommodate the button block and it was added back to all of the classic themes and it basically added an additional request to every classic theme page. And it's only like, I don't know, eight lines of CSS. So instead we're switching to inlining it. And it'll have a very marginal impact on performance but when you multiply that by all of the sites in the world it actually adds up. And that additional request, there is a cost to that as well. There's an environmental cost because that data has to be sent across the network and there's a cost to that. In addition to using blocks instead of plugins or block plugins instead of classic plugins we have a new system of theming called block themes. Who has heard of block themes? Yeah, so 2023 the theme that was included the last kind of official core theme is a block theme. And the major sort of technical difference or the performance impacting technical difference I guess between classic themes and block themes is that classic themes are kind of output all at once top to bottom. The PHP is rendered, we start at the top we output everything and then we finish. With block themes we actually parse through the content once first and then we do the render. And what that allows us to do is to know what is on the page before we start rendering. And that we're outputting I should say, the webpage and that allows us to for example only include the CSS for the blocks that are on the page. So in a typical classic theme you need to have, typically you have one CSS bundle that includes the CSS for everything on your entire site. So you can already guess that that's gonna be way bigger than you need for most of your site because most of the time you're not using everything on every page. With a block theme that's no longer true the CSS for each block can be inlined only when that block is present. So it's just another strategy that it doesn't actually require that much work for you even you have to, yeah thank you. You do have to make a switch. Obviously switching themes is not super easy but like if you are thinking about redesigning your site and it's time for a new theme definitely look at a block theme because of the performance advantage that's gonna give you. Yeah, right so that's true. Like you're including that extra overhead in each page load versus if it's an external resource and people are navigating around your site it might actually be cached, right? So that might not actually require that additional request. And I guess that depends to some degree on what your website traffic looks like. For a lot of websites they get one page view is like the primary thing that they get and then maybe a small number of secondary or third navigations. So if that's the case then the caching wouldn't come into play. But there is like I said there's a trade off there. You're increasing the page size. There's, yeah, so there's a trade off. So I talked about this briefly but the coverage tab again is to show you exactly where it is. Oh, I did have a screenshot. It's under sources and then you have to kind of find coverage down kind of by the console in that lower window. So if you didn't get to do this before open another tab and try this out on your website this is what's gonna tell you what is being used or not used on the site. And the stuff that's not used very conveniently as shown in red. So what do you do with the CSS that isn't critical? Like so what that helps you do is identify what your critical CSS is and critical CSS, okay, let's see. Show of hands, who knows what critical CSS is? Okay, pretty good. So critical CSS is essentially the CSS that's needed to render the initial viewport, right? So that wouldn't include things like something that was in your footer that's not gonna be visible to people. You don't really need that to load initially. And certainly it's not gonna include things that aren't on the page. We do a filter in core for preloading which is another way that you can kind of get the browser to find out about a resource that it needs earlier. So a good example of that is like something that's referenced in a CSS file. Like a font that the browser's gonna have to go download. If you tell the browser to download that with the preload directive, it will kind of start fetching that earlier so that by the time the CSS has been processed, it already has the font available. There's a great plugin if you do have secondary navigations on your site called Quick Link. And what this will do is use sort of prefetch to actually, if people hover over a link, it will go out and prefetch that page. And there's some customizability in terms of exactly how you want it to behave. And also there's certain URLs you might wanna exclude like a login page or something like that. But essentially, if you do have a site where people are gonna say you're selling products and they're gonna navigate to the product page from the homepage, you can make those pages appear almost instantly by using a plugin like this. And some of the optimization plugins also include this type of technology but this is a standalone plugin. So there's a lot to addressing JavaScript thread blocking and I'm not gonna get to go through all of it. But I will, like I said, I will share all these links at the end and you'll be able to kind of go work through it on your own. I put a link here to the recent issue that came up in WordPress Core which is about the emoji script that's loaded on every page. And we recently rediscovered that that's causing like 100 milliseconds of blocking for every WordPress page that's loaded and we don't even cache that so if you visit multiple pages on the same site with the same browser, we test every single time. So my colleague Weston opened a PR that will actually move that off into a worker thread and no longer block the main thread as well as caching the information in session storage so that we only do it once per session. This is a pretty low hanging fruit. Hopefully it's gonna reduce everyone's blocking time. But this is an example of something that can just be sitting there and unless you really spend the time to dig in and try to figure out what's going on in your site, you'll never really know it. And it's hurting everything on your site. So yeah, third-party JavaScript is a huge issue and when we say third-party JavaScript, this is JavaScript that's coming in from other sources like an ad tag or analytics tag or a commenting script or anything that you're learning from a third-party, not from your own website, tends to be an issue and something that you probably need to look at. Yeah, and each of these points here like debouncing your input handlers, this applies mostly to coding if you're writing like your own plugin, you're gonna wanna make sure that your input handlers are thread-friendly by debouncing them which basically just means kind of giving some room for the main thread to do work while you're also listening for events. Web workers is again an approach of taking some of the work that your JavaScript is doing and moving that off into a process that doesn't block the main thread. We talked about CSS already. With JavaScript, with modern JavaScript, if you're writing your own JavaScript, there are great ways now to split up JavaScript, all the browsers support module loading so you don't need a monolithic file anymore. A few years ago, we were recommending, maybe it was more than a few, we were recommending that you can catenate all your files into one because it was a high cost, there was like an overhead of making many requests. That's really not true anymore or the trade-off is not there anymore, I guess. So it's actually better to sort of split things up into a small chunk as you might actually use on the page. If you're a developer building JavaScript, make sure that you're splitting that up into the usable parts, I've got five minutes left. Oh my God, tree map, okay, this is really cool. I love this view in Lighthouse, I just wanted to show, it just again, this is more of an analysis tool, but it kind of gives you the picture of the scope of the problem. The size of the box represents the size of the element that's being reported on. All right, so we did get to the end in all the time, that is awesome. So I think we kind of did this along the way, so I don't think we need to go through it now, but basically, yeah, I mean, to analyze your site, you're gonna use these tools, you're gonna try to drill down, figure out what the source of the problem is, and then if it's a plugin, try to figure out, I mean, if you're a site owner, it's probably gonna be a plugin. Try to figure out how you can get rid of that plugin and replace it with something leaner. It's probably gonna be my number one recommendation there. And try the webpage test experiments. That will give you a really quick idea of whether you're gonna be able to make some real headway with your site by changing things. All right, I did create some demo sites for people to check out. I did not get a chance to get to them, but on these like two InstaWP sites and also on this GitHub repo, on the GitHub repo I created a bunch of kind of extreme examples, I guess I would say, of blocking where a site just inquires a zillion JavaScript so you can really just see how bad things can get. And there's like eight demo pages on there, which I will not have time to go through. I did look at some other sites. Sometimes you see surprising results like this where in the wild, you'll get a really good Core Web Vital Report. Oh, it actually didn't show the second one. Sometimes what you see in the wild does not match what you see in the labs was kind of the point of this, but I think, oh yeah, there it is. That's the performance when I read it through the lab test and the RUM score says the site is great. All right, given that I only have five minutes left, I am not gonna show all these examples. I think I'm just going to take questions. Yes, so I'm gonna leave this up for like the takeaways for like what I hoped you got out of the workshop and I would like to have a little bit of time for some questions, so. Questions? Yes. Thank you very much. I think everyone in this room found new tools and new techniques to optimize the websites. There were very good tools and techniques. But I think, as you mentioned, this is becoming more and more larger and as a web developer agency, clients are asking more tracking, more videos, more sliders, more forms, recaptures, et cetera. So what's the best moment to say stop? Because it doesn't matter how well you optimize, at some point you need to say no. So what's the good transfer for this? Thank you. Yeah, so I think that gets back to what is the business argument for this, right? You have to ask them the question, why do you want these videos there? And they probably want the videos there because they wanna sell more of their product. And they think that if they have a big, huge, pretty video, that's gonna help them sell the product. And so you have to make the argument that that's a trade-off, that they're gonna lose some people because that's gonna negatively impact the performance of the site, that people are not gonna have a good experience, they're gonna be sitting there waiting for the video to load, and they're gonna abandon the site because of that. So that's the argument, in terms of how you actually prove that, I think probably trying to collect some data, doing A-B testing, hopefully your site is tracking some metric that's your success metric. Try it with the video, try it without the video. Yep. Yeah. Oh yeah, thanks. Thank you. Thanks for the great talk. And I was wondering, you didn't say something about early hints pre-loading. Can you talk a little bit about that? Sure. And this is where Barry might be really helpful if you wanna chime in. If I say anything wrong, how about that? And there's actually, early hints, there's actually several different components to it. So there's like the prefetch, I think is that considered part of early hints too? Resources. Okay. So early hints is mainly about telling the browser earlier than it would otherwise discover resources that it's going to need to render the page. So I gave the example of a font, another example might be a background image that's referenced at the end of a long CSS file. So you can imagine the browser first has to go get the CSS file, then process the CSS file, then it sees, oh now there's an image I need to get, then it has to go get the image. If you put that image URL in the preload resources, the browser will know it needs to go get that even before it starts downloading the CSS file. Does that make sense? That's, oh but how to do it, you mean? Like are you asking how you would add that into your site? What is your recommendation to do this in WordPress? Because they're not always, I think the CSS file for all the black, the blocks would be a good example for preloading, but you don't necessarily know if it is loaded because we have classic themes, we have block themes, full-time editing, so it looks like something we only could do on an individual. I think so, I don't think it's something you can easily automate. And it isn't always predictable what the results, it's not like we could just preload everything. If you prioritize everything, nothing is a priority, so it's something that you have to fine-tune. I think you really do have to do it manually, you have to experiment with it. Is this helpful? And then run the test again, try adding it to the preload. But I think there are some things that are like obviously should be preloaded like the examples that I gave. So if you're building a theme you would know, like I should probably preload these. Anything to add, Barry? Also don't overuse it, the browser's very clever. So if you've got the CSS being delivered in the HTML, you'll find that there's no need to preload it. And people who preload it tend to preload version one.css, they upgrade to version two, they forget to upgrade to preload hint and you're now downloading two bits CSS. So preload and some of those extra fetching is more about things the browser can't discover. So a background image in a CSS file, you have to download a CSS file, find the background image and then, oh, I need that as well, so you can preload that. But fonts, again, same reason. So try and use it for things, they are hints to the browser, they're extra nudges. It shouldn't replace things it's gonna find anyway very quickly. So if I didn't make it clear before, we worked on the Chrome team, so we're very, very invested in trying to make the browser as performant as possible. And the browser is really smart about optimizing things, but there is a certain element of, it's up to developers, it's up to site owners to decide what to put on their sites and there's nothing you can do when that gets too bloated. Just the link up there, if it doesn't work, I'll make it work within the next half hour, but it's a bitly link that will have like a PDF of this slide deck so you can get all the links and go back through them and everything, so take a photo of that and you'll have a way to get to the slides. Thanks, everyone.