Using the Network Tab

[00:00:00]
>> Jon Kuperman: All right, so we'll move into the Network tab. So the Network tab can be a bit more overwhelming, so we'll do a refresh with the Network tab open and we'll get kind of a lot of different stuff. One thing I kind of like to do pretty often is, you can see in this section here, there are a lot of optional things.

[00:00:16]
So maybe deselecting the optional things for now just to try to make the page as simple as possible, knowing that we can go back and add these things later if we need to. So with all of the options deselected, we can see that this page has only two HDP requests that come over.

[00:00:32]
So the document itself, and then this style CSS page, you can click on anyone and you can see what the response looks like. So the document is HTML and the CSS is CSS. You can do some kind of cool things, you can hold Shift while you hover over an item and see who called it.

[00:00:49]
So if you think about the way your page normally loads, it's like an HTML file comes in and it has script tags to JavaScript or link tags to CSS. And then it kind of goes from there, but you can have JavaScript that fetches other JavaScript or JavaScript that fetches CSS, blah, blah, blah, so Chrome kinda keeps track of all this stuff.

[00:01:05]
So if you're like, well, where did this style.css come from? You can hit Shift and hover, and it'll highlight in green the About pages where it came from. A lot of the important information, I think, for the network tab when you're first looking is down here. Unfortunately, I can't zoom that in any longer, but it says how many total requests, how much was totally transferred?

[00:01:24]
How much in total resources was downloaded? This is a bit of a nuanced thing that I get questions on a lot. These numbers will often be very close to the same, but they will often be different, and there's a few reasons for it. One of them is that things can be cached, which we'll talk about later.

[00:01:40]
So you could imagine that you have a service worker or that you just have a heavy caching policy on your images, your CSS, something like that in which case the resources downloaded would be much smaller. It's also important to keep in mind that a lot of this stuff, the transfer over network is give and take.

[00:01:58]
And so instead of just the resources downloaded, which is just like what the browser took from the server, the transferred will also have whenever a fetch request is made or anything like that, the amount of data sent. So if you have a lot of data being sent and given, then your transfer will be a lot higher than your resources.

[00:02:16]
But I think they're both good numbers to It's kind of keep in mind about how much really went over the wire. And then you've got how long it took to finish the page, and then you've got these kind of Dom content loaded and load events. I'm not sure if anyone's ever messed with these in JavaScript before, but you can do on load or on Dom content loaded.

[00:02:35]
But they're essentially how long did it take for the actual Dom content, which is the HTML, CSS, all that to come down, get applied, and then how long until the final page loaded. They were put together, the JavaScript was applied, things like that. So this is kind of a nice overview at the bottom of how many requests, how much data went over the wire, and how long did the page take to assemble, essentially, are what these are showing you.

[00:02:57]
All right, so from here, we can see in this main table, we've got quite a few columns. One nice thing to note is that if you right-click on here, you actually have 100 more columns that you can add depending on what you're doing. If you're doing security specific things or if you're doing a migration from HTTP/2 to HTTP/3.

[00:03:14]
You can get all sorts of great information from here, but we're not gonna cover it all for now, just know that there's a lot more here. So you can also see how big everything was, how much time each item took to load, and the priority given to it by the browser.

[00:03:27]
We're gonna get into priority when we cover the network section later, but just kind of good to know that it's there for now. So if we go ahead and we clicked Screenshots, we'll come into one of the first sticking points I find of the DevTools that get people confused sometimes.

[00:03:41]
So when the DevTools themselves are open, even though to us, the website is still very much there in the background, right? We know that, let's see, performance, this Performance tab. We know that the Performance tab is there whether or not the DevTools are open. But the truth of the matter is that Chrome will only do the work of rendering what needs to be shown to the user, right?

[00:04:02]
Chrome is very lazy in this sense. And so when you have the DevTools open on the left side, right side, or bottom, it is important to remember that even though we know the website is there underneath, it's not doing any of the work to render that website. So when you do things like screenshots and you click on one of these Screenshots, you will see that the screenshot is, in fact, only showing that little bit of the website that actually was needed to render.

[00:04:27]
So the kinda caveat there is whenever you run into anything like this, the thing to do is to go over here to these three dots and to pop the DevTools out. Now, with the DevTools popped opt out, nothing is blocking that from rendering, so we can go ahead and Cmd+R to refresh again.

[00:04:42]
And as the page comes in now, we will see that the screenshots have the entirety of the web page. This is also true with like the Performance tab. If you have a really fast block, a text, then you have a really slow block, a video game, and you have the DevTools up over hiding the slow block, then Chrome will not spend all that work rendering that stuff because it's lazy.

[00:05:03]
And it says, I know that that's not being able to be seen by the user. So again, sometimes when you're doing deep audits, it can be a little bit tricky if you have the DevTools covering a bit. And then you're confused why it's not highlighting the performance, or the network traffic, or the screenshots of that bit.

[00:05:16]
Hopefully, that makes some sense, yeah.
>> Speaker 2: Is that the viewport then, or how is it looking at?
>> Jon Kuperman: Yeah, so basically, as far as Chrome cares, it goes by its viewport and the DevTools being open then shrinks its viewport. And so it does an intelligent pass to say, okay, I only have 100 pixels open what needs to be in there, and that's all the work it does.

[00:05:34]
It doesn't truly not do the other work like it'll obviously need to do some compute and processing, but it is important to think about that this lazy system based on. Similarly, if you've seen one of those blogs where the image is only load when you get into the screen, it's doing the same kind of thing, where it's like, if this isn't shown to the user, then I don't need to do this work.

[00:05:53]
>> Speaker 2: If you sort the incoming requests, for example, by name, how do you get back to the default sort?
>> Jon Kuperman: Let's try this out on a real website. This is a great question. So if we go to google.com, which I'm hoping will have a fair amount of network requests.

[00:06:06]
Okay, so this has a bunch of network requests. And we can see that the first thing in is the document. So yeah, if you're in and you're clicking around, and you get into some state and you wanna get back to the way that things were the first time, you can right-click on this.

[00:06:21]
You can go to Sort by and then you can sort by waterfall, which will be the initial loading waterfall that the network came. I love that question. Yeah, cool, I learned something that's amazing. I never seen that before. That is the Network tab. I think the last thing that I wanted to point out here is that when you click on an item itself, like this markup, you can kind of see all of the request and response headers here.

[00:06:45]
This maybe doesn't come in handy all that often, but it can be really good if, for example, you're a full stack dev and you're building your backend service and you're setting cache expiration or something like that, or you're setting a CORS header. And you wanna verify that the CORS header is being set correctly, in those cases, it can be really nice, or if you're doing a bunch of E tags for images or something.

[00:07:06]
So anytime that you're messing with headers on the server, this can be a really nice way to check the response headers and make sure that they're coming in correctly. I guess similarly, when you're doing fetch calls from the client side, if you're passing in any type of header information verifying that they actually come through, here can be good too.

[00:07:22]
And then you can kinda see a preview and the actual response that comes back, as well as all sorts of specific timing on how long it took and where that time was spent. We will get into this during the network specific section.