Top Core Web Vitals Recommendations for 2023

Hello, everybody. I'm Barry. That was a great introduction, so I will skip past on that and get started straight into the talk.

Slow websites suck. How many people like slow websites? Weirdos. And like, there's a lot of web performance advice out there. Maybe too much. I know because I write a lot of it.

First of all, you've got to figure out what you've got to measure. We love our three-letter acronyms in web performance. There's loads of them, tons of them, and we're just adding more and more continually. Timed first byte, by the way, is a three-letter acronym. The second T doesn't really count for anything, two, who cares? This is kind of overwhelming for particular people who aren't web perf nerds like myself.

We think we kind of solved this. We, being Google, came up with three new three-letter acronyms, the Core Web Vitals. Hands up, who's heard of the Core Web Vitals? Mixed crowd here. Okay. So, these are three new metrics that Chrome came up with as a way of measuring user experience for their websites. And these are ways that we can measure every single website. So, your only website might have your own metrics that you want to use. You might want to look at conversions, you might want to look at bounce rates, you might want to look at signups and that sort of thing. These are more measuring across the board that any website can use.

There's three of them. The Largest Contentful Paint, or LCP, measures the time from when you click on a link to the largest bit of content that's on the page. Typically that's a banner image. Maybe your H1 tag or something like that. Cumulative Layout Shift is my favorite one. It's whenever you go to a site and you start reading and an ad pops in and the thing moves down, and it moves across, and you have no idea and you lose your place and it's really, really irritating. Traditionally we never really measured that before so it's really interesting to have that. And FID, or First Input Delay, is supposed to be the responsiveness metric.

So when you click on a menu and it doesn't open, and you click again, and then it suddenly registers both and opens and closes really quickly and it's really annoying. So we measure that. And as well as coming up with the metrics, we came up with recommended limits for each of them. If you're under 2.5 seconds for LCP, we say you're good. If you're above 4 seconds, we say you're poor. And anywhere in between is mm, okay.

One thing to note is that we've just announced that FID is going to be replaced very soon with IMP, a new metric that we'll talk a good bit about later because that particularly affects JavaScript people and I heard there might be some in the room at the moment. So we'll come back to that one.

Okay. So we now know what to measure. We've given you nice little things that we think that you should measure there. The question then is how do you use that to improve web performance? So we've lots of tools, you can stick it in Lighthouse, it will run 53 performance audits and come back and say these are the things you can do. Yellow Lab Tool is another great tool, it will give you 38 little checks and give you a green tick or a red cross and say look at these things. Web Page test, for anyone who's done any waterfall analysis, it's fantastic. It's 16 pages of stats. And Chrome Dev Tools Performance Panel, if any of you have looked into that is, let's just say there's a lot of detailed information there and apologies to some of the Dev Tools team that I see over there.

So, we're back to the same thing, it's kind of overwhelming again. So we want to answer this question. So, we came up with, I spent a lot of time last year looking at this question. What are the most important recommendations that we can give to developers to help them improve the performance for their users? So, rather than stick it in the Lighthouse telling you, these are 53 things that you could improve but will it actually move the metric or not? We want to give a simpler, smaller list and say these are the things you should look at first. Particularly if you're new to web performance, you haven't really looked at it first, look at these things first and then come back to look at the rest. We want to have a particular focus on recommendations that we believe are the largest real-world impact. So, we're going to sit there and tell you to do this and you're going to spend a lot of time implementing it and it's going to see if not point, not, not, not, one second off your website. You're going to be annoyed and go, okay, yes, maybe technically that's best practice to do this but it took me six months and it didn't really do anything. Thanks very much. So, we're looking at things here that we really think will have an impact. We want to look at recommendations that are relevant and applicable to most websites. So, it's going to be lots of talks here at this conference on React or solid JS or whatever. It's very specific to those or if you're at another conference, on WordPress or whatever. So, we're looking at more general things here that every website should be able to consider and have a look at.

And we want to look at recommendations that are realistic for most developers to implement. So, there's a lot of really complicated web performance stuff. Inlining CSS, for example, has great performance opportunities. But it's kind of tricky to do right. A lot of people get it wrong. A lot of people mess it up and then it doesn't load properly. So, we're trying to look at some things that are, you know, if we tell you do this, most people are actually going to be able to do it if they want to.

