Web Vitals Explained

Welcome to Syntax today with an episode on Wes vitals. That is these words that you keep, hearing thrown around, FCP, LCP, INP, f, TTFB, OMG, all these performance words that are either thrown around or it 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 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. Right? And I I when I first ran it through without doing anything, it was at, like, a 65.

And then there Wes just all these, like, little nuggets that are I could add and tweak and change here here and there. And I I got it up to a 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. Yeah.

Yeah. That's such a thing. You had that tweet of there was, like, something to the the regard JS, like, you know, the only way to get a higher at, 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, that's not practical for most websites to have absolutely nothing in in in pnpm sake of a a hundred score or a hundred performance lighthouse score. You gotta have stuff on your website, whatever that JS, images or whatever. I know people these days like to ship really boring websites,

and, we gotta liven it up a little bit, folks. 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 a contentful paint later on because it loads in. And there's that. Like, you can, like, try to get a hundred in the score. And by the way, it it is a hundred on desktop.

Sure.

But on mobile, on slow four g, on some, like, crappy Android phone. It's it's a 95.

And if I were to to to sort of strip out all the images and and take all the charm away, I could get it up. But it's at a certain point, you gotta say, yeah. This is what I'm happy with because it's,

it's a nice looking website. Right? But also right? It gives you actionable items. But you personally, you know what's causing that, largest Contentful ESLint to slow down or whatever. You know what it is. You know what 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 at a hundred. Right?

I'm almost at a point where I wanna user agent detect the PageSpeed Insight website Oh, man. And and simply remove those items just from that user agent Scott. To stop people on Twitter from trying to dunk on me. Oh Node god.

So let's go through what they all mean. And we're gonna be using a website. It's actually from century,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 web page. So what that means is when you you load a a website, you might see stuff immediately.

And then this is actually a very frustrating experience JS that you'll see something, and then something else will Node, and then it will render again. And then something else will load, and it'll render it again, or you'll have, like, a little this could be, like, a banner that pushes the website down. You know? Totally. Yeah. Or it could be as simple as a a font that loads, and then it it rerenders. Like, sometimes Wes you look at the timeline view of a website, you'll see the, like, fallback font render first. And then once the the web font loads, then it will rerender. And and that's that will cause A a number of different things, but one of them will be a a repaint.

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. 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 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 response is slow. Right? Yeah. A big one is

waiting for HTML CSS to to actually load. It could be blocking the the actual HTML from from loading on the page.

Server responses could be a big one. So for mine, a a huge improvement came when I was I was just kinda, 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 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, which is the, the total amount of unexpected layout shifts that occur during the entire lifespan of a 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 it would bump everything down. Right? Or if I go to, I believe it was on my about page. Yeah. 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.

Aspect ratio of every single image Wes, 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 the Nuxt 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.

Yeah. Yeah. That 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 in Next Paint, which we'll talk about in a second. But the layout shift has gotta 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 JS, 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. Here's here's a kind of a neat one from Juan Farah. So I was I was tweeting about how I was working on it, and this guy's genius at this stuff. So he kinda went through and 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 fall back to swap, which is what you want. So meaning that when text loads, if 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 is invisible until it shows up. 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 Wow. 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 Radnica.

And g. Holy cow. Yeah. And I asked him. He said the story in Stefanov has a write up on it. I know Next. Js does this.

When you use next font Does it? 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 ESLint because the 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 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 realized it needs a web font, so it downloads the web ESLint, and then the web font is parsed, and then it applies it.

You're way ahead of yourself when you you prelate preload those things. Yeah. Sick.

So we did LCP, CLS, FCP.

There is INP, which this one is also really important to you 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. Century has a really good example. Watch this slow one. When I click it, and then, like like, a second later or four hundred milliseconds later, it actually does it. 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, two hundred milliseconds or whatever. So there was obviously some sort of code that was blocking in between the focus event and or 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 it, it captures down. Node 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. 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. Yeah. The slow one is one second here. A hundred and thirty six milliseconds is considered a fast INP interaction to next paint. And then five hundred is considered slow. Fast. Yeah. 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, that you have some Scott 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 Yeah. Waiting for a server response, and you can fix that with optimistic UI Wes the thing, you know, paints immediately and everything else happens in in the background. But it is something you need to be aware of 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 it to a local SQLite database, whether or not it's triggering a loading state, it does something the moment you click it. And that's the experience you should be striving for with your web apps.

