This course has been updated! We now recommend you take the Build Progressive Web Apps (PWAs) from Scratch course.
Transcript from the "Chrome DevTools" Lesson
[00:00:00]
>> Mike North: And there is a great DevTools course on Frontend Masters you should check out. But there are two areas I wanna focus on, in case some people have not seen that one yet, two areas of Chrome DevTools. And Chrome is what we're gonna be working with all day, in terms of developer tools.
[00:00:17] The first one I want you to pay attention to is your Network tab. And it looks like this. I'm just gonna give you a quick tour of what's going on here. So, you would do this up like, I still use Inspect element, right-click anywhere on the page. Click Inspect element, a thing will pop up on the bottom of your browser.
[00:00:34] And then click the Network tab on the top of that new thing that popped up and you will see something that looks like this. Now, you can set this up a number of ways, but I want us to pay attention to a couple of things. First, we've got the name of requests being sent out, and you can see that these look like API calls because you see that /api in the grey text on the left.
[00:00:58] This is because I've used this top filter here to filter for Only XHR, right? This is ajax. That filter box, by the way, that can take either a string literal and it will go and look for matches that match that string. You could also put a regular expression in there.
[00:01:17] So this is great if you had some chatter back and forth between two different system components and maybe you've got a word send and a word receive. And you wanna sort of take away all of the noise except those things that say send or receive. You could just write a regular expression with an or operator in there.
[00:01:38] It would be, slash send pipe receive slash. And that regex will be honored in the filter. We've got a status where you see your HTTP response status code, and these are 200s, meaning everything looks good. For protocol here, we're gonna be touching on HTTP/2 a little bit today.
[00:02:03] For the last, gosh, 30 years the web was operated on HTTP/1 and as our apps get more and more complicated it is necessary for the standard to evolve. So, I want us to be able to see the difference between those two types of requests. And then we've got this Size column.
[00:02:25] As we start to deal with something called service workers, we'll be able to use this to identify what is a request that's going to the outside world versus what's one chunk of your app asking. We'll have two chunks of our application and sort of one will send the request to the other and the other will satisfy that request instead of going to the outside world.
[00:02:49] That is the ultra high level service worker idea. And then finally, we've got Time and this Waterfall tick here. And the reason they're so thin is that I have used this filter on the top, it's sort of below this millisecond marks to sort of narrow the timeline to a particular moment.
[00:03:09] But if you hover over these little waterfall things you can see all of the time that you're spent waiting for the browser to allow a request to go out. You can see DNS resolution, you can see the overhead required for establishing a secure connection. So you can really drill down and see what's going on there.
[00:03:29] So that's the Network tab, and then there's this Performance tab. And we can think of this as being divided into three chunks. The first is the timeline and this is just sort of the superposition of how hard your CPU's working, how much memory you're consuming, whether it's rendering that's taking a lot of CPU versus computation.
[00:03:54] So that's on the top here. Below that we have network requests. And being able to see this side by side is really useful. This is not the starting point app that we're looking at. This is not a measurement of the app as it is right now, in Master.
[00:04:10] What you would see, because of this little screenshot film strip, right above the millisecond marks here, you would see that this yellow bar in the network section, which represents downloading the JavaScript. You'd have a completely blank screen until that JavaScript landed, because that JavaScript is responsible for doing 100% of the visual stuff on the screen.
[00:04:33] But it's a great way to sort of see the interaction between something came over the network, then my cpu started working really hard. Then all of the animations on my page started getting really choppy and I couldn't scroll smoothly. You wanna kinda see them all side by side on one axis.
[00:04:53] And then below that we can see what is called the flame chart, and this represents how much time each function takes to be invoked. And if you hover over these little sections here and you can zoom in and zoom out to sort of stretch this out and focus on a particular area.
[00:05:12] You can see that some of them are really thin and some of them are sort of fatter. We aspire to allow our web apps to work at 60 frames per second. And that only allows us about 13 milliseconds maximum per function invocation. That is our budget, before we start interfering with the ability to sort of scroll smoothly or animate things on screen.
[00:05:40] In JavaScript we're working on one thread, and everything we're doing is a very complicated process of bookkeeping and adjusting this animation a little bit. And now let's do some computationally intensive work and then draw one more frame of the animation, it's a lot of multitasking. But this is where you can look to see if there are massive performance issues and I'm going to walk you right into a major performance issue.
[00:06:09] It's a function that takes about 20 seconds to invoke, so it will be the obvious culprit when you start doing this performance analysis. But knowing how to read this flame chart is important. And we call it flames because it's solid at the top, and it looks kind of like fire as it comes down.
[00:06:30] You can think of it as a function is one section of the flame chart, one row, or cell, I guess you can call it. And then any functions that it invokes will be the next level down. So you can see that we start out course, but then things sort of split up as we go down and down and down.
[00:06:48] And so if you wanna figure out what is causing this freeze, what is taking a long time? It would be a conspicuously wide bar, and then you could sort of drill down and figure out. Well, when we get down to it, I'm allocating a thousand arrays here, that's the problem.
[00:07:05] Maybe there is something we can do to avoid that and make this faster. So these tools have been around for a while. As we lean more on our client side apps, as we try to push more responsibility in the direction of the browser, this starts to become a must as supposed to something we look at when we encounter a problem.
[00:07:28] You wanna keep an eye on this as you develop rather than waiting until a problem occurs. Because oftentimes it's like a death from a thousand paper cuts that makes things slow. And by the time things are slow, there are 50 different tasks you have to perform in order to speed it up.