Metrics

[00:00:00]
>> Now we know the problem. So we have that we have this problem okay? And the next step is to talk about metrics, okay? Because we can't improve what we can't measure, so we need to measure to improve something. Is not like am going to look at the website and say, it is faster now because my brain thinks it is faster than yesterday this is not how this works.

[00:00:26]
And in terms of metrics we have two kinds of metrics today, browser-centric metrics and user-centric metrics. These are just two examples of those we will get into the details. For example browser-centric metric, can be Time to first byte or Load. User centric metric - Content layout shift, Largest contentful paint, we will see them, okay?

[00:00:48]
Typically web performance originally were focusing on browser-centric metrics, because it's something that the browser will tell us sometimes. So what's a browser-centric metric? First, it's a metric that is important for the browser, so the user is not actually affected directly by the metric. Maybe that a worse metric there will affect other user-centric metrics, but not by itself.

[00:01:18]
The first metric that we typically use, it's Time to first byte, known as TTFB, Time to first byte. Previously, we were saying this as Backend time. Actually the latency will actually appear here. It's the time that it takes for the browser to receive the first byte from the HTTP response from the server.

[00:01:46]
So I'm requesting the index.html. I'm requesting your website. And the server is doing something server side, and returning me the bytes of that response, the bytes of that file. Well, at the moment where we get that file, that's time to first byte, and we measure that from the zero.

[00:02:05]
The zero is when the navigation starts. The navigation starts when you type a URL and press return, or when you click on a link pointing to that website. That's our zero, okay? That's the beginning of the timeline. Then over the timeline, we will see different milestones. Time to first byte is at which point in the timeline, the browser has received the first byte.

[00:02:31]
That means that it knows that the server is there and is responding because I'm getting some information back. Another browser-centric metric is first paint. First paint will actually tell you at which moment in the timeline the browser has paint something, but that something can be a line, or a background color, not actually content, okay?

[00:02:57]
So that's why it's not a user-centric metric, can be white, can be black. But the browser took the decision to say okay, we are going to start rendering something, okay? And that's First paint. Page load is another one that is actually browser-centric. That was actually the one that we were using before 2005.

[00:03:21]
During the 90s and the early 2000s we were using the page load time to measure performance. You know when page load is fired, does anyone know? Page load? What page load means? What does it mean?
>> Is it when the last byte in the get request arrives?
>> When the last byte arrives, no, it's actually farther away from that.

[00:03:48]
It's actually when the browser has nothing else to do about that page navigation. Which means, all the files were downloaded, all the resources were downloaded, and everything is painted on the screen. So everything is ready, okay? That is including iframes that you might have, if you have an iframe.

[00:04:07]
Even content that is actually below the fold. I will explain what that is in a minute, but after the scroll. Even content that is a mile away in this scroll, when everything is ready, page load is fired, okay? And we realized after a couple of years that that's actually not so important for the user.

[00:04:27]
It was important on the Internet Explorer era. Have you ever browse the web with IE? Yeah, we have two and a lot of "lucky you" again. So on IE, at least the first versions, like IE5, IE6, IE4, we used to have an animation, the logo. The same on Netscape, by the way, not just IE.

[00:04:50]
So when you are loading a website, we had a logo that was spinning around, and the logo stops at one point. At which point? When the page loads. So there were a lot of users that were actually waiting for that logo to stop to start using the website, okay?

[00:05:06]
You remember that, you're laughing because you remember that. Well, that's actually a page load. The problem is that page load needs a lot of time. And it's not so important because we know that the page is actually ready to use before that moment, before everything was downloaded, parsed, and rendered.

[00:05:24]
We don't need to wait for that time. So it's a browser-centric metric that, and we won't use anymore. It's not important. It's not an important metric. You will still get that metric from different tools, but it's not really important, okay? In fact, browser-centric metrics are not so important.

[00:05:41]
Yeah, some of the metrics will be important. Maybe time to first byte is something that we will check, but it's not really, really the ones that we will care the most about, yeah?
>> So if you have an event listener for on-page load. It's gonna be very pessimistic about when that JavaScript fires?

