883: Web Vitals Explained

What are Web Vitals, and why should you care? Scott and Wes break down metrics like LCP, FCP, CLS, and INP, explaining what they measure, how they impact your site’s performance, and how to track them yourself. Show Notes 00:00 Welcome to Syntax! 03:26 What each web vital means. Web Vitals Playground. 03:38 LCP - Largest Contentful Paint. 05:04 FCP - First Contentful Paint. 06:07 CLS - Cumulative Layout Shift. 10:58 INP - Interaction to Next Paint. 13:43 Measuring the impact. 14:22 TTFB - Time to First Byte 15:27 How to track this on your own. 17:42 Checking the performance of Syntax.fm. 21:07 Brought to you by Sentry.io. Sentry Web Vitals. 21:49 Checking the performance of Wes’ site. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. Today we have an episode on web vitals. That is, these words that you keep hearing thrown around. FCP, LCP, INP, TTFB, OMG. All these performance words that are either thrown around, or when you, when you run your website through like page speed or something like that, they will give you numbers. Or if you look in Dev Tools at your performance, they give you these numbers for these different values. And I've been dipping into them a little bit. I've been moving my, my personal website over. And as a part of that, I was like, I wonder if I can, can get this any better.

• 0:43Wes Bos?

  Right. And I, when I first ran it through without doing anything, it was at like a 65. And then there was just all these like little nuggets that are, I could add and tweak and change here, here and there. And I got it up to a 95 at this point. I can get it a little higher if I start taking stuff off. But I've never seen a website higher than 95 that brings me joy.

• 1:08Scott Tolinski?

  Yeah. Yeah, that's such a thing. You had that tweet, there was like something to the regard as like, you know, the only way to get a higher Lighthouse score is just by shipping absolutely nothing. And it is like so true. You know, every time those, those like mother effing websites or any of those things, it's like, okay, I get what you're trying to say with this, but like, it's not practical for most websites to have absolutely nothing in, in, in sake of a 100 score, 100 performance Lighthouse score. You gotta have stuff on your website. Whether that is images or whatever. I know people these days like to ship really boring websites. And we gotta liven it up a little bit, folks.

• 1:48Wes Bos?

  Yeah. And not to say that you can't have an exciting website, but like, like one example is I have this like little grunge speckles over top of my text. And for some reason it thinks that that is causing a contentful paint later on because it loads in and there's that like, you can like try to get 100 in the score. And by the way, it is 100 on desktop.

• 2:13Scott Tolinski?

  Sure.

• 2:14Wes Bos?

  But on mobile, on slow 4G, on some like crappy.

• 2:20Wes Bos?

  Android phone, it's a 95. And if I were to sort of strip out all the images and take all the term away, I could get it up. But it's at a certain point, you got to say, yeah, this is what I'm happy with because it's a nice looking website, right?

• 2:37Scott Tolinski?

  But also, right? It gives you actionable items, but you personally, you know what's causing that largest contentful paint to slow down or whatever. You know what it is. You know it is this image that doesn't have any effect on the user's experience. So the simple fact that you can look at this and say, I know why the score is low and it's not affecting users is the ability to be secure in your score that's not 100, right?

• 3:08Wes Bos?

  I'm almost at a point where I want to user agent detect the PageSpeed Insight website and simply remove those items just from that user agent to stop people on Twitter from trying to dunk on me. So let's go through what they all mean. And we're going to be using a website. It's actually from Sentry, webvitals.com. And they do a great job at sort of explaining what they are and visualizing what each of them are. So we'll start with LCP, largest contentful paint, which measures the time it takes for the largest text or image element to render on the webpage. So what that means is when you load a website,

• 3:54Wes Bos?

  you might see stuff immediately. And then this is actually a very frustrating experience is that you'll see something and then something else will load and then it will render again. And then something else will load and it will render it again, or you'll have like a little, this could be like a banner that pushes the website down, you know? Or it could be as simple as a font that loads and then it re-renders. Like sometimes when you look at the timeline view of a website, you'll see the like fallback font render first and then once the web font loads, then it will re-render. And that's that will cause a number of different things, but one of them will be a repaint.