So, we did that and we came up with recommendations for each. So, we came up with three recommendations for LCP, three recommendations for CLS, and guess how many recommendations for FID? Five. No, three. So, we've got three of each. The talk was nine recommendations, come on.

So, let's get started then. LCP recommendations, the first recommendation and it's particularly relevant for you JavaScript developers. Ensure that LCP resources discoverable for the HTML. And to do that, like, if you look at LCP resources, as I said, it's mostly a banner image, maybe an H1 tag. 70% of websites, depending whether you're looking at mobile or desktop, it's an image. So, an image has inherent delay because you've got to download your HTML. You've got to parse that HTML. You're going to say, hey, it's got an image. That's probably another resource. You've got to get that. We've got to display. All within those 2.5 seconds. So, to do that, we're going to talk a little bit about how the browser actually does that. HTML is parsed line by line. This is a quote from a friend of mine, Harry Roberts, a web performance consultant. He has a great talk on this, by the way. So, if this gives you a little taste of what you like, have a look at his talk on YouTube. I'll share the slides afterwards, by the way.

There's a QR code for you to look up. Where he delves into it in a lot more detail. I'm just going to touch the surface on this. It's also not strictly true, so don't tell Harry this. It's not line by line. It's byte by byte, chunk by chunk, whatever way you do it. It's symbol by symbol. But it's close enough.

So, we've got the standard bit of HTML. This is actually from a web.dev article I helped maintain. Fairly sort of standard. I've chopped a little bit out to fit on the side. And your browser is going to take this, and it's going to take all this code and turn it into a beautiful blog post. And the process that's in charge of that is this guy, the HTML parser, I like to call him the big dog, head honcho. He's going to make sure that it gets done. He's a bit long in the tooth. He's been around a while, much like myself. His eyes don't really look that far ahead, much like myself. But he's, you know, he's a workhorse. He will get through that code and he will make sure that your HTML is turned into that beautiful blog post. And he will start going through it line by line.

So he starts off, HTML, great, that's what he's good at. Good start, fantastic. Language, always set your language. Great for accessibility. And for those people who don't know or don't care about accessibility, the easiest way to putting it is if you go to a French website and it says, hey, you're English speaking, do you want to translate into English? That's because they set the language right. And the browser knows your English, the web page says it's French, it auto translate. Simple tag, do it. Then get to the head. The head's kind of your metadata.

This isn't your content, this tells the browser. It's all information for the browser about what to do. Your character set, you want this up near the top. This says what code, what character set the code is actually written in. If the browser doesn't have this near the top and it's already processed something and it gets a different character set than it was expecting, it has to restart over again because it goes, oh, I might have read that wrong. So get it up nice and near the top. Your viewport, this is all fairly standard stuff. By the way, those of you not using this viewport and disabling Zoom, come and see me afterwards. I want to know why. Because I've got these bad eyes and I love to pinch to Zoom. So this is probably the one you should be using unless you've got a very good reason. And you get your titles. You can now put the page title in your tab there. That's first sort of visual feedback to the user that something's actually happening. I'm going to skip these next three. I promise I'll come back to them.

Then you get to JavaScript. At this point, that big dog stops and goes, I don't know anything about JavaScript. It calls his mate, the V8 engine, that we learned about in the last talk. It comes along, processes that. The big dog goes back to its kennel, sits down, grabs a bone, starts gnawing away, says I'll come back to it later. After that process does whatever it needs to do.

Oy! Big dog, it comes back, sees I've got some CSS. Oh, network, can you get me some CSS? It goes and gets some CSS. Oh, and I need some more. Anyway. The point is, it's going through it line by line. And it can often get paused by things like JavaScript by waiting for network resources. That can make websites incredibly slow. And like, websites realize this, Microsoft actually realized this first. About ten years ago, it came up with a better way of doing which was this guy.