[00:06:00]
>> Yeah that's correct, that's why using on-page load, on load or addEventListener("load"), it's actually a bad idea today. And instead of doing that you should be using DOMContentLoaded. DOMContentLoaded is fired when the HTML has finished parsing and the DOM is ready in memory.

[00:06:18]
It doesn't matter what, if the images are loaded, if the CSS are loaded, what happens with iframes. So you can start firing JavaScript there. So using the load event in JavaScript, it's a very bad practice today, but it was pretty common in the 90s or the early 2000s.

[00:06:35]
I used that, yeah. Guilty. But it's not important anymore. We shouldn't be doing that anymore, okay? So forget about page load. So during the rest of the day, probably we won't use page load as actually a real metric. Sometimes we say page load, but we're not thinking about the real browser-centric metric known as page load.

[00:06:59]
We will care about user-centric metrics. And the problem with these metrics is that they cannot be defined or expressed by code, actually, because it has to do with the user. How the user perceives performance, it's about user's perception. So we have to wait for browser vendors first to the community to define some units and some metrics and how to define the metric and how to calculate the metric.

[00:07:33]
And then we need to wait for browsers or tools to actually calculate the metric, okay? So for example, we have first interactive, that's the one also known as time to interactive, sometimes names might change. But first interactive means that the main thread has been released, at least for a couple of milliseconds.

[00:07:55]
So you know, well I'm not sure if you know, but now you will know, that the browser has only one thread by default. It's a single thread. Everything that the browser is doing goes in one thread. Your JavaScript runs on the same thread, okay? So if it's occupied by the browser doing something, you cannot execute JavaScript.

[00:08:15]
If the thread is occupied by your JavaScript code, the browser cannot render. Because it's the same threat is like it's like a highway with only one play for only one car at a time, okay? So we have one lane, so only one by one. And first interactive means that the browser left some room for a while so we can write our own code, okay?

[00:08:44]
What the browser is doing? Well, parsing, downloading files, parsing. Actually, downloading files can be asynchronous. So that can be in a different thread. But parsing and laying out and rendering that is calculating the CSS and then actually making the rendering on the screen. Happens in the same thread, so if it's taking too much time you're not leaving a space to execute JavaScript.

[00:09:11]
So first interactive is at which moment there was some release so actually it's interactive, why it's interactive? Because when you click when you drag when you scroll the browser needs to receive the input from the user, from the scroll operation, the click operation. For that, it needs to be interactive.

[00:09:32]
Speed index. I think that speed index is pretty cool. It's underused. The first time you see the metric, it's not easy to get it. So let me explain what that is. Always if you see the even the number to say speed Index, three seconds. Let me explain that.

[00:09:54]
We have an example. So on the x-axis, we have time, in this case in milliseconds, so 100, 200 milliseconds, right? And then we have screenshots at the bottom. So we see a screenshots of that website over time. What's the end? The end of the timeline is when the page is loaded.

[00:10:14]
And then what we measure at any point in the x-axis is how much of the final rendering is actually rendered at that point. So, for example, here we see nothing because it's white, the line is over zero on the y-axis. So the y-axis that we see here actually at the right, it's actually percentage.

[00:10:40]
How much of the final rendering was rendered at each point of the timeline? So when we start seeing a logo, we see here that we are going up on the percentage because now we see a logo. And then of course it's getting better over time. So a speed index.

[00:11:00]
This is how you calculate the speed index. We need to make, this operation, so we need to take screenshots of the website. And then we calculate the percentage of the final render at every point. Let me show you another example and you will get the idea. This is Amazon.

[00:11:22]
On Amazon, we see for 100 milliseconds, nothing, so we are at zero. And then, quickly, it goes over 75% of the final rendering, and then the rest, until we get 100, okay? Both are being loaded at the same time, so the page load time it's the same. Let's say 1.3 seconds, roughly.

[00:11:47]
Both, okay? So both are 1.3 seconds, but which one is faster? Gmail or Amazon?
>> Amazon. The area under the Amazon curve is bigger.
>> The area under the Amazon curve is bigger, and is that better or worse being bigger?
>> Feel faster for the user.
>> It feels faster.

