Transcript from the "Measuring Real User Performance" Lesson
>> So the very last thing I wanted to cover as network stuff is the idea of measuring real user performance. So this is a really cool idea. It was actually something I didn't get into until later in my career. So what we would always do is we would like, again, we are like authoring a web app, and we look at it on our machine and we are like, it is pretty fast or whatever.
[00:00:22] We know the amount of milliseconds that it takes. And then somebody even asked a question earlier about like, but does it normalize that data based on your network conditions? And it does not. But I think that's hinting at a really a larger question, which is like, okay, but how fast is it for your average user or like how fast is it for the bottom 10% slowest user computers?
[00:00:43] Or something like that. And so this idea came around a long time ago of shipping some code that would like sort of get the time that it actually takes on their actual computer and send it back to you. So at its like absolute simplest, you could stand up a service that takes like maybe a username and event like the page to load and a time, right and you could have a database that stores all that.
[00:01:21] And then you can figure out the difference yourself by doing n minus star and then you could send that to this cool service. You can be like, whoa, like most people, it takes one second. But look at this, a few 100 people, it's taking 30 seconds what's going on there.
[00:01:35] And you can learn all sorta cool stuff like, we have our data centers in the US. But we're getting a really big, African bump in users. We should get a data center out there. We should do something like that. So this happens to us a lot like at Twitter at startups.
[00:01:49] You'll see your app will go big in a new place that it hasn't been big before. And all of a sudden everybody's kind of crossing over the the data takes a long time. So this can be really cool to A, see what how it performs on slower computers but B, to recognize when something has changed, like you have a new country city zone that's getting really popular and you wanna go add some resources to it.
[00:02:12] So this is what we used to do. But then we got this really cool thing called console time, which is way better. So instead of doing the math ourselves, we could just console time we could pass in a string. Now we do the thing when it console time end the same string and then it keeps track of it.
[00:02:28] It prints it out for us, which is like super cool. And it's also more accurate it prints it out down to a more finite number. So then that was the cool thing to do for a really long time. And now we have an even cooler thing, [LAUGH] which I get really excited about, which is the performance API.
[00:02:46] And so, again, these are all doing the exact same thing, right? But it's like, instead of console time and console time end, you do performance, which is a global, dot mark, and then performance.markend, and then you can print out, mark and measure is the technology, so then I print out a random string, and then which two things to compare.
[00:03:05] So this is very much the same as, up here where I would do like console and start. But the cool thing about doing it this way is not only do you get that time, but it actually is like a standardized thing that other browsers recognize. So if you run some code like this, and let me see if I have some going, Yeah, so if you run some code like this and you do a performance measurement, which is what the tab we're gonna cover next.
[00:03:34] But if you do a record, and then you refresh the page, and then you stop the recording, we can ignore a lot of stuff. But we can see that my mark and measure actually made it into a brand new section called Timings in the Performance tab where I can actually see how long it took.
[00:03:48] I can interact with that. So it's like way cooler than console logging out, end minus start or whatever you do a performance mark and a performance measure, and it'll actually show you in the Performance tab, exactly how long it took and what it was doing and cool stuff like that.
[00:04:02] So these are really cool to add something like this, whichever approach you take is fine. And to stand up some kind of service that receives all of it. And you can really see how long it's taking your actual users to load your actual code. The performance API also has a bunch of really cool stuff.
[00:04:18] I'm not gonna cover it in depth, but I did just wanna show you so just on any random site, you can do something like Performance get entries by type, and then you pass in a type. So I'll print this get entries by type of resource. And it'll actually show me all eight of the resources at grab, which is the exact same stuff that you see over here.
[00:04:37] But you can start like brainstorming like as you get more into this stuff that you could totally build your own Tooling, around, for example, you could just take this, and you could send it to your service. So your user sending it in, and now you can see the network waterfall, for your users in real time, as opposed to just you using your app.
[00:04:55] Things like that. You could do paints. So every time the browser has to do a repaint, and you can see what was it called? What did it? What triggered it? How long did it take? All these really cool things. So it's basically the same API that Dev Tools is using to do its like network stuff and things like that.
[00:05:11] But now you can not only harness it by making custom scripts where you can actually grab that user data and send it to a service, you can way better understand how long all these things are taking. This was really cool. I would just if I were you, I just do like a performance.
[00:05:26] And then do a dot and just check out all these like very, very cool things that it can do. And MDN has really great docs on the performance API, which I've linked to up here. It really opens up like a whole world of stuff you can do.