So, if the last guy was a big dog. This is what I like to call the excitable little puppy. He's a preload scanner. What I will do is, while the big dog is doing the main work, it will zip through and find all the resources that it needs and start fetching those in advance. And that makes it a lot quicker. So, whenever the big dog gets there, everything's already fetched. It doesn't know how to parse the HTML, JavaScript, and all you need to do is fetch really quickly. It will just run through it like a little excitable little puppy. If you throw him a ball, he'll go and fetch it really quickly. And that makes websites really fast, and you can see this. If you ever run a waterfall, this is from WebpageTest. We get the blue HTML document, and then boom, we're immediately asking for five resources here that it's already found that it needs to fetch. So, if you're not putting those resources in there, then you're making it really difficult for that. So, if you're not getting anything for this little dog to play with, then you're slowing your website down. My colleague Jeremy wrote this fantastic article, Don't Fight the Browser Preload Scanner.

I love the title of this, by the way, because you might think, okay, how would I fight the browser preload scanner? This is how you would fight it. If this is all you've got, that little app.js, and there's nothing else in your HTML until you download that app.js, which is probably several megabytes in size, parse it, compile it, and only then start injecting stuff in there, you've basically given nothing to that little puppy to play with. You've given nothing to fetch. But why would you do that? Look at his face. Come on, he loves fetching stuff. So, give him something to do there. Now, you might be asking, what if I need to execute JavaScript to say, you know, it's custom content, it's a photo app. I want to display your photos, not someone else's. That's fair enough. So, we'll come back to these three lines, which I did tell you I'd come back to. These are resource hints you can put in there and say, preload these. You're going to need these two fonts. I have no idea what you're going to display in this text until I execute my JavaScript or later. But trust me, you're going to need the fonts, you're going to display something. Or web.dev uses an image CDN. So, we're saying, preconnect this image CDN. Again, don't know what image you are actually going to download. But you're going to download an image most likely on most articles at some point. So, you can go there. And again, it gives the little puppy something to play with. So, don't fight the preload scanner. Make resources discoverable. And that's honestly one of the biggest things that we, the JavaScript developers, do very badly. So, put more of your stuff in HTML. Server-side render stuff. Give that little puppy something to play with.

Moving on. Ensure that LCP resource is prioritized. So, we said earlier the LCP resources are 70% images. I'm going to let you into a dirty little secret here, browsers don't prioritize images. At least initially. They couldn't give a damn about those. Script browsers fetch resources in several steps. First of all, they get the render blocking resources. So, CSS is in there, any synchronous JavaScript that goes ... I can't even start to draw the page until I do this. And only then does it get the onscreen content. Your images, your video, or anything like that. So, this is why you often see pages draw. There's a big white space where the image is, and then the image starts to come down there, because it doesn't hold up that initial drawing until it gets the image. And then finally it gets the offscreen talk. A lot of content. There's an awful lot of talk about lazy loading stuff. But I just kind of do it a little bit, and they figure out what's onscreen, say, get me this very quickly, and then we'll worry about the rest of it and we'll get it later. So, images are not render blocking. They can't be in that first stage. They're always going to be inherently delayed a little bit. And we're saying that the LCP images are your most important content that we want to get up there in front of the user quickly. Then the fact that it's not going to be even started to be fetched for a little while is kind of annoying. And I know some of you might say, hey, we just heard from this very clever guy called Barry Pollard so we know how to fix this. What we'll do is we'll just preload the image in there. That's... He told us that. It tells us to fix things properly. This doesn't actually work as well as people think it does because the browser still knows it's an image. I've got...

Oh, look at that, my fancy little clicker. So we've actually told it, this is an image, fix it as an image. So it goes image, I know about it. I'll get to it later. I'm gonna get to those more important stuff first. So it helps a little bit that it discovers it earlier but it still doesn't get it in that first phase. It still says I'm gonna get the more important stuff first and only get to this whenever I get it later. So that doesn't help us with the way we think it is.

But there is a new API that does called fetch priority API. It used to be known as a priority hint. And this is a really, really complicated JavaScript API. So I'm gonna show you some code in this next page. Don't worry about it, don't get confused. We're gonna walk away through it and I'll explain it. Because to use this and tell the browser this image is important means you have to do this. That's it. One HTML attribute. Anyone here know HTML? Come on, one person. So, I'm gonna show you. No, but you add an HTML attribute to this. This tells the browser I don't care what you normally do. This is important to me. Boost it, get it first and get it because it's important.