• 4:37Wes Bos?

  So that's the largest contentful paint, which is basically like waiting for the website to stop making huge changes. Like if we were to reload this page here, you'll see this might be a website you visit and then, oh, it bumped down. And that's really frustrating when you visit a website and you're trying to start using the website. But everything on the page keeps moving and that's so frustrating for an actual user.

• 5:04Scott Tolinski?

  Yeah. Next up is the first contentful paint, which FCP. And this measures the time from when a page starts loading to when any part of the page's content is first displayed. So I think this is something that people might hack by doing like skeleton screens or things like that, right? To get something on the screen instantly if you're doing client side rendering. Or this could also be slow if your server responses slow, right?

• 5:30Wes Bos?

  Yeah, a big one is waiting for HTML CSS to actually load. It could be blocking the actual HTML from from loading on the page. Server responses could be a big one. So for mine, a huge improvement came when I was, I was just kind of like developing it. I had my cache turned off. And then once I flipped the cache on, the the response times for some of the dynamic stuff increased or yeah, or got much smaller. And then my FCP got really, really low. So that's certainly one to keep your eye on. Next up, we have CLS, cumulative layout shift,

• 6:10Wes Bos?

  which is the the total amount of unexpected layout shifts that occur during the entire lifespan of a web page. So this is another frustrating one where things load on the page and this could be an image. If you do not have the width and height of an image. Encoded on your image tag, it's going to cause cumulative layout shift. So one thing I didn't have is my logo didn't have a width and height on it. So what would happen is it would load zero pixels high. And then, once it loaded, it would bump everything down, right? Or if I go to, I believe it was on my about page. Yeah.

• 6:53Wes Bos?

  So this image right here, you'll notice that it flickers. Yeah. If I, if I refresh it really quickly, you can see that there's just like a hole in the website. Right? And that's good because I wrote a script that on build would figure out what the aspect ratio of every single image was. And then, then I'm able to encode that data in the image or sorry, in the image tag. And then whenever you load it, the next JS image tag does this, the next image tag does this. And that's really handy because it doesn't cause your page to sort of move whenever somebody, something is loaded.

• 7:30Scott Tolinski?

  Yeah. Yeah. I mean, these things are all, it's funny because these are all things that we experience on a day to day basis. And I gotta say, as a user, you know, I can take a slowly loading website or I can take, you know, sometimes I can take something with a slow interaction and next paint, which we'll talk about in a second. But the layout shift has got to be one of the top two most frustrating things in using a website. When some resource loads late, usually an ad, and then you end up clicking on the wrong thing and it somehow knows exactly when your finger is like coming down onto the button. It's like it sees your webcam sees your finger about to push on something and it's like, oh, time to load the ad. It's, it's crazy how it does that every time.

• 8:14Wes Bos?

  Here's, here's a kind of a neat one from Juan Ferraz. So I was, I was tweeting about how I was working on it and this guy's genius at this stuff. So he kind of went through and found a bunch of stuff that I could very easily change to, to improve it. And one really neat one that he did was I had my font fallback to swap, which is what you want. So meaning that when text loads, If you have a custom web font, you should probably show, if it doesn't load within a certain amount of time, you should probably show like a fallback font while that's loading. Otherwise, you're just sitting around and the text is invisible until it shows up.

• 8:56Wes Bos?

  Right? That's, that's a bad experience. So it's a better experience to show the text while you're, you're actually loading your web font, but it is a bad experience when that, that fallback font is a different size than your actual font that you use. So what he did here is he added a font face called fallback that uses local Arial, but then it adjusts the ascent, descent, line gap and size adjust. So basically it stretches every letter of, of Arial to match the size of my custom web fonts, which, which was Redneka.

• 9:40Scott Tolinski?

  What a G. Holy cow.

