 So in this talk, I'm going to talk about improving web covitals with Drupal. I did other research online before this presentation, and there's a great deal of material online about web covitals. And obviously there's a great deal of material on Drupal, but I didn't really find these two topics in one. So it took me quite a while to come up with certain things. And most of the stuff that I'm going to tell you today are stuff that I have just implemented myself on various projects. And I thought I would share some of these tips because it has proven to actually improve the web covitals metrics over the course of time. So just a little bit about me. I'm originally from Trinidad, Antibago, although these days I'm based in Thailand. I have been using Drupal for about 17 years now. If you want to find me on Drupal.org, my handle is X amount. There's also, if you need to contact me, there's a contact form there as well. I've been working at Salsa since July 2022 as a Drupal training and documentation specialist and senior Drupal engineer. So I do some training around GovCMS and some dev work as well. I'm also really into SEO and web covitals because I like to see how you can implement one little change and it can have a massive impact on thousands, even millions of people. To me, that is a very exciting thing. So I'm really excited about these kinds of stuff. And I kind of just started a YouTube channel about Drupal on SEO. It's about less than one year old. I only posted one video so far. I was like about 100 views, but my plan is to put more videos there in the future. And this picture was from DrupalCon in Washington DC in 2009. Obviously, you know, the guy in the picture is not talking about me, but the other guy there is Dries, he's the creator of Drupal. Your hair color. All right. Well, that was because I knew I was going to work for Salsa back in 2009, so I'm kidding. So at that point in time, I was still living in Trinidad and Tobago and just the week before this conference, there was carnival in Trinidad. And I played carnival and I had like a red costume and everything. And then like the day right after it finished, I flew to Washington. So I was really hungover in this picture actually and my hair was all red still from the carnival event. So that was why that explains redness there. Okay. So here are some metrics that people tend to measure. So I'm going to assume that you know what these metrics mean. Even if you don't know what it means, you can go to that web dev link there. And it will give you a very detailed explanation about each one of these things. There's not enough time for me in this presentation to for me to explain what each one of these metrics mean, right, even though I would really love to go into detail here but I just won't have enough time. So, as I was saying in the beginning, it took me quite a while to come up with a suitable name for this presentation because you could ask Suji like she keep asking me. So what do you want to name it and I was like, what I want to talk about LCP and I also want to talk about CLS and, and then I just decided to name it Web Covitas and Drupal because I couldn't decide on a specific name at the end. So, apart from, so the ones you see at the top LCP FID CLS, these are the Web Covitas that Google suggests that you improve because they will ultimately affect your SEO and your page rankings, right, and how it does the page rankings. It's not the only factor that affects your page rankings, it's just one of the factors right now. There are other metrics that you can measure like INP, which is interaction to next page, which is a kind of new ish metric. And that one is like, well, that measures like when you click on some after your page is already loaded and you click on a button, and then something happens like you expand the menu or something. So fast that, that, that responses that is what INP measures right. And there's, there's others like TTFB and TBT, start render, page size, image weight, your long tasks, JS weights, CSS weights, you can Google each one of these to see exactly what they mean. And the important thing is like metrics evolve over time. So back in the early days we were measuring like dumb content loaded and page load and these things and then now we have LCP FID and in the future we have NIP. So these things evolve over time right. Ideally you would want to set performance budgets, right, so let's say, and you can implement performance budgets in your pipelines right so if you were to create an MR, it can tell you like okay, if you were to merge this, it would increase your LCP on these pages by this amount, or your FID by this amount or whatever right, or even it would increase your image weights or your JavaScript weights by this amount. So if you set budgets and you set them correctly, it can be really helpful in your project overall. And I have some, some links there about different ways that you can set budgets. So you can have a look at each one of those. When you have some time it will give you much more detailed explanation how to set it up correctly. Also you want to make sure that you measure metrics that are meaningful for your site right so not everything is going to be applicable to all sites. It can definitely be overwhelming. If you were to start tracking everything and then try to improve everything at the same time don't try that because you will just be like super stressed out. So just pick a metric, maybe start with the web core vitals, pick one and try to improve that and then you know when you make some headway, you will realize that as you improve one, you might also improve another one. Or you might also make another one worse right because sometimes something has to yield for one to be better. So pick one and then you know work your way up to the others. Also those links there. I really like web page test.org because that one specifically. I'm not sure if the others do it but I know this one does it allows you to run experiments on the flying so you can run experiments. Let's say like you want to pre connect to external domains without having to change a line of code and then you can see what difference it would make. That is called experiments in web page test. So you can check that out. Ideally you should take care of all of these things. These are some of the easy stuff that you can implement doesn't take. Well, some of it doesn't take much time. Some of it might take some time but these are what I would consider like the lower hung fruit right and I could spend like an entire presentation talking about each one of these things here. Right. Just by the way the font size and the star cloud has no meaning so let's say like pre connect has the biggest font it doesn't mean that pre connect is the most important one right. So just disregard the font size for now each one is equally important. Please research each one of these individually, you can find a ton of information online and how to correctly implement these things. I like to use web.dev. So if you were to take each of these terms and search it on web.dev, it will tell you like the most optimal way that you can implement this on your website. Also on web.dev I tend to find many other like useful tips there also it's a really great resource so I highly recommend you check it out. There's also a Google search central YouTube channel and which is where Google posts like SEO talks and latest trends in the industry and so on. So I highly recommend you check that out when you have some time as well. And there's also a Google Chrome developers YouTube channel where they talk about like latest developments in the Chrome web browser and latest latest API is that you can use that other browsers probably haven't implemented as yet. I tend to get a lot of like good resource material and tips from there as well. So the next few slides I'm going to talk about some web performance tips in 2023 that more sites do not implement as yet but it is so easy to implement and it is already available right. The first one is priority hints. So here I have some code on different ways that you can implement this. So the important part is where you see fresh priority right and just by the way, this only works in Chrome, as of now, but it's an experimental API, and it will probably be rolled out to the other browsers but as of right now, it works in Chrome. So what this does it, every every asset on your site has a priority, your browser determines what that priority is. Priority hints is not, is not directly tell any browser what a priority should be is just given a hint of what you would like priority to be right. So an example like in the first one there, if you have an above default image by default the browser would probably give it a high priority because it's in the viewport. But let's say you wanted that image for some reason to not have a priority of high, this is how you would set it to low. The example of that might be like, you have a car or so in your viewport right the initial viewport, the very first image should be high priority, but all the subsequent images should be low priority because they are not actually viewable until user slides across right. So you can use fetch priority here to set just the first image high, and then all the other images to low, right. You can use it on scripts and non as any second line of code there as well. And you can also use it on iFrames as well. So have a Google of fetch priority, and you can find some information on web.dev on on different use cases on how you can implement this. I have an example later on where I will show you how I implement this. So this is HTTP 103 early hints, right. So, just to explain what this is when the, when you first load a page, you send a request to the server, and then your browser just sits there and waits for like one or two seconds and it does nothing right. At that time this is called the server think time during that time, you know, the server builds the page, and then runs queries into the base or whatever and then sends the page back right and that takes about sometimes one or two seconds. And then your browser starts parsing the page, finding the CSS finding the JavaScript starts loading images or whatever right. So the early hints is, is what the server can send during that server think time right and these are like link headers. So while the browser, sorry, why the servers doing all that processing. You can send these hints to tell the server to tell your browser start downloading these assets immediately because you will need them. So usually you will put like CSS in there because CSS is render blocking, and you need that for sure. Right, you could also put JavaScript in there, or even images in there as well. But don't go too crazy on this because you only want to load the things that are critical for the initial viewport so those these will be like CSS, any JavaScript that is needed in the initial viewport not all JavaScript is needed in the initial viewport and especially images that are needed in the initial viewport like any like your logo could be a good example or anything way your menu is your menu uses images right. There's a module called triple simple push. You can check it out. And it is not like it is okay to use, but you have to be careful when using it because it pushes all your CSS and all your JavaScript, right. And there I did open issue an issue queue for server push to just only push to CSS and give the user the option to give the side administrator the option to push JavaScript or not because on some sites, especially the ones that I was working on. I don't want to push all the JavaScript because I deferred a lot of my JavaScript on one site, especially, and server push was just pushing everything right. But these JavaScript or like analytics JavaScript, Microsoft Clarity JavaScript and add to any JavaScript. These are like not critical JavaScript so there was no need for me to push all these things right. When you push all these things that are not critical the server spends time downloading all these non critical assets, when it could have been building out that initial viewport and doing much more critical stuff. So you take away time from something important to do something else, which is not so important right. So this is just something that you need to be careful when use this module. Cloudflare CDN and probably other CDNs I'm not sure, but I know for sure cloudface CDNs will issue it to be 103 early hints for you automatically, and it will grab those from your link headers. Right. So if you did use Drupal server push, then your CSS and as of right now all the JavaScript will be included in your link headers. And if you are using Cloudflare, Cloudflare will use all of those JavaScript and CSS as early hints and I will do that for you automatically. There's a link how Cloudflare implements it should be early hints. So if you were to just Google Cloudflare, it should be 103 early hints you will find that link and they will explain in great detail how they have implemented it but I just gave you the summary of how they did it there So basically they will just take your link headers, cash it in a special cash and then on a subsequent user, they will send those assets immediately while your page is still building. And then when your page is actually finished built, they will compare what is the CSS and the JavaScript what is in the actual page and if it hasn't been updated. And then there's nothing to do it just keeps loading that has been updated, they will, I guess, set something in their cash to update the CSS in the early hints cash. I probably didn't give like the best explanation there but I think it's much better if you just go it and read that Cloudflare page. They will tell you exactly how they implement that. So, another one that I really like and this is a really easy one to implement is using CSS content visibility. Right. This can be done at the CSS layer so if you look on the image in the middle there will do image on the left sorry that whole pink section. So, let's say that that class was dot story right. So, if you set content visibility on that section, then when and that, and ideally this works for sections that are lowered on the page right. So, what the browser will do is it will load the entire page and that block that that story block will just not render until the user scrolls down. So, that that part then it starts all then the browser actually renders it and does the work to render it right. And you can apply that this this works when you apply it to like sections lower down on your page like the footer or any body part that is lowered on the page. And it's a really easy thing to implement. And this will greatly reduce your, your render time for the page right. So, the browser doesn't know how high that block should be. So there's a there's an additional CSS set and I think it's called intrinsic value something that you can set. That will estimate that you can set which is actual height, like, let's say 500 pixels or whatever. The browser will just reserve 500 pixels and it will just be blank. And then when you get to that, it will actually render it. And whatever new height it takes that says more than 500, it will just take that new height and it will disregard the 500. But the reason for including the default of 500 is so that the scroll bar doesn't, you know, get that kind of like junky kind of effect. I need more about what I just said there go to that URL that you see that web.dev URL and it will give you a very detailed explanation on how to implement this correctly. But I really like this one because it's so easy to implement and it really greatly helps with reducing page render time. Another one is optimizing long tasks. So there's a new API call is input pendant and yield, right. So, as it says there, if you use it, if you use these two in combination is a great way to get the browser to stop whatever tasks it is processing so that it can respond to some user input, right. So in the first, the first line first blue line there, there's a long task. And let's say in the middle of that blue line, the user clicked on something right. What happens is the user didn't pay the browser has to wait for this task to finish, then whatever the user clicked on will be activated right. And if you look at the last line now, if you implemented this correctly. At the time the user clicks, the browser will pause the task and process the click. And then when that is finished, it will just continue from where it left off. Right. And this gives the user a much more faster like response. Right. So this will improve your I am P your interaction to next paint. Right. And it gives the user that, you know, this website is really, really responsive. Right. So you can have a look at that URL, which will explain in great detail on how to mend this correctly. And it's a quite a long page actually. Okay, so here's where I will CSS I'll talk about CSS background images because this is a special case and a lot of sites use CSS background images. Let me use a real life example here. This is a website of mine that I built and maintain and score class of X dot com right and the problem here is their menu icons. So when you when you click on one in the menu, you get a drop down and each one of those images as a separate CSS background image and it comes from CSS. And it is not discoverable because CSS background image is actually not discoverable by the browser until the browser knows that it needs it. And that is when the user expands the menu. Right. So the effect it has, especially on slow connections is if you want a slow connection and you expand the menu, there'll be all this white space. And then the images will start loading and will start populating one by one, and it gives a kind of like, it gives a kind of like feeling like this website is kind of slow right because the images are still loading even if you did it if you clicked on the button like five minutes later. Right. So the browser's preload scanner will not load images until it knows it needs it. And this is especially true for CSS background images so I will tell you how I solve this problem right. So the solution number one is, first of all, I took all of the images and I made it into one CSS sprite so that instead of loading like 15 small images, I'm just loading one image right that was the first thing that I did. And then I put, I said a preload on that image in the head of the page, and it said the fetch priority to load so I'm using the party hints here, because I wanted to load. I wanted to be a high priority because it's not critical right because when you load when you go to the page for the first time. The first thing you do is you're going to read the article on a page you're not going to expand the menu right the majority of the users, which is continue browsing down and reading the actual material. This is why I said the fetch priority to load right so that the browser can okay I need this image to load at some point. So the browser can discover the image now, right, even though the image is still in CSS. So the browser's browser's preloads kind of will find and load this image. This is fine for images in the initial viewport. Anything in the initial viewport should be considered to be critical. So for most CSS background images. This solution will work and you can just leave it here. But I am. There is a better solution preloaded preloaded CSS background images that are part of the LCP should have fetch priority set to high. Better yet, don't use it as a CSS background image. Just put the image directly into the HTML, if you can, right. So now I'm going to show you solution to which is a slightly better solution than solution one. So, instead of preloading it, because I have determined that this image is not critical. I'm just loading it near to the bottom of the page, and I'm not displaying it, and I'm setting fetch priority to low. So what this achieves is that when the browser pauses HTML and gets to the bottom of the page is going to find this image. It's not going to display it because I said style there, right, and it's going to load this image at a very low priority so it's going to do all the important stuff first and then load this image later. If you click on the menu, the image is already there and I'm waiting, right. So why put this in the HTML is because the browser preloads kind of will find this image. If you put it directly in the HTML anything you put directly in the HTML the browser will find that this works in this specific case because this image is not critical. So if this image is critical, you're better off doing solution one, right, which is just preloading it in the header, and if it's absolutely critical you set fetch priority to high. So, so your logo, for example, right. So, your browser's preload scanner will find and load all like your source attributes in the HTML, including poster images in video, which is a kind of neat feature. So if you have a video, you can put a poster image which is like a thumbnail version before the user actually plays the video. And the browser will preload all of these things for you automatically. If you want your assets discoverable in the fastest possible way, put them directly in the HTML and avoid loading them from CSS and JavaScript. And that is the most optimal way to load them. The HTML is super fast and JavaScript is the fastest way to build a slow website, because every website has JavaScript. We all love JavaScript, but you know JavaScript is something that it just loads later on the pipeline and it makes the website a bit slow, right. So, I'm going to just talk about some common mistakes that a lot of sites make. One is that we tend to lazy load everything, all images, right, especially images that are considered for the LCP last largest content for paint. If your image is in the viewport, you should not lazy load that image, right. Because what will happen is the browser will load everything. And then you, it sees lazy load and set to lazy and then it loads that like load on the pipeline. And then you kind of scratch your head wondering, but why is this image the LCP and why is the LCP so bad. It's because you probably lazy loaded lazy loaded that image right so lazy load every other image except images in the viewport. And there's a quick CSS trick if you apply that CSS, it will and you look at your page. If you see like a blue border in the viewport of any image. That means that you're lazy load an image in the viewport and you should try not to do that. Another common mistake is sites tend to preload and preconnect to everything, right. So if you, if you preload all your images and preload all the JavaScript and all your CSS, you prioritize everything, right. But then nothing, if you prioritize everything and nothing is prioritized at the end of the day, right. So only preload preconnect to critical resources. And I'm highlighting only word critical here because critical here means, if it's in the initial viewport, then you should preload it if it's not absolutely necessary, and it's not concerned with initial viewport for example analytics code, then you should not preload it So we tend to use the advanced a gg module advanced acquisition module, and there's an option to set pre connects to external domains. And if you check that box it will find any external libraries that you use and just pre connect to every one of them. I like to turn this off because I like to customize exactly what I pre connect to because not everything that you want to pre connect to is critical for the initial viewport right. So I look at a page and I look at the initial people and I determine what is critical and I just connected though I pre connect and preload those resources only. I think it's hard for the advanced artificial module to determine what is in the initial viewport, and it just basically pre connects to everything. I've seen some sites in line all CSS. Don't do that because it defeats, like all your cash in and your CS CDNs if you use it. So if you hit one page with all your CSS in line. If you hit a second page, then the process still has to like load all of CSS again there's not any cash right. Don't use complex CSS. So try to keep your CSS trees small right if you can target a direct class or ID, then just do that, don't like you know keep nesting nesting nesting three four layers down because the browser has to calculate all of these things. And this increases the render time of your page. So keep your CSS really small and tidy as much as possible in your views. Views tend to input default HTML and CSS in your page right so or in your view block. If you're not using the default HTML. For example this would be like add an autumn even two rows or add in like default HTML for fields and so on right. If you're not using these things, and you're not actually using in your CSS, then it's not needed and if you remove it is going to reduce your total like HTML payload at the end of the day. So, you can disable those things, especially removing like removing I've seen sites where they have fields and filters in the views, but they're not even using it like for example they might have a field. And they might just hide the field, and the field, and when you really check it that field is not even use and if you did it's just there because some previous developer thought it might be needed, and they included it right. So if you trim your views like that, it will reduce the SQL query count for the page right which would ultimately increase your page or time and TTFP time to first bite. So have a look at your views and try to make them smaller. That's what I'm saying. I think I mixed up the last two points there but turn off the default CSS HTML that comes from your view and this will reduce your HTML geometry. So every kilobyte counts in this case right. If you try to develop a site, well most people develop sites first and then afterwards they try to like optimize it and try to trim things right. It will be very hard to like try to do it that way. So if you like will like you know mindful of this while you actually develop any site. You know it would be actually easier because a typical example is, you know you, you write a bunch of CSS. And then afterwards you try to optimize that CSS but it's really difficult at that point because now you have to go rewrite everything right. You will like target and directly classes and IDs and so on in the beginning, then, you know, every line of CSS that you save, it really helps at the end of the day, right. So this is something that if you can do it from like the beginning of a project, or early on in stages of a project, it will be much easier to achieve in the long run. Yeah, that's about it. So, I'm not sure how we do in any time here, but I can take some questions. If you guys have any. Oh, so she won this at Govan. I have one question regarding that you mentioned about the viewport loading. When user scroll it will render the stimulus. If you scroll to this one right. Yes, yes. So it will work for the board as well like if search engine board will just crawl the data, it will like. So what I, what I, what I thought about that right so like the the HTML still exists. So if you like let's say you are the top of the page and you load for the first time, and then you did a text search for something in that pink section, you will still find it because the HTML still exists. So if you did a text search and you jump directly that section, then you browse over just load that section immediately at that point. So it is still searchable and still accessible, even to like screen readers on song, right, it's just not rendered at that point. Because HTML still exists. It means it's still accessible, right. But if you go to that link. It explains very detail about what you just asked actually there's a section on that. Anyone has any other questions. All right, it seems we don't have any more questions. Thanks a lot for your session and now stop recording.