Network Optimizations

[00:00:00]
>> Jon Kuperman: We already got a little bit of a primer on this. I just wanted to cover a few more things, kind of in depth. In particular, the DevTools I find is like a really excellent tool for understanding. Like, again, I should tag these with like areas where DevTools can make you a bit magic on your team.

[00:00:15]
I think network optimization is another one, because even as a front end developer the DevTools can really help you do things like go to your API team and say, hey, our TLS handshake is taking longer than normal. And they're like, what? And it's like, actually, DevTools just told me that.

[00:00:30]
I didn't really know that otherwise. But it's really cool because it shows you really fine-grained not only how big something is and how long it took and whether it was cached, but also where the time was spent. How fast your service is, how fast the user's connection is, how long it took doing various things like HTTPS is really, cool for stuff like that.

[00:00:48]
This is a diagram of the typical website waterfall, right? Think a lot of people probably see this if you run the network tab and hit refresh, you see first there's some block of the initial document, right? The thing that your HTB server sends down first is like index html, and that has to come all the way down.

[00:01:05]
With some varying tricks you can do like HTML streaming and you can do partial responses, but the document comes down. As the document gets parsed, we see our, ignoring the content, we see all of our links to style sheets like our, our link res, and then we see our scripts to JavaScript.

[00:01:20]
And then from those we need to go out and we need to fetch those things, and those are what we call, kind of critical assets, right, anything up in the head tag. Have you seen this before, where people are put my JavaScript in the head tag, because it's really important for ads or tracking or analytics.

[00:01:33]
So anything in there is marked as critical and downloaded immediately. And then as it kind of gets assume, we can parse things out of the body tag, we can parse more JavaScript and CSS. And then eventually we start hitting these async API calls, stuff like that. So we get this kind of what we call the waterfall.

[00:01:51]
And there's all these tools out there, which we will cover, where you as a developer have fine-grained control over waterfalls that we didn't used to have. But, yeah, it's important to know, document comes in, then critical stuff, and then asynchronous stuff. And these network packets, for those who haven't inspected before, which we can do inside the inspector, they're plain text content.

[00:02:11]
And they're basically like, they have these start lines which are the request itself and the response. These are HTTP headers, and they show a bunch of different user agent and stuff like that, and then the body comes down. And so we'll say, hey, this website is posting to your API.

[00:02:26]
And then you'll say, cool, they're forbidden. And then I'll say, okay, I'm not gonna let them in, basically. And so everything is this kind of like request, response, transactional relationship between clients and servers. And this is true outside of language and outside side of tech. This is just how these applications kind of work together, regardless of what programming languages or frameworks you're using.

[00:02:45]
Again, we have this thing, this concept I mentioned this in the last section, but that it's more than just downloading these things, because they interact together. And so we have to download the HTML, and we have to turn it into an inline, a JavaScript object. Then we get the CSS, we turn that into a CSS object, and then we start applying these things together.

[00:03:04]
The CSS applies to this or this JavaScript adds a new H1 or all these things kind of happen. And eventually, we end up with one render tree, which is like basically the document after all of this stuff has kind of happened. So it's downloading, it's parsing, and then it's building up these trees and applying them.

[00:03:21]
And then we apply the style, and we do the layout, the paint. The browser handles all this stuff for us. But the important thing to know is that we are often bottlenecked by the fact that the browser can't know where things go until it has applied some of these things like CSS, or JavaScript to the document object.

[00:03:36]
One caveat for all this stuff is browser caching. So you can make heavy use of browser caching, and then there won't be network requests for those things. So you can cache your static assets. You can cache large assets, small assets. You've got all sorts of options here for browser caching.

[00:03:51]
The network tool will help us in a large way, seeing what's cached and what isn't cached. Has anybody played around with any of this compression in the browser before, like gzip brought Lee, have you heard of these things before? Okay, so these are a really cool concept. So it's very high level.

