Check out a free preview of the full Progressive Web Applications and Offline course:
The "Introducing HTTP/2" Lesson is part of the full, Progressive Web Applications and Offline course featured in this preview video. Here's what you'd learn in this lesson:

Mike reviews the features and browser support of HTTP/2, a revision of the HTTP network protocol.

Get Unlimited Access Now

Transcript from the "Introducing HTTP/2" Lesson

>> Mike: All right, so as we approach sort of the final punchline of this course here, I want to talk a little bit about networking. We've done a lot to improve the loading performance and the capabilities of our applications through changing our own code. But we've still been using a CTP 1,which for decades, that has been the foundation of how we send web pages from servers to clients.

[00:00:28] And where we used to be looking at Wikipedia articles,right, documents in the document view. And that was usually one to three HTTP requests, like the idea of external style sheets, that was a wild concept 20 years ago when these standards were designed. Now things look very different. Now these rich clients that we're building, they have a lot more resources and we're trying to split things apart in such a way that users have to download only what they need.

[00:01:01] And there are a lot more connections going on than we used to see. HTTP/2 is the next generation of the HTTP protocol that aims to give us some very meaningful improvements. So the first improvement you'll notice is that this is fully multiplexed. Meaning we're not asking for files one at a time with independent connections.

[00:01:27] We initiate a single connection and then we can receive multiple independent files in parallel, right? So it's not like I wanna stream you one piece of data and stop and here's another one. Servers can push responses onto client caches. And what that means is, you can think of it as, I ask a server for index.html, and it's gonna send me the HTML.

[00:01:53] And before it even gets another word from me, it'll start to send me the JavaScript, and maybe some images, and things that it know corresponds to that HTML document. And basically by the time the browser starts reading it, it's gonna say, I need this piece of JavaScript. And it'll go and see that, it's already on its way to me.

[00:02:14] It's halfway here, and I just have to wait for it to arrive. So this really makes it so that you're no longer waiting for that HTML document. Looking at that, figuring out what additional resources you need to get. And its no longer sort of waterfall approach to sending everything you need in order to get that page on te screen.

[00:02:35] That's what we mean by push, a client ask for one thing you can send that think back and push three other things, or n other things. So we already talked about some problems with HTTP/1.1, and it's gotten a lot better, right? So the average connection now is much better than it was 10 years ago.

[00:02:59] Round trip time is still kind of where it's been. And in terms of thinking about mobile networks, some rules of thumb are, if you're on an LTE connection. That is, a single digit number of milliseconds of extra latency, round trip, relative to being on WiFi or something, you've a little bit extra.

[00:03:17] For 3G, you add 1 to 300 milliseconds of extra round trip time. And then if you're on 2G connection, that's like a full second of extra round trip time. So we need a way that we're not having a serial chain of multiple request back and forth. Because on older devices and older networks, and on things that or often like Li-Fi, right?

[00:03:45] We end up having really inappropriate load times, upwards of 20 seconds just because it's so much back and forth.
>> Mike: And as I pointed out, I've had a lot of files here think about all these grocery images. Right, the HTTP/1.1 approach would have me making something like a sprite.

[00:04:09] Where I'd put all of those images under one big mega image and use CSS background positioning or something to try and consolidate those resources. I don't wanna do that, I wanna have them all as original files, so I only send the one I need. And I shouldn't have to pay extra bandwidth in order to get my number of requests down, right?

[00:04:30] Having my mega image that has 15 grocery items that I don't need, that should not be the solution. And HTTP/2 makes some massive improvements there. So here's a waterfall of view, Steve, do you remember which site this was? Dinosaur.js?
>> Steve: That is
>> Mike: 114 independent requests in order to get that page loaded.

[00:04:52] That's one per image, one per external stylesheet, script, fav icon. All of these little things add up. If you're using WebApp manifest, that is a separate request there. If you're using an AppCache, that asset manifest is a separate request. It adds up really, really quickly.
>> Steve: And I will say that is like average.

>> Mike: We're not trying to shame here, this is a real number here.
>> Steve: Most pages that I looked at for this screenshot were in that same number.
>> Mike: Absolutely, but it's pretty terrifying when you think about the overhead for each connection, right? So what this has led to, the fact that we're building on this same HTTP/1.1 protocol.

[00:05:35] We've been using it for many decades,is we've learned to stick to certain conventions. And we've learned certain hacks that we can use in order to avoid letting this hold us back too much. So one of them is reusing connections and that just means having many things hosted on a single domain.

[00:05:59] So you can establish that TLS connection, and get your DNS resolution out of the way, and then hit that a few times. The modern browsers will allow between six and nine simultaneous connections per domain. So if you need more than that 114, right? We need to shard our resources, so that we can download like two pieces of JavaScript from this one thing and six images and time from this other thing.

[00:06:29] And if you look at something like webpage test, and that was a screenshot of webpage test there. And have a lot of images on the screen that are all competing for this connection. You can actually watch that six start and then one has to finish before the seventh begins.