Even if you do need to wait, like, you should be showing something Some. To tell the user that they actually were. Because how many times have you clicked something and you're not sure if it worked? So you had to click it again, and now 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 on my logo for the Node page, and it says Pnpm of forty milliseconds. So, obviously, that's that's very good.

And that has to do GitHub because the framework I'm using, Waco, has preloaded yeah. Waco. I always get it wrong. Waco. Waco. They preloaded the Node page. So the amount of time that it takes to simply just swap out that component is is extremely fast. Right? It's forty milliseconds.

Word.

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 slow rendering or you haven't haven't cached. Let me see on my my website here. So there we go. Look at that Wes seven hundred and twenty seven milliseconds because I'm 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. Look at ninety three milliseconds because that function has been warm. And if I leave it for a couple minutes, then it would it would go back up to seven, eight hundred milliseconds. So I'm gonna be caching the actual output of that and using stale while we're 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.

Man. Yeah. Okay. So if you wanna actually get into figuring out, these things on your own, obviously, you can plug in your your website to page speed insights and get some of them like we mentioned. So if you wanna get things like the, Pnpm 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 INP, CLS, LCP.

You can also click record at any point and use your 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 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 do you feel like the performance tab can be intimidating?

I think so. There's there's a lot on here. And if you don't know what you're looking at It's just a bunch of lines and numbers. Yeah. Yeah. And I I think that's why these vitals are really nice to to sort of look at because you you can you can look at all this stuff. And Sure. If you wanna figure out what is causing that, like, some of these some of these people that are able to figure out what is causing it, like this Node, he figured out that if the if I made my background image cover, then then the web vitals would ignore it because it's considered a a background image and it's not content.

But there's all these, like, wild things. And you can look into that and and really get it get to know it. But simply just, like, looking at these four or five different, vitals is a great way to to start and know if something is good or not.

Yeah. Nice. Yeah. So you can go to your 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 turning doing it with the disable cache on and off so you can kinda get an idea of, is this fast because it's loading from my disk, or is this fast because, like, what what does it look like when the fur this person visits for the first time ever Mhmm. And they don't have a a client cache. Yeah. The the Syndax website, though, we Scott 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. Yeah. I know some of that yeah. I'm sure there are some things. We load a lot of stuff on the site.

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

But no. That that didn't matter because that just loads It loads in the background. But I don't know. And I don't know if WebVitals gets angry at that. I actually haven't checked. I don't think so. Let's see. And other another really kinda 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. Yes. Right? So you'll see here, Wes we got a 61.

Yeah. But the actual stats that that people are seeing is is is good. We're we're in the green for most of them, and then we're eking in the yellow for first contentful pay and time to first bite. So these two for FCP and t t f b, they if we improve the server response speed, then I'm sure that the FCP would go down as Wes, 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. It's it's kinda 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. Yeah.

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. Yeah. We're not caching them? Or Well, no. We're No. They're We're just not we're just loading them directly off of GitHub, so we don't we don't have control over that. But if we were to put, like, a proxy in front of that Right. That's what I was thinking. Yeah. Compress them, maybe convert to AVIF or or WebP, that'll probably give us quite a bit. That should probably be a pretty good video

to to Yeah. Because weren't you working on something with images and and, like, a a Cloudinary esque personal service? Or Wes that what I did I dream that up? I feel like you were doing it. Years ago, I wrote a

Cloudflare Worker that sits in front of Cloudinary.

Yeah. And what that does is it 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'm I just moved it all to CloudFlare images, because it it does all of it for you. Alright. So that is Wes vitals. Certainly worth taking a look at, your website and seeing where all these things are. And it's as as much as I I hate them, it's also kind of addictive trying to be like, oh, what can I do to increase this? And you try to try to game it up a little bit. Now I'm I'm curious if we could there's probably three or four little things on Syntax website we could do to to bump ours up quite a bit. Yeah. I am the I'm the exact type of person

who Node some numbers to to gamify things for me, to make it interesting for me. I actually really love, love that about the Century stuff, because in Century, 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 wanna do is spend a whole bunch of time fixing something 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?

Exactly. Yeah. Yeah.

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

Yeah.

But could I get it a couple points higher? Cool. Alright. That's all all we have for you today. Let us know if we missed anything or you'd like to add anything. Tweet us at Syntax FM, Wes at Syntax Scott FM, or or whatever other way you'd like to get in touch. Yes. Absolutely.

Peace.