• 9:42Wes Bos?

  Yeah. And I asked him, he said the story in Stefanoff has a write up on it. I know NextJS does this. When you use Next font, it will sort of measure all the glyphs and match them. So you can have a nice fallback. Previously, he shows the previous version before it's loaded, it has a big, it pushes the whole page down. And then once you apply this fallback font, it, it still changes because like you still have a paint because the font loads in, but it doesn't actually push the page up or down, which is really nice to have. And I also added, if I were to view source on the page, there is a preload

• 10:27Wes Bos?

  for each of the fonts. Here we go. Link rel equals preload and then I've preloaded it. And what that does is it tells the browser, before you even get to the opening body tag, start downloading these assets because you're going to need them eventually. And then by the time it gets to the CSS and the CSS is parsed and it realizes it needs a web font. So it downloads the web font and then the web font is parsed and then it applies it. You're way ahead of yourself when you, you preload, preload those things.

• 10:56Scott Tolinski?

  Yeah. Sick.

• 10:58Wes Bos?

  So we did LCP, CLS.

• 11:01Wes Bos?

  FCP, there is INP, which this one is also really important to pay attention to. You do not see INP when you do page speed insights. And that's because it has to do with interaction to the website. So when you click on something, here Sentry has a really good example. Watch this slow one. When I click it, uh, and then like, like a second later or 400 milliseconds later, it actually does it. Um, I've, I've run into this previously with eBay's search bar. You would click on the search bar and it would not like focus it for like 200 milliseconds or whatever.

• 11:40Wes Bos?

  So there was obviously some sort of code that was blocking in between the focus event and/or or the click event in general. Maybe there was, maybe there was a click event higher that was checking if it was a specific type, type of click. And then if it's not, it goes, it, uh, it captures down, not but events can either bubble up or capture down. So it might just capture down and there's probably some code in there that was, was faulty and causing a long time. So the time that it takes for a interaction, whether that's a click, a touch, a scroll to when the actual paint happens to, to when the user sees it.

• 12:22Wes Bos?

  And if there's a delay more than, I don't know what's, this is a fast one. I'm not sure what a, a fast one is.

• 12:31Scott Tolinski?

  Yeah, the slow one is one second here.

• 12:33Wes Bos?

  136 milliseconds is considered a fast INP interaction to next paint.

• 12:39Scott Tolinski?

  And then 500 is considered slow.

• 12:41Wes Bos?

  Fast. Yeah.

• 12:42Scott Tolinski?

  And then over that is very, very slow. You know, there's a lot of techniques to reduce this type of thing and it could, sometimes it's, uh, that you have some not great programming inside of your React components. You're clicking something and a whole bunch of JavaScript is running before the UI does anything. Sometimes it's waiting for a server response and you can fix that with optimistic UI where the thing, you know, paints immediately and everything else happens in, in the background. But it is something you need to be aware. Because if you use a native app on your iPhone or Android phone, you click something, it almost 100% of the time does something the moment you click it, whether or not it's saving into a local SQLite database, whether or not it's triggering a loading state, it does something the moment you click it.

• 13:27Scott Tolinski?

  And that's the experience you should be striving for with your web apps.

• 13:31Wes Bos?

  Even if you do need to wait, like you should be showing something to tell the user that they actually were. Cause how many times have you clicked something and you're not sure if it worked? So you had to click it again and now you've got two things. So the way you can measure it is you go to your Dev Tools, open up the Performance tab, load the page and let's click on something. So I'm just gonna, I'm on my about page here, I'm gonna click on my logo for the homepage. And it says IMP of 40 milliseconds. So obviously that's, that's very good. And that has to do with, because the framework I'm using, Waku, has preloaded. Yeah, Waku, ah, I always get it wrong.

• 14:10Scott Tolinski?

  Waku.

• 14:10Wes Bos?

  Waku, they've preloaded the homepage. So the amount of time that it takes to simply just swap out that component is extremely fast, right? It's 40 milliseconds.

• 14:21Scott Tolinski?

  Word.