And a symptom from eBay said, we added priority hints, we tweeted this out at the end of last year. The main image in the item page and immediately saw an LCP improvement of 150 milliseconds in Chrome. Easily one of the most effortless speed wins for us truly a one line change. Now, you might be thinking, 150 milliseconds? Who cares? Come on. But trust me, eBay is actually pretty fast. So for them to get any performance improvement is pretty good. For them to get 150 milliseconds is brilliant.

For them to do it just from a one line code change is fantastic. One word of warning this, whenever we explicitly increase the priority of one resource, we implicitly decrease the priority of another. It's a quote from another friend of mine, Andy Davis, another web format expert. So don't shove this thing on everything. Use fetch priority to tell the browser about important images, but don't overuse it. If you stick it on every image there, you've basically said none of them is more important than the rest, all of them are important, and probably more important than that render-blocking CSS and stuff like that. Don't overuse it. Use it one, two, maybe three images tops.

Last of all, use CDNs to optimize document and resource TTFP. So until you get that HTML at the top, you can't start with the rest of the waterfall. You can't get anything. So the document is the most important thing you can actually get. And we use CDNs a lot, but we don't generally tend to use them for the document. We often use them for image CDNs or JavaScript CDNs, where we get the JavaScript there. We tend not to use them as much for documents there. And that's honestly where you can get most of the game there. So having a CDN means that your document is copied in loads of places around the world, it'll come back quicker. Even if it has to go back to your server to do some, I don't know, look up and get personalized content, it's a lot quicker doing that from a CDN than doing it from the actual browser all the way back. So have a look at that.

Moving along, so our CLS recommendations. As I say, CLS is when everything shifts around and it's really annoying. The reason it shifts around is because we haven't actually left space for that. We know we're going to load something in there. And traditionally, we talk about images. So again, this is HTML for the JavaScript developers in the room. You put the width and height on images, for example. An image without width and height, the browser will very cleverly say, this is probably zero pixels high, zero pixels wide, you know, good guess there. And if you load it, you got some text there. When the image comes in, everything shifts down. Really, really annoying. If you have those width and height, the browser goes, ah, okay, I'm going to leave a little bit of space here, I know what the size is. Even if you've got CSS to say max width, it'll use that to calculate what we call the aspect ratio and set aside the appropriate height. So very simple there, just make sure that all your images have width and height. But it's not just images. Ads are a big one. So, again, ads often come in late loaded. You can put the min-height in there and leave some space. Even if, you know, you've got different ads for different people, it might be 50 pixels, it might be 75 pixels, depending on the ad displayed.

Trust me, it's not going to be zero pixels. So put a min-height in there of 50 pixels, at least you've reduced it. It's still a bit annoying but not doing that.

Similarly, if you're using an app.js file and it's an empty div to see that, don't do it. The number of sites I see where the footer's up there, budging the header and going, oi, let me get in there. Then the app loads and it moves everything down. You know the app is going to be spending a little bit of time. Shove a min-height in there. It's very easy. Reserve some space, less jarring for the user from moving around. Be eligible for the BF cache.

So the BF cache, or back forward cache, is a very little interesting thing that the browsers do. Chrome came very late today, we only launched it about a year and a half ago. But what it does is when you go to a page, let's say you go to Google search, you click on a search result, you go there, you're like, that's not the one I want, you click back. You can either do research and it can take a couple of seconds. Or what the browser will do is it will keep a copy of that page in memory for a few minutes after you've gone and say, if you come back, boom, there you go, instant. Because better than loading fast is loading instantly.

