Mastering Chrome Developer Tools Terminology

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Jon Kuperman: Okay, so we've got terminology. So, if you hover and hold shift over any one of these things. Let's find a juicy one,
>> Jon Kuperman: Like this one, all right. So, I'm gonna hold shift while I hover over this and I get this modal pop up. So, we've got a bunch of different terms here and each term gets its own color.

[00:00:24] On a more interesting site, like if you do this on your production site you'll see a lot more colors than just green and blue. You'll see like oranges and yellows and all that kind of stuff. So, we've got all these different terms. So, I'm gonna cover each one of them and then kind of come back and we can take a look at it because the terms matter as much as the time loaded.

[00:00:40] Cuz you need to figure out what's actually wrong. So, we've got queuing, so if you see queuing taking a long time there's a couple of things that can happen. One thing is that browsers try to be smart and they try to prioritize each item by the type that it is.

[00:00:57] So, we can see that and over here there's a priority tab, right? So, you can see is that the highest priority of the document, we need the document, you need the CSS. And then JavaScript high. It's really important but it's not as important as the CSS cuz CSS needs to be there.

[00:01:14] And then if you ended up with stuff like a bunch of images or fonts or things like that you'll see the priorities kinda going down. So, an item might be queuing even though it's an earlier request cuz Chrome doesn't think it's a very important request.
>> Jon Kuperman: It can also be waiting on hold, again, like I said you can only have so many, here it is it's six, I think I said five earlier.

[00:01:36] Chrome can only handle six concurrent requests. So, if for the very beginning of your document you have seven style sheets. The seventh one is gonna be queued, put on hold, until the six have completed. And then, yeah, this is like disk cache entries, that's not really important. Really if you're seeing queuing, it's either, it's a low priority item or it's marked that way, or it's too many requests and you can't do that one.

[00:02:00] So, that's queueing. The next one is stalled or blocking. It's like the same thing as queuing, they're very similar. Stalled or blocking also might be indicative of you having a proxy server that's slow. So if you have like some caching server somewhere and you're seeing a big stalled and blocking in a small queuing, there's a good chance that your proxy server is taking a long time.

[00:02:22] And that's what's causing it. Usually, you see queuing as the, if there's a latency it's gonna be in the queuing field. Also you'll see some information here, this is just a timestamp of how long the proxy negotiations took, so as like the DNS call goes out. I don't wanna get I guess too far in to the that working, I just want you to understand okay, I have a really wide bar but why is it, why is it slow?

[00:02:45] DNS look up, again I don't think I've ever run into this being the cause of anything slow but it is worth it. It's kinda cool that every request Chrome sends out, it timestamps each step of the process for you. So yeah, this is just like hitting a domain name service and transferring your IP to a domain name.

[00:03:03] Establishing a connection, this could be, I have never seen this one slow either, it is part of TCP handshakes. It could be failing and retrying and also how long it takes to make the SSL connection but I've never seen this one as a problem. So, if you see as a problem you're on your own but feel free to tweet at me and I help you investigate.

[00:03:25] This is just the pure SSL part of it. And then the actual time of the network request, how long the request sent. And so, it's the time that it took the server to start sending the request basically. This one is how long it took from when the request was sent until the first byte was received by the browser.

[00:03:52] And so, this is where things kind of get interesting where it's most commonly your problem is gonna be in some a slow server, a slow network connection, a big files. Here's where we really start seeing that. So, this is like I send off a request for a stylesheet and then I get a timestamp, 1:00 PM request was sent.

[00:04:11] And then time to first byte received is like 1:02 PM, obviously it would be milliseconds not minutes. But, so now you're like, okay, it took you not a lot of time to send the file, but it took me a really long time to receive it. It's probably a network issue.

[00:04:26] Or it took you a really long time to send it, I received it just fine after you finally started, it's probably a slow server. And then this is just like the actual process of those bytes coming down, so this is gonna be purely your network connection. But if you're seeing slow content download you probably don't think my gosh, my users need to be faster.

[00:04:47] You probably wanna start thing about how you can make your files smaller, right? Because if you as a web developer likely from this class in a first world country, on a powerful machine like a MacBook Pro or something. If you're seeing long content download times, you gotta believe a lot of your users are having excruciating download times.