• 14:22Wes Bos?

  And then finally, there is TTFB, Time to First Byte. This is simply the amount of time between the request that was, that was made and when the first byte is delivered to the actual browser. So this has entirely has to do with how quick your server can deliver a response to the actual client. So this might have something to do with if you have a slow rendering or you haven't, haven't cached, let me see on my, my website here. So there we go. Look at that was 727 milliseconds. Cause I don't have caching turned on right now and it had to like warm it up. I'm gonna, I'm gonna be turning caching on, but if I were to refresh that, there we go.

• 15:06Wes Bos?

  Look at 93 milliseconds because that function has been warm. And if I leave it for a couple of minutes, then it would, it would go back up to 7, 800 milliseconds. So I'm going to be caching the actual output of that and using staleware or validate. So we don't have, the user doesn't need to wait on all the server rendering stuff that, that is happening behind the scenes.

• 15:27Scott Tolinski?

  Man, yeah. Okay, so if you want to actually get into figuring out these things on your own, obviously you can plug in your website to PageSpeed Insights and get some of them like we mentioned. So if you want to get things like the IMP, a lot of this stuff can be gathered directly in your browser in the Performance tab. Now, the Performance tab will load some things on refresh. It will show you IMP, CLS, LCP. You can also click Record at any point in user application, and it will be not only showing you like a flame graph of the JavaScript functions that are running, but it will show you all kinds of stuff. It will show you screenshots so that you can see even frame by frame how things load, if things are shifting when they're loading, where there's

• 16:11Scott Tolinski?

  times where 60 FPS is dropping. The Performance tab is definitely underrated. It's a bit of, it's a bit intimidating, don't you think, Wes? Do you feel like the Performance tab can be intimidating?

• 16:24Wes Bos?

  I think so. There's a lot on here, and if you don't know what you're looking at...

• 16:29Scott Tolinski?

  It's just a bunch of lines and numbers, yeah.

• 16:31Wes Bos?

  Yeah, and I think that's why these vitals are really nice to sort of look at, because you can look at all this stuff, and if you want to figure out what is causing that, like some of these people that are able to figure out what is causing it, like this Juan, he figured out that if I made my background image cover, then the web vitals would ignore it because it's considered a background image and it's not content. But there's all these like wild things, and you can look into that and really get to know it. But simply just like looking at these four or five different vitals is a great way to start and know if something is good or not.

• 17:14Scott Tolinski?

  Yeah, nice.

• 17:15Wes Bos?

  Yeah, so you can go to your Performance tab, click on Record. Refresh and Record is really nice because that will show you the initial page load. It's also worth doing it with the disable cache on and off, so you can kind of get an idea of... Is this fast because it's loading from my disk? Or is this fast because like, what does it look like when the first this person visits for the first time ever? And they don't have a client cache? Yeah, the syntax website, though, we've got some, some really good. We did a whole show on like, how we improved a bunch of performance things on the website, but we've got some pretty good metrics on here. I wonder what the actual page speed score is for us.

• 17:56Scott Tolinski?

  Yeah, I know some of that. Yeah, I'm sure there are some things. We load a lot of stuff on the site.

• 18:02Wes Bos?

  Yeah.

• 18:02Scott Tolinski?

  We also have a massive content JSON file that loads for search. That probably doesn't help us.

• 18:09Wes Bos?

  But no, that didn't matter because that just loads.

• 18:12Scott Tolinski?

  It loads in the background.

• 18:13Wes Bos?

  Lazy and.

• 18:14Scott Tolinski?

  I don't know if what vitals gets angry at that. I actually haven't checked.

• 18:18Wes Bos?

  I don't think so. Let's see. And other, another really kind of cool thing is if you, I think if you have Google Webmaster Tools or something, it will show you the actual scores for people that are actually visiting your website.

• 18:32Scott Tolinski?

  Yes.

• 18:32Wes Bos?

  Right? So you'll see here, we've got a 61.

• 18:35Scott Tolinski?

  Yeah.