[00:04:04]
We have this idea of compression in computer science, totally outside of web, where you can take something like a song, you can make it a bit smaller, when you zip up a file, right? You've compressed this file. And the only real rule is that the person on the other side needs to have sort of the same tool in order to unzip the file, right?

[00:04:21]
I can't just make my own zip format and send it to you, you won't be able to extract it again. And so we have these kind of agreements, like the zip format or whatever. But the web has these agreements too. They have compression formats which the browsers all have an ability to decompress.

[00:04:36]
And so the most popular one still is gzip. And so all browsers have the ability to decompress a gzip file, meaning that you can gzip all of your files on the back end, less stuff transfers over the wire, and then the browsers can decompress them. And over the years, we've come up with a lot of different kind of tools.

[00:04:54]
So we've got the new the kind of newer tool is broadly which all browsers also have these are all done in standards bodies. And Brotli, you can get even smaller files, so less over the wire, which is really great. But all these things are trade offs, of course, right?

[00:05:09]
And so one of the things with Brotli is that the compression time for Brotli, as you can see in this middle slide here, takes a lot longer to make the tiny Brotli file than it does to make the Gzip file. That being said, decompression time is quite fast with bro, so you've got all these trade offs basically.

[00:05:24]
I think this usually comes into play, like, if you're building like a no JS app, you'll have your framework like Express or something like that. You'll have these abilities to add cache or to add minification, or to zip up these things. So you can get, you can install an express plugin for Gzip for an expression plugin for Brotli.

[00:05:41]
But we will be seeing this stuff. So basically, I think the takeaway here is that as a full stack dev, you have quite a lot of ways that you can make things faster without reducing the number of lines of code by compressing these things. And then a caveat on that, because I don't give good things without bad things, is that it is important to keep in mind again, that we're trading off here, that yes, you can make it smaller over the wire, but you are adding this work then of having to decompress it before it will run.

[00:06:09]
So there are definitely certain cases where it might be just better to serve the raw thing itself because it'll have a smaller parse time. But I do think in general, G-zipping assets is just like an all around. Thing to do, I think that if you're building a full stack app, you should use Gzip, or broadly, and you should compress all of your assets.

[00:06:25]
So there's kind of this, like magical way that you can compress things. The browsers know how to decompress them. I know you all said you're new to this, but does that make sense, kind of at a high level, this thing? Okay, great.
>> Speaker 2: You saw all of these on the CDN, like each version of each compression or how do you handle?

[00:06:39]
>> Jon Kuperman: Yeah, I think if, that's a great question. So I think that you would choose you like, I think I would choose one. I wouldn't do both versions of a compression because the browsers don't have any way of choosing between them, and so you would need to kind of pick your compression technology, yeah?

[00:06:52]
But then, yeah, you could store these things on your CDN, and then there'd be just so much less going over the wire, which is nice. Got question, sorry.
>> Speaker 3: Often with compression, we lose something, is that same here?
>> Jon Kuperman: Lose something like, yeah, this is a great question.

[00:07:08]
Yeah, so you have two different theories in compression. You have like loss full, is that what it's called? And then lossless compression. Yeah, so these would not, these do not lose like in for your files themselves, you are not gonna lose anything. The source code will come back 100%.

[00:07:23]
That being said, when you think about images and things like that, you will often be having to chose compression algorithms. Some of them, you will lose some of that granularity when they come, yeah. So for your source code, there's no loss to your source code. This is loss-less, it will reassemble in the exact way that it came.

[00:07:39]
That's a great question. But yeah, with images there's like a whole world out there where you can super compress. Some people do really fancy things, where they losslessly, really compress it so it first loads in a little grainy. And then in the background, they fire another task to the CDN to get the lossless one and then swap it.

[00:07:55]
There's all sorts of cool stuff you can do with different loss lossy levels. I might be getting the terminology wrong, but yeah.
>> Speaker 4: Lossy.
>> Jon Kuperman: Is it excellent for the source code? Yeah, no loss, you get all the source code back the same way.