[00:05:05] Cool, so having said that we can start holding shift and taking a look at some of these, so you can see it queued for 6 milliseconds, that's nothing, not worry about that at all. It wasn't stalled for very long either probably just the time it took to negotiate all that stuff.

[00:05:19] The request was sent basically immediately, so my server is doing a really good job. And then it's like I didn't start receiving the first byte for, I think that's really fast, 100 milliseconds. But that's like the one thing I might might keep my eye on or whatever. Is maybe I could send less or maybe I could, things like that.

[00:05:37] The content download didn't even take a millisecond, so I'm really happy with that. So, out of anything here, I mean, I think this is a great chart but out of anything here is like time to first bite was kind of what took a while, so I might start investigating that little bit.

[00:05:52] Again, on a big production app, you'll start seeing a ton of different colors. And you'll start really seeing, this file took a second to download, or something like that. And we're gonna do some examples where there are some really bad ones. So, just kind of important to go over, yeah?

[00:06:08]
>> Speaker 2: Yeah, I just wanna point out, some of us aren't seeing the priority column.
>> Jon Kuperman: So sorry.
>> Speaker 2: Yeah, if you right click on there.
>> Jon Kuperman: So, yeah. So, mine's over here. There's actually a bunch of extra columns you can add, so you can right click on any one of these and make sure that priority is checked.

[00:06:27] For those that aren't seeing it-
>> Speaker 3: Not even in the list of available.
>> Jon Kuperman: Really?
>> Speaker 2: It is for me.
>> Speaker 4: Yeah, I was able to do it.
>> Jon Kuperman: [LAUGH] Okay.
>> Jon Kuperman: Yeah, it's not there.
>> Speaker 4: It's not in your list?
>> Speaker 5: [CROSSTALK] protocol.
>> Speaker 3: I don't think so.

[00:06:42]
>> Speaker 6: Hit right [CROSSTALK].
>> Speaker 7: Jon, you have a secret version of- [CROSSTALK]
>> Jon Kuperman: Well somebody sees it, right?
>> Speaker 2: I see it.
>> Speaker 4: I see it.
>> Jon Kuperman: There we go. Sorry, yeah, I mean so again it's, [LAUGH] they move fast, things change. Priority is not really important because you can figure it out just by file type.

[00:07:03] That's really all it's doing, so it's gonna give the document the high end CSS the highest priority, because those are absolutely crucial for render. And it's going to give all JavaScript high priority because we'd like to have that stuff. And then things like Async or deferred scripts, anything like that, images, all that kind of stuff is gonna start slowly trickle down the priority line.

[00:07:24] Sorry if you're not seeing it. I'm not sure why but it is not vital for any of the stuff that we're gonna to be doing.
>> Speaker 2: Next question is how does the network tab work with HTTP streaming or WebSockets?
>> Jon Kuperman: Yeah, so basically yeah, so WebSockets will work.

[00:07:45] It basically works really well with both of those things. So, it handles like Ajax, WebSocket requests all as their own type and so you'll see a WebSocket type event in here. And each transmission from it, you'll see as a viewable, how long it took, how big it was, all that kind of stuff, yeah?

[00:08:06]
>> Speaker 8: The screenshots thing was really interesting. But you had a ton of screenshots and I have like two.
>> Jon Kuperman: Okay, I had a ton on Twitter. Because, and I didn't know that they started doing this, they're fading those images in on the home page. So there was a re-paint for every one opacity that they filled in.

[00:08:25] So yeah, screenshots are gonna be taken when an important up re-paint of any kind happened. So, on the current page that we're on there's one initial paint is all there is. On a web application there's gonna be like a ton of different paints as things go around. So yeah, mileage may vary on those for sure.

[00:08:45]
>> Speaker 8: So, it only generates a screenshot when you're re-paints, not when it loads, well I suppose it re-paints every time that loads a new resource.
>> Jon Kuperman: Yeah, so it's not gonna re-paint when it downloads a stylesheet, but it will re-paint if it applies to anything. So, if you had a stylesheet with no used rules in it, that wouldn't trigger a screenshot.

[00:09:04] But yeah, every image, every style change, every content change, all that stuff will trigger one.