HTTP/2

[00:00:00]
>> Steve Kinney: So a few other things that I wanna talk about on the topic of network load and then also the amount of code that we ship, is we have increasing support for something called HTTP/2 which shock surprise is the successor for HTTP/1. And it has some unique characteristics, right?

[00:00:19]
And again, it's like, should I totally optimize my strategies for everything based on HTTP/2? The answer is, you measure your traffic and then make you the call, right? If you don't find you have a lot of HTTP/2 traffic, maybe it's not the time yet, right? Cuz like we're gonna see that a lot of the best practices of HTTP/2 are literally what are called like the anti-pattern to HTTP/1.

[00:00:39]
So it's one of those things where you have to kind of like make a decision. Sometimes whether or not you support HTTP/2 is not your call to make. So for instance, like I said, we are on a bunch of systems right now that don't support HTTP/2, we're moving to a bunch that do.

[00:00:57]
[LAUGH] Like that's just a thing that's happening, right? So I have no point optimizing for them now, but this is a thing that I will likely do in the very near future. So it's an upgrade. The big thing is this idea of multiplexing. We'll talk about why that's important in a second, and also that service can push assets to the client before they're asked for, right?

[00:01:17]
So you can kind of like theoretically tie this in, like rather than parse the HTML, I need to go get the CSS file. The server can know here's the HTML file, here's the CSS file, I know you're gonna need next, start taking it now. So yeah, it solves all the problem we have in HTTP/1.

[00:01:33]
We do a lot of like weird hacks to make HTTP/1 work. Bandwidth has gone better but latency hasn't, cuz like again, electrons going through copper wire around the planet, that is a physics problem that I don't think we're gonna solve any time soon, that I know of. I'm sure there are people working on that, but that's not my domain of expertise.

[00:01:53]
But with HTTP/1, we can send one file at a time. That means while theoretically, and I'll show you the cheat that we use for this in a second. But you can send the CSS file or the JavaScript file, or one of whatever. So like breaking stuff up into a lot of small CSS files is usually not a good idea, cuz you'd have to like make any connections expensive, jam it all together in one, send it over.

[00:02:16]
>> Steve Kinney: So the way it works is normally, you get a thing, you ask the server for a thing, you get it. You ask the server for a thing, you get it. Like browsers cheat a little bit by they open like six connections to a given, and I think that changes depending on the browser, Firefox might do eight.

[00:02:29]
Don't quote me on any of those numbers. Somewhere between six and eight connections, so it can get stuff concurrently, right? And then when it uses all the six and it can go get other stuff, but you're maxed out at six at a time. So I'm gonna break my CSS into 40 files.

[00:02:45]
That's a bad idea, because you can only get six at a time, right? And so, normally we would go through these processes of jamming all of our files together and concatenating them and creating these large, large bundles, right? Which we've seen has a certain cost associated with it on the other side of the tube, when the user gets it.

[00:03:04]
HTTP/2 on the other hand, can send multiple things at the same time. So we make connections that we saw just pumping all the assets, and they get put back together when they are in the browser. So that's like major difference, makes some HTTP/1 practices not good HTTP/2 practices.

[00:03:21]
And some HTTP/2 practices not good HTTP/1 practices, just on the very nature of how the technologies work. So yeah, concatenating all of your JavaScript and CSS into large single files. Useful when you can only have a certain number of connections at the same time, not useful when you can like concurrently send multiple things and then like pull them back apart later.

[00:03:41]
Inlining images as data URLs instead of sending the image, you might make the basic 64 encoding and put in your CSS file as a giant, long string. But when you can send multiple things at once and you can predictively push things, you can't predictively push just that 64 bit encoded string, but you could predictively push the image.

[00:04:01]
So what do you do? Like, honestly, you measure, right? And for you, as front end engineers, for us as front end engineers, I care more about our asset strategy. Do we make giant files? Do we make tiny little ones, right? It's about measuring and figuring out. It's not like do you turn HTTP/1 on or off, because it is backwards compatible.

[00:04:21]
Like if your server supports it, it's whether or not you choose to take advantage of it. And so, you measure and you figure it out. So how do you get HTTP/2? And this is also the answer to the question of, how do I get a CDN? Is you use somebody else's.

[00:04:36]
So there's a bunch of services, where you put your code up there, it is on a CDN, it is supporting HTTP/2, you get everything out of the box. So the left two is now.sh and Netlify. Now .sh gives you a command line tool. You do like now deploy, and your app goes up into the cloud.

[00:04:57]
Netlify is actually pretty cool too, which is like you can install GitHub hook and whenever you merge into master, it deploys your code. That is like kind of the things I use like my own projects and stuff like that. That's probably not, I'm sure there are like large companies using both these services, like that's not what we used in 7th grade.

[00:05:14]
We use Amazon cloud front which is Amazon's, the picture I showed you earlier that's Amazon CDN. You put stuff in S3 bucket, all your traffic goes to cloud front. Like generally speaking, you can configure, you can or your app's team or whatever, can configure these back end service.

[00:05:29]
But you can also just pull a solution off the shelf. Cloudflare is another great service that provides a CDN that is supportive of HTTP/2. So like, you can basically if you choose to use one of these services, all of them have some kind of free tier. But if you choose to use one of these services, you basically get these things out of the box.

[00:05:48]
Your job as a front engineer is to think about like, okay, what are the assets you're building now, right? What other things can you take advantage of should these features exist? This slide is here basically cuz no one's going to be able to look at those screen shots, zoom in close enough to get the URLs.

[00:06:04]
So in case you wanna reference this later, here are URLs for all the things I just talked about.