• 18:36Wes Bos?

  But the actual stats that people are seeing is, is, is good. We're in the green for most of them. And then we're eking in the yellow for first content, full pay and time to first byte. So these two for FCP and TTFB, if we improve the server response speed, then I'm sure that the FCP would go down as well and we'd be in the green for all of them. What are we on desktop though? 78. What is it telling us we can improve here? Images. This is also kind of a nice thing is it's kind of like broken tests. They'll, they'll tell you some possible savings that can be done here. And not all of these are, are things you can actually change. Right? Like you get back to the removing the entire website and then it's fast.

• 19:21Scott Tolinski?

  Yeah.

• 19:22Wes Bos?

  But you can look through and go and say, oh yeah, that is something I could, I could possibly do. So it's telling us we could, oh, our GitHub avatars. We're loading GitHub avatars off of GitHub.

• 19:35Scott Tolinski?

  Yeah, we're not caching them or?

• 19:36Wes Bos?

  Well, no, we're, we're just not, we're just loading them directly off of GitHub.

• 19:40Scott Tolinski?

  Yeah.

• 19:40Wes Bos?

  We don't have control over that. But if we were to put like a proxy in front of that.

• 19:44Scott Tolinski?

  Right, that's what I'm thinking.

• 19:45Wes Bos?

  And then compress them, maybe convert to AVIF or WebP. That would probably give us quite a bit. That should probably be a pretty good video.

• 19:54Scott Tolinski?

  Yeah, because weren't you working on something with images and like a Cloudinary-esque personal service?

• 20:02Wes Bos?

  Um.

• 20:04Scott Tolinski?

  Or was that what I did? I dreamed that up? I feel like you were doing it.

• 20:06Wes Bos?

  Years ago, I wrote a Cloudflare worker that sits in front of Cloudinary.

• 20:12Scott Tolinski?

  Yeah.

• 20:13Wes Bos?

  And what that does is it uses Cloudinary to do all the resizing. And then it uses the Cloudflare worker simply just to cache them so you don't use up the Cloudinary bandwidth. But these days, I just moved it all to Cloudflare images because it does all of it for you. All right, so that is WebVitals. Certainly worth taking a look at your website and seeing where all these things are. And it's as much as I hate them, it's also kind of addictive trying to be like, ooh, what could I do to increase this? And you try to game it up a little bit. And now I'm curious if we could, there's probably three or four little things on Syntax website we could do to bump ours up quite a bit.

• 20:58Scott Tolinski?

  Yeah, I am the, I'm the exact type of person who needs some numbers to gamify things for me, to make it interesting for me. I actually really love, love that about the Sentry stuff. Because in Sentry, they give you all this stuff for your users who are actually using the site. But they give you like, these are the pages that are hit the most and have the worst scores. And for me, that is so helpful because I can say, what is going to make the biggest impact if I approach this first? Okay, this route is clearly the slowest. Let me, let me get this as fast as possible and then just move down the list to the ones that will have the biggest impact. Because the last thing you want to do is spend a whole bunch of time fixing something

• 21:40Scott Tolinski?

  to make Lighthouse happy when it has absolutely no impact on your users, right? That's just like, kind of like an ego fix, right?

• 21:47Wes Bos?

  Exactly, yeah.

• 21:48Scott Tolinski?

  Yeah.

• 21:49Wes Bos?

  That's where I'm at with this, this 96 on my personal website right now is like, in no world is this actually affecting anybody who visits the website.

• 22:00Scott Tolinski?

  Yeah.

• 22:01Wes Bos?

  But could I get it a couple of points higher?

• 22:06Wes Bos?

  Cool. All right. That's all we have for you today. Let us know if we missed anything or you'd like to add anything. Tweet us at syntaxFM, skid us at syntaxFM, or whatever other way you'd like to get in touch.

• 22:20Scott Tolinski?

  Yes, absolutely.

• 22:21Wes Bos?

  Peace.

• 22:22Scott Tolinski?

  Peace.