[00:06:45] So it's almost like you have a pool and you cannot go over six. This is really bad.
>> Mike: So, the good news is that HTTP/2 from our standpoint as developers, is largely not something that we need to worry about. All of the HTTP/1 work we've done will also work in HTTP/2.

[00:07:08] This is really important for adoption, because it means that companies like ACMI and CloudFlare that can upgrade their CDNs. And they can start to roll this stuff out without waiting for apps to retrofit something. All of your stuff should still work, but the big differences here are that we can send multiple files over one connection avoiding that repeated overhead.

[00:07:36] And we can bake information that we know at build time about certain types of requests and proactively push resources to the client that we know are part of that. So if you've heard of code splitting or route splitting, the idea of on an orders page, we need maybe some extra JavaScript there or some style that only pertains to that.

[00:08:02] That would only be included if that's what's going to be on the screen. And we can push that extra CSS file and that extra JavaScript file. We can sort of slice things up very smartly and not pay the typical price of having so many different files to download.

>> Speaker 3: You mean instead of bundling but lazy loading different parts of the app. Is that what you mean?
>> Mike: So bundling is important because that's how we're going to get all of these files. But if you have 50 different routes in your app, 50 different meaningful URLs that people had.

[00:08:37] You can end up with one JavaScript file that represents the core stuff that you need regardless of route. And then a per route file that when combined with the core is like everything you will need for that URL. When we start talking about architecture patterns in a few minutes.

[00:08:57] That basically lets you get away with sending, only if the JavaScript, and only if the CSS that's absolutely needed from the server to the client, in order to get that page rendered as quickly as possible. But that involves slicing things up very cleverly, if that makes sense, and then lazily loading others.

>> Mike: So this concept of pipelining versus not pipelining, this is just the idea of this concept of HTTP/2 push, right? So on the left with no pipelining, this is the HTTP/1.1 idea. Where we kind of ask for index.html and then we discover that we need the CSS. And only at that moment does that new request go out.

[00:09:47] On the right, we know about these things. We've built the applications, and we can package things together and we know exactly what's gonna be required for our app to render. So, in terms of browser support, this should be quite encouraging. This is something that has been worked on for a long time.

[00:10:10] And it is supported basically everywhere that you care about. Even looking at IE, because back to IE11. Often times the way you're gonna wanna set this up, particularly if you use Node, it's not safe to have Node open to a long living connection. Cuz remember we have one thread, it's not more safe to let Node have a long connection.

[00:10:35] Where it's pipelining a bunch of files back than it is to have it reading a QR code for 20 seconds. It's locked up and busy doing one thing. Which prevents it from exercising its super power of doing a bunch of multitasked tiny things that have a high degree of concurrency even though there's no parallelism.

[00:10:55] So typically what you'll do is you'll have HTTP/1.1 on your application server. And then you might have an Edge server, like Engine X is a popular one. And that will act as what's called an HTTP/2 proxy. And basically take care of transforming the stuff in the data center into H2 pushes to clients.

[00:11:19] So oftentimes the browser will be able to hit that with either protocol. And if they don't support the new stuff, if you're using IE 10, often these proxies will have no trouble just passing straight through and stepping down to the 1.1.
>> Speaker 3: So this raises an important question.

[00:11:40] Not important, I mean it's interesting to me that what is the adoption gap for?
>> Mike: So when you talk about an adoption gap, there are a couple of different adoption things that need to happen. And in order for us to really take advantage of HTTP/2, a lot of infrastructure has to be converted over.

[00:12:03] The first adoption gap was CDNs like Akamai, right? Where it doesn't matter were your little Engine X server does what it's supposed to do. Or if you're on Amazon and you've got an EC2 machine and you have installed an H2 server and you're serving it up. If you're going through CloudFront or going through their network infrastructure, if at any point along the way there's something that only supports 1.1, you're stepped back down to 1.1 when talking to that browser.

[00:12:33] So you need the devices to support it, you need the Edge network technology to support it, you need the CDNs to support it. And we are finally there. There's really no excuse for adoption, other than that developers need to know how to take advantage of it. In most cases, if you're serving from CDN, it's already using HTTP/2.

[00:12:56] But in terms of like asset serving layer, like this thing that we've been hitting localhost 3000, that's where we need to start as developers adopting technology like Webpack. And working things into it that help us initiate the push, right, initiate that pipeline request. Cuz our CDN can't help us with that.

[00:13:17] That has to happen right at the heart of the application as we serve up the next.html.
>> Speaker 3: So are there any good libraries, or is it like you still use the Webpack, but you do things differently?
>> Mike: So if you use Firebase's style of coasting, all you need to do on your HTML documents is add a couple little headers.

[00:13:37] You have to work with the link header and you can go and look at the documentation for that. Or maybe in the Firebase course, we may or may not have that in there. But it's pretty easy,and again, you just have to leave some clues and then serve it up in HTTP/1.1.

[00:13:54] And then if you handle assembling those clues like the special header, then at the CDN level, Firebase's edge servers will take care of optimizing that and pushing the resources that you specify in the headers. So really the adoption problem is over, now it's about developers taking that next step and taking advantage of what's available.