Q14: Web Vitals

[00:00:00]
>> Match the web vitals to the correct descriptions. So we have TTFB, FID, TTI, TBT, CLS, and INP. And then the time it takes for a web page to respond to a user's first interaction, the time that it takes the main thread, the time that the main thread is blocked from responding to user input.

[00:00:18]
The average time it takes for a webpage to update its visuals after a user interacts with it. The time it takes for the server to respond to a request and start sending data back to the client. Or the time it takes for a webpage to be fully loaded and responsive to the user input.

[00:00:33]
Or the last one, the stability of a webpage's layout or unexpected layout shifts that occur on a webpage as it loads. So the answer is TTFB or Time To First Byte, the time it takes for the server to respond to a request and start sending data back to the client, or more like the moment that the client receives the first byte.

[00:00:51]
Then we have FID, First Input Delay, which is the time it takes for a webpage to respond to a user's first interaction. Then we have TTI, Time To Interactive, which is the time it takes for a webpage to be fully loaded and responsive to user input. We have the TBT, Total Blocking Time, which is the time that it takes the main thread or the main thread is blocked from responding to user input.

[00:01:11]
Then we have CLS, which is Layout Shifts, so the stability of the webpages and layouts or the unexpected layout shifts that occur on a webpage as it loads. And NIP, Interaction to Next Paint, which is the average time it takes for a webpage to update its visuals after a user interacts with it.

[00:01:28]
So first, the Time To First Byte, there's no animation here or something, but that's just the moment that the client receives the very first byte of the server. This isn't necessarily as the response ends. Normally, a response streams in, so this is just the first byte of that response.

[00:01:43]
That is that Time To First Byte, that's the moment where the parser can kinda start parsing and processing that HTML. First, or next, we have the First Input Delay, and this one kinda measures. So on the main thread, we can have long tasks, which is a task over 50 milliseconds, or a regular task.

[00:02:00]
And if you open your dev tools, you will often see another bar with long tasks, these are the tasks that you wanna avoid as they block the main thread. So for example, here, the user clicks on something, as it's still performing a long task. So during those 200 milliseconds, which seems short, but for a user experience, that's actually quite a lot, it cannot process that event because the main thread is currently still processing that long task, and JavaScript is single-threaded.

[00:02:28]
First Input Delay isn't super consistent cuz what if the user clicked for the first time right before that long task? Then your First Input Delay seems a lot shorter, even though, yeah, so it's not super consistent. Also, users may not even interact with your website, then you don't get a First Input Delay value, but it's still good to just keep in mind.

[00:02:52]
Then we have the Time To Interactive, which is the first time after a long task has ended that the main thread didn't have any long tasks for at least five seconds. So this kind of just measures that after that time, the thread is reliably interactive. Maybe some long task might still occur six seconds after that last long task, if that makes sense, but yeah, at that point in time, that's the Time To Interactive.

[00:03:18]
So yeah, that's when you can make sure that long tasks won't block user input. Next, we have the Total Blocking Time, which is the time from the First Contentful Paint to the Time To Interactive that the long tasks take longer than 50 milliseconds. So the first one was 90 milliseconds, so then it's 40, 55, it's 5 milliseconds, and 154 minus 50 is 104.

[00:03:44]
And these all get combined into a single value. So here, the Total Blocking Time is 149 milliseconds, because that is the kind of cumulative time that the tasks were over 50 milliseconds, if that makes sense. I feel like I'm explaining it in a confusing way. But the Total Blocking Time is a good indication of how interactive your webpage is before the Time To Interactive, because as you see here, for both of these, well, scenarios, the Time To Interactive is the exact same.

[00:04:17]
But for the first one, there's just one big long task. During that entire long task, your user cannot interact with your webpage at all. Whereas for the second one, your user still has some time to interact with it, cuz there are still some long tasks. But in between, they can still interact with it and they will actually see that input.

[00:04:35]
But it's not reliable because you still see that some long tasks are happening right there. So yeah, it's just like a good measurement to see, okay, this is my Time To Interactive, but how interactive is it prior to getting to the Time To Interactive? Because it doesn't mean that your webpage isn't interactive at all before that timestamp, kind of.

[00:04:57]
Yeah, so here, the Total Blocking Time of the first one is 700 milliseconds, whereas for the first one, it's only 15 milliseconds. So that's a lot better. Then we have the Cumulative Layout Shift, which is kind of like, it's the product of the distance fraction with the impact fraction.

[00:05:15]
So first, we have the distance fraction, which is what percent of the largest viewport measurement, so either the height or the width, did that element change? So in this case, it moved by 22% down. And then we have the impact fraction, which measures the percentage of the vieport that was affected by this layout shift.

[00:05:38]
So in this case, it was the entire viewport that got shifted. As you could see here, nothing was as it used to be. I don't know if it just went back. Yeah, so in this case, the CLS is 0.22, cuz the distance fraction is 22%, 0.22, and then the impact fraction is 1, so 0.22.

[00:06:00]
So you can see here, if we somehow dynamically load a filter, I don't know why that would be dynamically loaded. Maybe you're fetching something from a database and then conditionally rendering based on, I don't know, a certain condition and this gets rendered right after the initial load. So maybe your user wants to click right on that Using React Server Components, but then it shifts and you accidentally click on that sort date.

[00:06:22]
So in this case, the distance fraction is only 13% down of the total viewport's heights, and only 60% of the total viewport was affected by this change, so then the CLS is only 0.07. That make sense? Kind of? [LAUGH] And then we have the Interaction to Next Paint, which is kind of a new measurement [LAUGH].

[00:06:45]
Or it gets measured when a user leaves a page. And it's the combination or the average time that it took for the website or for the page to respond to user interaction, until that interaction actually showed up on the page. So that includes processing the click event, layout, paint, and also compositing.

[00:07:04]
So at the very end, or when the user leaves the page, you usually get the worst INP that it measured throughout the entire lifespan of the page. But it kinda depends on the amount of interaction you have. Sometimes you get the 98 percentile, stuff like that. So that's Interaction to Next Paint, which is pretty new, but a pretty good indication of just how responsive it also looks to your user.