Network Performance Q&A

[00:00:00]
>> What is the correlation between priority and waterfall?
>> The waterfall will show the actual statistics for that particular request, right like that request. But the priority is how the browser chooses which order to fire things in. So if you have a lower priority item, you will see that it spends time either queueing or stalled.

[00:00:23]
If you have more than six, both conditions have to be met. If you only have six total items, the lowest priority gets fetched at the exact same time as the highest priority. But if you have more than six requests, that's images, scripts, CSS, all that stuff, then you'll see lower priority items will spend time queuing whereas higher priority items will not spend time queuing cuz they'll go right away.

[00:00:44]
>> So for the waiting, that's specifically an issue with the server side code, or it could be like you said something with the database, that's it, and usually you have to look there to find a way to speed it up?
>> Yeah, that's a great question, so time to first byte and waiting, are those always server side issues or could they be front end issues?

[00:01:02]
I mean, technically it could be front end if your connection is so bad that a byte takes a while, there could be some issue there, right? If you're on a really, really weak connection, your time to first byte will be slow as well.
>> But typically, since it's such a small amount of data, if you see a slow time to first byte, it usually means that between the server getting the request and giving the very first piece of data back is taking a long time, something in there, whether it's server processing the requests or something in the database or something like that.

[00:01:33]
It could potentially be something's slow for you, but for example, if other websites are loading great for you and then your website has got a slow time to first byte, that's almost guaranteed to be a server issue.
>> And did any of these also take into consideration the user's machine?

[00:01:52]
>> So they don't normalize data, they won't say for you this is doing what, Lighthouse for the audits will do something kind of like that. They'll say, this is pretty good for a slow device, something like that. But these are just going to show simply the time taken.

[00:02:09]
So if we do a refresh here, it's just gonna say, how many milliseconds it's spent at each phase. So it's spent six queueing, DNS lookup was four milliseconds, and then you can see that the time to first byte took 60, which is very fast, but you can see just pure milliseconds.

[00:02:26]
So no, it doesn't normalize the data at all.
>> I have a question. What is the initiator columns about? Yep, so the initiator is who requested that. So if you think about you have an HTML file that has a script source main.js in it. So main.js' initiator would be index.html cuz index.html is what called that.

[00:02:52]
And then if in that script source you did a fetch for food.jpg, then food.jpg's initiator would be main.js cuz that was who initiated it. So it's like, why did you call this thing? It's like, so it's like this one, we have this, give a refresh here, we have this network.html.

[00:03:14]
So we have network.html, that was initiated just by the server, right? That's always the the main thing you get is an HTML file. But then if you look at all these, you can see the initiator network called the JS, network called the PNG, network called this CSS file.

[00:03:30]
But the CSS file called these other two CSS files, so you can see the initiator is different for that.
>> I just had a question. So if we do a cmd F on the network panel, there is a drawer which opens up to the right. I was wondering how can we use that, this one, yeah.

[00:03:49]
>> So this one's kind of interesting. So you have kind of two options here, you have one is the option just to filter, to kind of filter this list down, right? And so you can do things like if you search for net, you can do something like that.

[00:04:03]
You can also do, I think it'll support some amount of regular expressions or whatever. Yeah, the other option that you can do is you can do this kind of more advanced search by cmd+F or ctrl+F. And now when you search for things in here, it'll actually parse all the response data as well.

[00:04:21]
So you can like a lot of these will have headers. So basically the filter here is gonna search your names, right? That's what it's gonna search. The search bar here is gonna search the names, all the response headers, all the request headers and the resulting response body itself.

[00:04:37]
So you can really kind of filter through. We're almost done with the network, but I do have one call out that I like to do which is rightfully, we obsess about network performance. It's a good thing to obsess about. And the faster you get your site, the happier users will be.

[00:04:51]
But I do feel like sometimes we get really carried away with this idea of, and actually the Gzip question is a great segue of, well, if we can just really compress everything and send it over, then we've solved our problem, right? So we'd take this gigantic thing of JavaScript and we compress it and send it over the wire and that's great because it's fast over the wire.

[00:05:11]
But I do want to always caution people that as we compress more and more and as we send more and more JavaScript specifically instead of images over the wire, parse time becomes a really big bottleneck as well and it's something to keep in mind. So the idea with compression being you take a JavaScript file, it's 10,000 lines long, you run it through Gzip, and you get a much smaller file, which is great, cuz smaller files travel faster over the wire, but they have to be uncompressed on the client's machine, right?

[00:05:43]
Their browser will uncompress it. And they still have to parse that giant amount of JavaScript. So I do think that compression is great, we should compress everything. There's a lot of websites that are Gzip everything or whatever and they'll check a website to make sure that everything is being compressed and Brotli is even faster.

[00:06:00]
But we need to keep in mind that at the end of the day, we really should be trying to limit the amount of JavaScript that we send over the wire too. Those are always huge wins because even if we can get the network request quick, the parse time is really substantial.

[00:06:15]
There's this post by Addy Osmani here that I linked to, which is well worth the read on itself, but it's called JavaScript Startup Performance. And it's just all about kinda like the cost of JavaScript. So I took this picture from it, which I really liked for people that want a better idea of how kinda these things work like after the JavaScript makes it over the wire and is uncompressed.

[00:06:37]
It still has to get parsed and turned into the DOM tree and it gets compiled and optimized. All this stuff has to happen on this large amount of code. So while we shrink our images and bundle and shrink our JavaScript, all that, trying to send less JavaScript over the wire is vitally important to speed.

[00:06:54]
And you can do really cool things. You can asynchronously load bundles. There's a Webpack Frontend Masters course where Shawn shows how to split your bundles up and only load what you need at page load and bring stuff in. So there's a lot of different ways we can think about it.

[00:07:08]
Network's really important but parse time is really important too. And there's a little graph, the same JavaScript file. So you're on your nice desktop computer and it takes 200 milliseconds, which is well within a fine range for everything to parse, but you move over to a mobile device that has a worst CPU and it can take over a second to parse the exact same file.

[00:07:26]
So just to call out on that stuff. Cool, any questions about that?
>> When you go to the size, right, when you're in your Network tab, you're looking at the size column. If I were to refresh this page right now, and not a hard refresh, but just a refresh, I don't see it on your screen, but I see some assets showing up as dis cache [CROSSTALK] memory cache?

[00:07:54]
>> Yeah, I have this cache disabled. So if I unclick that, yeah, so these are just things that the browser has been able to optimize for you. So these items that are just CSS file items that are just being cached on your disk, so they won't have to load.

[00:08:11]
So you can see the page load time goes down to zero milliseconds. This is similarly true, you'll see it if you cache responses to yourself, right? So if you set cache headers on your network requests, then you'll see those reflected there as well.