So we're going to have a look at a video here, if the Wi-Fi works. So we start on TechCrunch, on left, we've got a back forward cache browser, and right, we go to BBC, it takes a little while to load. If we go back, you can see on the left it's instant. If we're like, oh, actually I forgot to pick up something from that article I'm about to read. So if you go forward again, again, instantly on the left, and it takes a little bit of time. So even if you're caching all the resources in the browser, it still takes a while for JavaScript to execute and to lay out the page and to do something. We show that about 10% of pages on desktop, and about 20% on mobile, are actually back forward navigations. Again, there's lots of examples in this, when you're shopping for socks on Amazon, you're like, oh no, I don't like those plain back socks. Click on that one instead. So there's lots of back forward newspaper articles whenever you're looking at them. You're back and forward, and you're looking through it, and do that. So there's a lot to be gained from this. And if I can be so bold as to quote a very smart person, me.

On this, I wrote an article before I joined Google about how I thought this was a performance game changer, and I always said that sites that are giving up free web performance to the users, making passing the core web titles needlessly toughen themselves with not doing this. Because you get this for free, but there's a couple of APIs that you can use that'll disable this back forward cache, because the browser goes, I'm not sure if it's safe to actually restore back to this page. So if you use cache control no store, or if you use unload handlers on desktop, then it stops it.

There's a very easy test in DevTools in Chrome. Go there into the application tab, go to back forward cache. There's a big, inviting blue button. Load your page, press that, it will go forward, to a random page about .chrome or something like that, and it will come back, and then it will tell you whether that works, and if it didn't work, here's CNN, it will tell you why. These are unload handlers, and you can look at those and see whether they're actually worth the benefit.

And last of all, avoid animations that use layout-inducing CSS properties. This is a bit of a weird one, because I'm not entirely sure that we're doing this right, but it's what we're doing at the moment. So look at this fancy animation. We love animations, we love bringing them in and stuff like that. But if you're using top, left, right, bottom, and you're moving stuff with that in CSS, that's actually really process-intensive for the browser. They've got to relay out everything else, and they've got to have a look and send and shift, and then figure it out and redraw it. That's even if you move it into its own layer, its own Z index, and it's completely separate from the page. It will still have to do that stuff and do that. And these two bits of code are, will be identical to the user, but the one on the right is using transform. That happens in the compositor layer, after all the layer is happening, we just do a little trick right at the end just before we've hit the screen. Much less work for the browser, and also doesn't count towards CLS, because the CLS stuff happens earlier than this. The net effect to the user is mostly the same, so maybe CLS shouldn't measure it, but there's lots of other good reasons we're doing this. So, if you're sitting there and you've got a cookie banner that comes up, make sure you're doing it with transform, not with top left, because otherwise you're getting needlessly hit with that CLS. So, Fade, as I say, you click a button, how long does it take until the JavaScript cart is running? Lots of websites pass this. It's not a really good measure, and that doesn't mean that we're just making it harder, because can we all honestly hand in heart say that lots of websites are fast for, you know, they interact immediately and do that and stuff like that. No. So, we've introduced this new metric last year, Interactions Next Paint, and at Google IOO at the beginning of this month we announced this is going to replace FADE next year. So, there's some search ranking benefits from having faster websites. This will be what we use to measure it. So, FADE, basically, if you start clicking on a button, you've got some blocking time before anything happens. Then you've got the interaction, your JavaScript code running, and then you've got to paint the results of that JavaScript running. FADE measures this bit.

IE, the blocking time, before it starts running. And only for the first interaction. That was kind of an easy way of saying, right, does it take a long time whenever a person clicks before it actually does anything? IMP, however, measures all of the full interaction. And it measures for all interactions and gives you kind of a worst one as a score for your page. And that doesn't mean that your whole interaction has to be finished. You just have to give a paint. So, as long as you're not blocking that main thread that whole time. So, if you're sitting there doing a network fetch, don't worry about it, as long as you're allowing the browser to update if we click something else or you're putting a loading dot, dot, dot, this thing in there. As long as you're giving the browser that chance to do it, we're not going to penalize you for the whole time. We recognize some things are slower to run than others. But what you should do is not hold up the whole browser, block it, the whole thing, to prevent it actually doing anything. You can think of IMP in these phases. Sort of the input delay which is what FID measured, your processing time, that's the one you probably thought about more, that's your code or your framework's code that you're looking at, and then the presentation delay. So, we're going to talk about some of these things. The first two bits are kind of improving your JavaScript, last bit is kind of improving your rendering.

