Using the Network DevTools

[00:00:00]
>> Jon Kuperman: Network optimization. So I'm back over here. Click on Network Performance. We've got some cool things here just some cool things about bounce rate, probability and things like that. But what we'll do for now is we will just kind of open the Network panel and we'll refresh this page here.

[00:00:18]
And since this page has some images and some JavaScript on it. It's a lot more interesting than the page that we were looking at before. We can kinda see that there's quite a lot of resources coming through and they're taking quite a while. We've got these low priority things taking a while to get through, I'll give it a second.

[00:00:35]
And then I think I'll actually just pop this dev tool out, so we can get a nice full page of it here. So, yeah. So we can basically see that we've got these kinda of screenshots of the app loading which we showed before. I'm gonna minimize that for now.

[00:00:46]
We've got a list of all of the things, I think Mark had pointed out this really great workflow earlier of sorting by size and seeing what the biggest thing that came down was. So you can see that the largest things that came were our images followed by this JavaScript file.

[00:01:00]
Followed by another image, and then we kinda get into our CSS and HTML. We've got at the bottom, again, still we've got how many requests we had, how long it took to load. And then we can see some things that are quite unacceptable, like the DOM content itself took seven seconds to load, the whole page took like 23 seconds to load.

[00:01:19]
We can use this again when we get into the lighthouse audit, because it'll give us some really actionable items for making this load a lot faster. But the network is a great place to start off to identify that there are problems in general. Yeah.
>> Speaker 2: What would account for the differences in load times here?

[00:01:32]
Mine says 3.21 second.
>> Jon Kuperman: I think the big thing is that I still have this 3G throttle enabled by accident, is probably the biggest thing. So let's go ahead and refresh the page here. Yeah, so now I've got two 2.11 seconds. Yeah, it's great question. I didn't mean to leave that on, but I thought it nicely illustrated that sometimes loads can be quite long.

[00:01:52]
Yeah, cool, so we've got all this different stuff. [LAUGH] That's a really good segue. These are really great tools, disable cache and throttling. But do make sure that you recheck them as you're going about your day. I actually had quite an embarrassing probably five years ago. I filed a big SEV1 ticket against one of our production apps for taking an unbelievable amount of time to load and then realized I had fair 4G or something like that enabled.

[00:02:19]
And I was doing all these profiles and I was like, how is it that this tiny JavaScript bundle is taking this long? Man, that was embarrassing. So, another case for using incognito windows cuz they'll reset all your defaults, but do make sure that these are so excellent to use.

[00:02:33]
You can also do these cool network conditions that are kind of interesting. So you can refuse some of the encodings, some of the compression algorithms. You can override the browser cache, you can get really nitty-gritty with that. But I think just knowing that these network conditions are here is good enough for today.

[00:02:51]
The one thing I wanted to point out here is, so if we go ahead and we do a refresh here and we look at some of the times. So I'm gonna click on,
>> Jon Kuperman: One of these scripts here. And so basically what I wanna do is look at what took the longest amount of time.

[00:03:08]
This picture took 11 seconds, then I go ahead and click on it. We get this really cool, so similar to what we've looked at before. You can see the headers. You can see their image response and its preview and things like that. But I wanted to check out this timing thing, cuz I feel like it's one of these very underrated features of the dev tools.

[00:03:24]
And what this is it shows you, at what point in the load was this image queued for download? When did it actually start downloading? And then it shows you this really nice color coordinated breakdown of very deeply inside the HTTP traffic, the TCP, where did things take a long time.

[00:03:43]
So this harkens back to that kinda superpowers I was talking about the beginning, where you can see how long did the content actually take to download? How long were we waiting on the server response? And so you can do these really cool things if, for example, I go back to google.com, and I do a network thing here, you can really get some amazing insights into what actually took so long?

[00:04:06]
So we can see this thing took 3 seconds. And we can see that it was really waiting for server response for quite a long time. You can get some really nice details into, for example, the request started and it was told it was a secure request. So it does this HTTPS handshake, and that goes back and forth, and then the request finally comes in.

[00:04:26]
How long did it take before when that came in and when the first byte started responding? Maybe your server's slow, or it took a long time to download. Maybe the internet connection slow on your user. So you can really see three seconds to load isn't the same as three seconds to load in different cases.

[00:04:41]
It could be you two and a half seconds waiting for the server to respond because you need to scale your servers. Or it could be three seconds all and downloading and the server responded immediately. It just took a while for the thing to download. So you can get some really cool information.

[00:04:54]
I recommend if you ever strike anything puzzling in the network performance you click on the asset itself and you come in here. And you just take a little bit of a look, cuz sometimes you'll see really surprising things. This deep links through to this really nice explanation. And so here, these are on the official Chrome DevTools docs.

[00:05:10]
You can see all the different possible states and what they mean, basically. So you can see there's like DNS lookup or something gets stalled because there's so many different reasons, it's priority or there's too many connections open. Like I mentioned before, there's a limit on the number of TCP connections that can be open at a time per origin.

[00:05:28]
So if you had seven style sheets, the seven one won't start downloading until the first one finishes those kind of things. So yeah, I think this is really incredible, quite easy to digest when you consider how complex the topic is. But just a really nice tool where you can see everything that's going on, and why it might be taking so long.

[00:05:47]
Yep, I also have brought the network waterfall thing in here. The last thing I wanna mention here is this never thinking too simplistically about things. I think we get obsessed with download time, and rightfully so. How big is your image? How long did it take to download? How big is your JavaScript bundle?

[00:06:06]
But I do think we need to remember that there's a lot more performance than that. And there's this great blog post by V8 just talk which is the JavaScript engine behind Chrome, talking about how much more there is going on than just downloading. So for example, I hear this all the time, where people will say, why do you care so much about a three kilobyte JavaScript bundle when you have a ten kilobyte image, right?

[00:06:28]
And I think I said it like an hour ago, but I was not 100% correct, because the image just gets downloaded and immediately displayed, right? You know what to do with image. You just put it on the screen, but the JavaScript has to get fully parsed and compiled.

[00:06:40]
V8 has to run it through its own optimizing, compile or generate byte code, there's a lot of work to be done after the download. So I think we fall into traps sometimes thinking too much about download speed. And I guess the takeaway that I want people to have, especially with JavaScript, is that reducing the amount of JavaScript not via compression.

[00:06:58]
But actually eliminating some JavaScript can be tremendously helpful to your page load time because there's so much more to be done than just downloading stuff. Yeah, similarly here we've got these pictures where you see how much time is spent, but so much time is spent just parsing and compiling it.

[00:07:14]
You wouldn't have that with an image, right? And on mobile devices it gets even worse where you spend over a second here just parsing this quite small JavaScript script file. Again, nothing to worry about too much just when you're thinking about things like sizes and equal amongst all asset types.

[00:07:29]
JavaScript is particularly expensive because it's more than just downloading it, and these are kinda things to kinda keep in mind.