 So, it was really hard to pick specific topics to talk about here today because web co-vitals and SEO are too massive topic. So I'm just going to give you hints about specific things that are very important, but you'll have to do a lot of Googling on some of these things. Just 30 minutes for this entire presentation, so I won't have time to go into a deep dive into some of these things. So let's just start, okay, so a little bit about me. I'm originally from Trinidad and Tobago. I flew 10,000 kilometers just to be here, I live in Thailand right now. That is my Drupal handle, you might have seen me around the block at some point and I've been using Drupal for 17 years now. I currently work at Salsa doing all of that. I started a kind of new YouTube channel and my plan is to talk more about these specific topics right now, just one video and like 100 views or something, but it's a new channel so hopefully it will get going eventually. Okay, so first let me explain what are the core web vitals for those of you who don't know what it is. These are metrics that Google measure to determine how user-friendly your site is. Once you make your site user-friendly, Google will reward you by ranking you higher given that you have high quality content, of course. Google specifically states that page performance matters, that is a direct quote from Google and here I've literally copy pasted some quick stats from this link here to show you that some of these companies, the bigger companies at least, that improve these metrics had great success in their bottom line and financially. So a website that is user-friendly will rank higher than a competitor's website given that everything else is equal like you have high quality content and so on right. So if you want that competitive edge in terms of search ranking, this is one area that you can improve and I will show you in this presentation how you can improve some of these metrics. So let me just explain what are some of these metrics, right? So the first one is first content for paint and the definition is there at the top of the screen, but I'm just going to read the English version here. So this represents the first point in time when it browse a paint something to the screen. So in the screenshot here you can see this is a mobile version of the Google search and the first content for paint happens on the second one there which is that is the first thing that user actually sees and this is what this metric actually measures and at the bottom you're going to see like the time that this happens is considered good if it is less than 1.8 seconds and you know in the orange section it means that you need to improve it obviously and if you are in a red section you're doing very bad and you should like definitely try to improve this. The second one is largest content for paint. Now I can do an entire presentation on this but what this is is it represents the time taken for the main content of the page to be painted and the page can have different content which can be considered the LCP but is the largest one that is actually considered in the end. So if you look at the screenshot here on the second screenshot on the second image sorry the LCP right now is that text block right and then the page continues loading until you get to the last one then the image pops up and then that becomes the LCP. So then Google recognizes that the actual LCP here is the image at the end right and here at the bottom you can see where you fall and what you need to do if you're depending on good or bad and there are different elements that are considered for LCP. You have image elements, image and SVG video elements and the LCP in this case is the poster image in the video element. You have CSS background images and block level like text elements. So ideally you want your LCP to be a text block. This will help you achieve the fastest LCP if it was a text block. Obviously this kind of will be the case for every single website because it really depends on your design. If your LCP is an image you can improve it by pre-loaded it in the head in the header and optimizing the image size so you can use like WebP, AVIF and responsive image size. The objective here is to make that image as small as possible. In the cases of CSS background images ideally you want to put those directly in the HTML and don't use it as a CSS background image. If that is not possible at least optimize that image and pre-loaded in the header. If your LCP is a text block like for example in the first and the second screenshot there let's assume that was your LCP. You can improve this by if it does use like a custom web font. You can pre-load the web font in the header and even better is if you can you can self-host that web font instead of using an external domain. Better yet you can just use a default web font. Cumulative layer or shift. So this is a cumulative measure of unexpected shifting of page elements. So if we look at this screenshot there when the page first loads it loads this text block and then apparently there's an image that just because it's so big it takes a while to load and then when it loads it pushes everything down. So when you have things shifting around the place this is what CLS measures. The usual suspects for CLS are images without dimensions so in this case if you did not specify a width and a height this is what will happen but if you did specify a width and a height the browser would reserve that space so it will actually start as in the second screenshot there and then the image will eventually load and nothing gets shifted at that point. Another usual suspect is a font. So for example in your primary menu you have a default font and then when you hover over it sometimes you have like a bold version of that font and then the bold version because the font is slightly bigger it shifts so when you hover you see that menu shifts. I don't know if you noticed that before but it is something very small to notice if you have like a fast internet connection but if you did slow your internet connection down it is very much more apparent. Another one is third-party ads or widgets that dynamically resizes on itself so if you have like ads on your page if it's not implemented correctly you know it could be bigger or smaller and shifts are running content a lot and the last one is content injected with JavaScript especially third-party JavaScript. So if you have content in your initial viewport that is loaded from JavaScript that is going to be a very big factor that will affect your CLS and here we have this course so you know where you where you need if you know if you're good or needs improvement and so on. Just by the way there's a link right at the bottom there if you want a deeper dive and understanding of CLS. Okay so first input delay now this represents the time from when the user first interacts with the page to the time that the browser responds to that interaction right. So if you can imagine like sometimes when you click on a web page and then like nothing really happens for like one or two seconds and then something happens that is what we're talking about here. So on this image here if you look at the main thread line so every browser has a main thread which this is what the browser uses to do everything like load the page parse the HTML load JavaScript execute the JavaScript render everything right. Everything happens on this one main thread and in that yellow block the longest yellow block there. Let's assume that that is the time when the browser is actually executing some JavaScript on your site and if the user was to click on something during that time they would have to wait until that JavaScript has finished executing and then the browser will respond. So I will show you how you can improve this. This is a tricky one to improve but I will show you how you can improve it. So here are some ways that you can measure these things. Chrome user experience this measures real world data in the field so this is what your actual users experience using actual devices right. Google page speed if you were to run your website through Google's page speed this is more like a simulated environment and it will give you like tips on how to improve these things but you have to keep in mind that this is a simulation this might not be what your real users are experiencing. So you might see differences between the Chrome user experience report and your page speed insights and you might be like you know scratching your head wondering why is it good here but it's bad there. That is because one is one is actual users data and one is a simulated environment and in Google search console they also they will identify groups of low performance pages for you. So for example if you have like blog articles let's say they use like a one template right. So search console will not identify every single blog article and tell you like this one is bad that one is bad. It will just group all of them and give you like a group score and say like your blog articles has this group's LCP score of blah blah blah right. Another important thing here is Chrome user experience and Google search console aggregates data over a 30-day period and that is updated around every 30 days approximately. So it is not real time in other words. Google does provide a web vitals library and that link that is like a code snippet of how you would use it. You could read more about it at this link at the bottom of the page. Additionally there is supposed to be a YouTube video in the middle here but if you search this video on YouTube this gives a very good breakdown on how to measure your web covitals in real time and set it up using Google Analytics and BigQuery. So if you really want to go deep into this I recommend check this video it is about one hour long but you could get a lot of great insight by watching this. Sorry didn't mean to. So some other important tips there are other metrics that you can't measure such as interaction to next paint, TTFB, total blocking time, start render time, page width and so on. Now I could talk about each one of these separately for very long time but I can't right now but have a Google of these things if you want to learn more about how you can improve each one of these things they are all important. It's important also to remember that metrics evolve over time so what might be apparent or today might not be so apparent like in the years to come. In the beginning we used to talk about like DOM content loading and page load time and so on but you know like these things evolve. You want to set performance budgets you can use these tools here to set up these things in your pipeline so you know that when you have a merge request it you will know like how much it will affect these metrics. You can set that up by using I've used NPM bundle size to do that but there are other tools I haven't actually used all of them but you can have a Google of these ones and you can figure it out I'm sure. I really like web page test.org because this one allows you to run experiments without changing a line of code so on that side you scan it using that side and then let's say you want to simulate how your site would perform by preloading all of your JavaScript for example. It's just a click of a button and it does that for you and you don't have to go back to your developers and ask them to do this. So I really like that one. You want to measure metrics that are important for your site not all metrics will be important for all sites and it can definitely be overwhelming if you start to track in every single thing from the beginning. So you know start with one metric and work your way up and figure it out before like tackling another one unless you have like a big team then go for it. So I can do an entire presentation on everyone here but you want to make sure and take care of all of these things. Please research each one of these individually. They're quite big topics on their own. Web.dev is a great resource if you want to learn about these stuff. I tend to find very useful tips there. There's also Google Search Central YouTube channel which also has a lot of great tips and there's a Google Chrome developers YouTube channel which also is a great resource. Just by the way the font size here is not relevant when I created this talk that is just my lack of graphic design skills but each one is equally important. There's one here advanced aggregation. This is a Drupal module of course. I have a little bit more on that one in a slide coming up. So here the next few slides I will talk about some missed web performance tips that you can just simply implement on your site and just people are just not doing it for some reason. So for example in the first one there let's say you have an image which is above the full but it is low priority. So for example let's say you have a carousel right. The very first image in a carousel is the highest priority of course because that is what the user will see but all the other images are not so important. So you don't want to preload all of those images because you're just wasting precious browser resources doing all of that when your browser could have used that time doing more important things. So in that case you can use this new API it's called fetch priority. Just by the way this only works in Chrome as of now. Other browsers will just ignore this attribute. So here we set a fetch priority of low so we tell any browser we're giving a browser a hint right. We're not actually forcing a browser to do anything at this point. We just given a hint to say load this image but with very low priority because when assets are loaded by a browser it is given a priority. So in the second one you can see here that you can also use it on your JavaScript if you were to preload your JavaScript files. Fetch priority can take values I think it's high and low. I don't think there's a medium. I think it's just high and low for now. You can also use a new script tag and also iframes. So I've just put some examples here of different use cases for this. Okay so when you hit a web page for the very first time then you send a server request right. Then it goes to the server and you know it builds the page and then it sends it back to you. That time that gap time the browser just sits and waits and does absolutely nothing right. So you can use HTTP 103 early hints to utilize that time. So in that gap time what you what can happen is if you did put like your CSS in your link headers and an important JavaScript in your link headers while the browser is just sitting there and waiting it will start downloading those assets right. So then when the page when the page starts loading it already has that stuff preloaded for you. So there's a module called Drupal server push which does this for you. Just just by the way this pushes all CSS and all JavaScript which might not be what you want. There's a patch that's on the way that fixes that. Cloudflare I know for sure will issue HTTP 103 early hints automatically for you if you already have them in your headers. I think maybe other CDNs will do it for you. I'm not sure I haven't used all of the CDNs. So this one is the one that I really like and it's really easy to implement. This can be done at the CSS layer. So what this will do is if you can imagine that pink section is a story class you can set content visibility to auto. So what will happen here and this works for stuff that is lowered on the page. So when if when your page loads this is not initially viewable right. So the browser doesn't actually render this. So this saves on the on the render time here right. So if you have very long page content this is one thing that will help you very much. This input pendant will help with your first input delay. So if you look at the first row here if the if the person clicked on something in the middle of that blue line they will have to wait until the browser finishes whatever task is doing and then respond right. With this implemented if you look at the last line so the blue line the browser is doing something and then the user clicks the browser pauses what is doing responds to the user to the click code whatever and then when that is finished then continues executing that JavaScript task. So you can use this to improve your first input delay and interaction to next paint or IMP. So in the interest of time I'm going to skip the next three slides but I'm just leaving it here for the record and purposes because this is actually very important and a lot of sites do we use CSS background images. So if we do have time I'll come back to this. That's one, two, slowly, three, okay. So HTML is very fast. You want to like put things inside of HTML if you want them to load immediately right. The last point here JavaScript is the fastest way to build a slow website. I'm sorry if there are any JavaScript developers in the audience but what I mean here is like third-party JavaScript, JavaScript injected into the theme. I'm not talking about like react and here are some common mistakes that people usually make. A lot of people lazy load images but if you lazy load images that are in the initial viewport then it has the the opposite effect right. So do not lazy load images that are in the initial viewport. There's a little bit CSS snippet there that you can use if you insert that you can see right away if you have any images that are lazy loaded in your viewport and if you do see that you need to get rid of that lazy loaded on that image. So I don't have time to go into everyone here but I would like the second to last one I would like to talk about that one. So a lot of dribble sites have we use views and filters in your views right and I've come across cases where you know because sites change hands with different developers many times over time people add filters to views and these might not be necessary because it's not used anymore. So look at your views and try to clean them up it will definitely help in improve your page load time and if your view is using the default CSS and HTML but you're not actually using that in your theme to style the page then you can just turn that off. This will reduce the HTML DOM tree. And it might seem like okay I just did all of that work to save one kilobyte but one kilobyte really does matter. Every kilobyte does matter. So some other important metrics that apart from web co vitals there are other important metrics that you can measure such as you know this less hair. Just one thing about carbon footprint. So monitoring your websites CO2 emissions helps you understand its environmental impact and identify ways to reduce your digital carbon footprint. So I will show you how you can measure these. There are individual tools that you can use to measure each one and I've list them out here so we can go to each one measure them and fix them right. For the last one carbon footprint we are developing a tool that measures that one and I'll talk more about that in the next slide. So at Salsa Digital we are developing a Drupal 360 order tool which will go to all of those tests that are just those tools sorry that I just showed you in the previous slide aggregate all of those results for you and give you this report at the end right. So it tracks all of those metrics that I mentioned gives you one report with tips on how to improve these metrics also. Right now it's an alpha tested and here's the example of the tips and you do it yourself sorry to do yourself tips that the report will give you so it gives you like instructions on how to improve your speed SEO accessibility and so on. We have early access of this service if you come across our boot you can give it a try. So please come to our boot and let's talk about Drupal 360 we could give it a scan of your site see how it goes and that's about it. I can take some questions or I can go back to the CSS backer images. Here's a problem with CSS backer images so you can see in this menu here I have all of these CSS backer images loaded right. What happens here is when if you were to load this website on a slow connection and you hover over one of the menu these images there's going to be blank spaces and it's going to populate one by one right which is a very bad experience so in the first solution what I did was combine all of those images into a sprite and then I preloaded that that image sprite at the top give it and give it a fetch priority of low low because it is not immediately needed when you want to use a load the page for the first time when a when a user goes to the page for the first time they're more than likely just going to read the content right. So the browser's preloads kind of will find this image unpreloaded so when you click on a menu the images are already there right. This is a okay solution and it will work but there's an even better solution which is solution number two. So here I've shifted the the image down nearer to the the footer just before the body tag and I'm not preloaded it I've just put it directly in the hml and not displaying it and setting fetch priority to low so what will happen here is the browser will find this image it will load it with a very low priority and then when the browser clicks on the menu the image is already there so I think this solution is slightly better than the first solution. Don't do this if this image is very important for the initial viewport if that is the case solution one is better. So I think that was it for CSS. Okay I could take any question not from Google Analytics this is tracked when when users opt-in from Chrome. Chrome I don't know how actually they track this but Chrome gathers this information from real users so when you go to Google Search Console that is where that data comes not but you can set up your own Google Analytics to track this if you take a look at that YouTube video that I have posted. Google Analytics doesn't actually track these metrics by default not necessarily don't use JavaScript just ideally just pure hml is the fastest right but obviously we don't just use pure hml but if you can just use pure hml that is the fastest that is what you should aim for but it is not always the case yeah if you do use a lot of JavaScript good luck you might want to preload some of that you could preload some of that in your header you can reduce it so cut the ones cut the JavaScript but you do not actually use it and defer it right they always like use an async and defer so every you look at your initial viewport whatever is important for that first initial viewport you preload all of that and you push that directly to the user everything else could wait and just defer that that is probably how you