So, the easiest thing is avoid or break up long tasks. Again, shout out to Jeremy who's written another fantastic document on this, he's got a lot of docs on web.dev about how to do this. JavaScript is greedy by nature. We've got this function, we're quite happy with it, we've modularized it, we've got five little sub functions and great for us, our code is written in a way that we like it. JavaScript will hold on to that main thread and run through each of these. So, even though we've got five functions here, it'll just do them one after the one after the other. In a way, it's no different to have written them as one big function. So, what you need to do is tell the browser, right, okay, take a break now. The easiest way to do that is set timeout, which has been available for a while. So, here we've got a set timeout of zero. We're saying these lesser important things, run them in zero seconds. It doesn't actually run them in zero seconds, it puts them at the back of the queue in zero seconds. If there's nothing else to go, we don't need to do any paints, nobody's clicked another button with more important stuff, it'll run them straight away. If there's other stuff that needs to be done, it'll do that. You're allowing the browser to go and handle any other events that are important to it, before you do these things. It's important to look at your code and see where you can put these breakpoints in. There's nice JavaScript APIs, Chromium only at the moment. But keep an eye on these, set timeout is available. And look at your frameworks and what they can use.

The next thing, and I'm probably in the wrong room for this, but avoid unnecessary JavaScript. Because our love affair with JavaScript knows no bounds. We're shoving more of that stuff on our pages. But you got to look and see, do we need it? And particularly, do we need it always upfront? There's a big argument at the moment with SPAs. Is that big delay until it gets there and everything works really quickly worth it? Or should we load the minimal needed to draw the screen and then lazy load the rest of the stuff as people scroll down, as they interact, or using a service where I could try and get it proactively, prefetch it in the background? So have a look at your code. What can you split? What can you load later? What can you do? That sort of thing.

And don't just look at your code. Google Tag Manager is another big one that gets a lot of stuff. A lot of developers go like, well, that's marketing. I don't care about that. Marketing will have that. Look at them. See that. Ask them why they still have that tag from their summer 2000 promotion. Do they really need it now it's 2023? Get them to remove stuff. Because even if it isn't firing on any page, it's still a big, big blob. And when you stick it in Lighthouse, it's sitting there going, whoa! Google Tag Manager is the worst thing on your page. So clean that up and have a look at it. Similarly with other third party content. If you've got chat widgets or video embeds, defer them or use modules which defer by nature. Any social widgets that share this thing, they're often quite chunky in JavaScript. They're just a simple button, you think, but they're quite chunky. They're the bottom of the page. You don't need to unload at the top. Eye frames are very easy to lazy load. And, you know, if you've got a lot of YouTube embeds and they're all off screen, lazy load them and the browser will get them just before they come on the screen. Facades are another thing, particularly for video things like YouTube, where you can sit there and it will show the image, but won't download the big chunky video player until the user actually clicks play. Because if they're not gonna click play, there's pointless bringing it down. And last of all, avoid large rendering updates. So see what your framework offers here.

There's a lot about concurrent rendering, using suspense and react and separating out the bits rather than saying, this whole app has to all render at once or nothing, I don't care. You wanna break it up and say, this bit's ready, render it, this bit isn't, that's fine, just display this little bit of text and go on.

There's a lot about resourcability and non-destructive hydration. If you're doing a lot of work on server-side rendering, to send that over in JSON blob and then get the browser to re-render the whole thing is quite expensive and a bit of a waste, so have a look at and see what your framework offers there.

Keep your DOM sizes small, that's honestly the easiest thing that you can do, because if you're updating, there's a lot of the JavaScript framework will re-render the whole DOM, so again, if it's big, that's gonna take a lot of time. If you keep it small, it doesn't matter if it does that. CSS containment is a bit more advanced ones, you can sit there and say, this bit of the page isn't affected by this bit of the page, it's okay, if that changes, don't worry about redrawing like this. And requestAnimationFrame is an API that runs on every animation frame, if you put a big chunky bit of work there, it's gonna run on every animation frame, so don't ever use that, only use that for critical stuff that needs to be run just before they're animated.

And that's pretty much it, those are our top nine recommendations. We've written a blog post on it, with a lot more detail and a lot more links, so have a read of that.