The Google Core Web Vitals team understand the amount of web performance recommendations is overwhelming and many don't know where to start. We've been working on identifying the 9 key recommendations (3 per Core Web Vital), which we think will have the most impact and which we recommend sites look at first. This talk will explain what they are, and why they are our top 2023 recommendations.
Top Core Web Vitals Recommendations for 2023
AI Generated Video Summary
1. Introduction to Core Web Vitals
Hello, everybody. I'm Barry. Slow websites suck. There's a lot of web performance advice out there. First of all, you've got to figure out what you've got to measure. We think we kind of solved this. We, being Google, came up with three new three-letter acronyms, the Core Web Vitals. These are three new metrics that Chrome came up with as a way of measuring user experience for their websites.
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.
2. Improving Web Performance
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.
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.
3. Web Performance Recommendations
There are web performance recommendations that are realistic for most developers to implement. We came up with three recommendations for LCP, three recommendations for CLS, and three recommendations for FID. For LCP, the first recommendation is to ensure that LCP resources are discoverable for the HTML. This involves understanding how the browser parses HTML line by line.
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.
4. HTML Parsing and Metadata
There's a QR code for you to look up. It's not line by line, it's byte by byte, chunk by chunk, symbol by symbol. The HTML parser is in charge of turning your code into a beautiful blog post. It goes through the code line by line, starting with HTML and setting the language for accessibility. The head contains metadata.
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.
5. HTML Parsing and Metadata
This section explains the importance of setting the character set and viewport near the top of your code. It also emphasizes the use of titles for visual feedback to the user.
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.
7. Fighting the Browser Preload Scanner
If you want to fight the browser preload scanner, make sure to give it something to fetch. Use resource hints to preload necessary fonts and preconnect image CDNs. Don't fight the preload scanner, make resources discoverable. Put more of your stuff in HTML and server-side render to improve performance.
8. Prioritizing LCP Resources
9. Using Fetch Priority API
There is a new API called fetch priority API, previously known as a priority hint. By adding one HTML attribute, you can tell the browser to prioritize important images. eBay saw a 150 millisecond improvement in LCP by using this technique.
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.
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.
10. Using Fetch Priority API
For them to do it just from a one line code change is fantastic. Use fetch priority to tell the browser about important images, but don't overuse it. Use it one, two, maybe three images tops.
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.
11. Optimizing Document and CLS
Last of all, use CDNs to optimize document and resource TTFP. Having a CDN means that your document is copied in loads of places around the world, making it come back quicker. For CLS, ensure that images have width and height attributes to prevent shifting. Ads can also cause shifting, so use min-height to leave space.
12. Optimizing Min-Height and Back Forward Cache
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.
13. Optimizing Performance and Metrics
I wrote an article about the performance impact of giving up free web performance to users. There are APIs that can disable the back forward cache, and using unload handlers can also stop it. Avoid animations that use layout-inducing CSS properties, as they are process-intensive for the browser. Instead, use transform, which is less work for the browser and doesn't count towards CLS. We introduced a new metric called Interactions Next Paint to replace FADE and measure faster websites.
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.
14. Measuring Interaction and Improving Performance
17. Optimizing Rendering and DOM
There's a lot about concurrent rendering, resourcability, non-destructive hydration, keeping DOM sizes small, CSS containment, and using requestAnimationFrame for critical tasks. These are our top nine recommendations. Read our blog post for more details and links.
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.
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.