[00:12:11]
Amazon feels faster because we render more content in less time in the timeline. So if you think about this so what being faster means, we don't know what that means, right? But it feels faster, I like the idea of feels. So it feels faster, the perception of performance is better on Amazon.

[00:12:31]
>> So what happens if like say Amazon have the last percent took three seconds? That curve would be very large Is there any way like normalize for.
>> So actually we're not normalizing the value, in fact I didn't explain what the speed index is yet, this is how you calculate it.

[00:12:51]
So what is the index is it's the area above the curve not below the above, in this case the gray area. The bigger the area the worse. So in this case when you're expanding the x axis you will get we will have more, more area. So what we need is to reduce the gray area that in short words, it's like measuring how much blank the user sees over the page load process.

[00:13:21]
And we need to reduce that blank, so that nothing that the user sees, okay? Makes sense, kind of? So the value that we receive as a speed index, it's a number, it's the area above the curve. But the number by itself doesn't say anything. So it's expressing which unit.

[00:13:40]
Pixels per time, percentage per time, it's not important to understand the number, but how it's measured. And the number by itself, it's also useless. That's why we will talk a little bit about performance budgets. So it's not just about the number, we need to define which number is good and which number is bad, okay?

[00:14:02]
So it's not just getting the value, it's knowing, we are really bad, or we are really good. So when you look at both websites, the loading process, you can feel that Amazon is better. Even the page load time is the same for both. And a speed index will measure that feeling, that's the idea, right?

[00:14:22]
So speed index is measuring that feeling. The feeling that Amazon is faster, okay? Make sense? That's speed index. We will see how to measure these metrics in Dev Tools and in other tools in a couple of minutes. Time to interactive. We saw first interactive first, time to interactive it's not just the first time it's interactive, is that it's interactive enough for a couple of milliseconds.

[00:14:53]
So you can scroll safely and you won't see janks as scroll or things like that because it has enough time left for us to execute JavaScript. Largest contentful paint, also known as LCP. That's the one that we will focus the most for measuring a good loading performance, at least the initial loading process, LCP, okay?

[00:15:22]
LCP, largest contentful paint. We will explain that better in a couple of minutes with examples. But actually, remember, every metric in this case, it's calculated over the timeline, and it's at which point in the loading process. The largest contentful element of your screen was painted. What is the largest content for paint?

[00:15:45]
It depends on your website. It can be a text, title, a paragraph of text, it can be an image, actually 75% of the websites are using an image as their largest content for paint. It's like, the largest part of your website that is actually content, and not just a color.

[00:16:03]
We'll see some examples there. And also, you can create your custom metric, and this is actually pretty cool. You can define for your website, for your experience, what's a good metric. So for example, Twitter used to have a time to first tweet. So when you get in twitter.com, at which point the user is seeing one tweet, okay?

[00:16:26]
And that's time to first tweet. So you can actually define your own metric, so then you can see how to improve that metric based on what experience looks like for your users. Do we have a question?
>> Is time to interact somewhere between DOM content loaded and load?

[00:16:43]
>> Typically, it's after DOM content loaded, and it can be after on-load. So it can be between, that's probably the most common scenario, but it can also be after. I mean, if you are executing a lot of JavaScript. And I'm talking to you, react developers, or angular developers, or Vue.js developer, that are not using a framework, a server-side framework, maybe that happens after onload.

[00:17:11]
So it depends, actually. Let me add a warning. I think I have that slide later, but let me add a warning at this point. With web performance, don't trust anyone, don't even trust me. So you need to trust on the data. You need to measure and see everything in action for your website.

[00:17:33]
And if you can, for your real users, with something known as real user metrics, RUM. So don't trust, like the check the top ten things you need to do to improve your website then you go and do those ten, it doesn't matter. So don't trust that because every website is different, so you need to see a lot of techniques, test them, measure them and see if that's better or worse.

[00:17:59]
We don't have silver bullets here. So we actually need to measure, test and then apply techniques, test again and see if it's better or not for our website. Of course, we have some basic ideas that will apply for most or for all the apps, but for some a lot of small things, it depends.

[00:18:22]
So it depends on your website on your content.