1. Introduction to HTTP 3
Hello there, I'm Robin Marks and I work at Akamai. And I'd like to talk to you today a bit about HTTP 3, which is the latest and greatest version of the HTTP protocol.
And as you can see, it's really quite a bit different from HTTP 2. One of the big changes that happened was that we no longer use TCP underneath. But we've moved to a new transport protocol called QUIC instead. QUIC itself, which runs on top of UDP. You don't really need to know all of these details.
The main thing you need to know for today is that QUIC and H3 have a lot of new performance-related features on board, things that make it quite a bit more efficient than H2 and TCP, as such as help your web pages load quite a bit faster. Now, you might think, oh, this looks interesting, but it's probably going to be a lot of work for me, right, to start using all of these new features. Well, that's where the good news comes in. That's not true. Basically, if you just enable HTTP 3, which is often just the flip of a switch, you get all of these features out of the box. In fact, you don't even have to change anything about your web pages to make optimal use, as long as you're already tuned for HTTP 2, which, to be honest, after eight years, you really should be. This should work just fine on HTTP 3 as well. So, this is quite good. You can get all of the benefits with not a lot of work.
2. Zero RTT Limitations
The browser and server determine the zero RTT limitations for security reasons. It's often limited on many deployments and has restrictions on the types of requests allowed. The lack of control can lead to the browser sending incorrect requests, resulting in wasted potential. While you get the features for free, it's not without limitations.
This is again something the browser chooses for you. And in this case it's not just the browser, it's also the server that is going to be holding your hand. For some complex security related reasons, zero RTT is often limited quite a bit on a lot of deployments. So for example, the code that I have here says that you can only use get requests without query parameters in a zero RTT request. Which as you might imagine, really lowers the amount of use cases you can use this for. For example, it's kind of useless for most API related requests. And again, the thing, because you don't have a lot of control over this, it might be that the browser gets it wrong. Browser sends a wrong type of request in zero RTT. The server will then reject that and the browser will have to retry it after that first round trip. Kind of wasting the potential of zero RTT. So yes, you get all the features for free. But it's not all amazing as it might seem.
3. Resource Loading and Prioritization
I want to talk about how we load individual resources on a page and how we prioritize when those should be loaded. HTTP 3 uses a simple mechanism to assign priorities to resources, but there are some problems with this approach. Browsers may not agree on resource importance, and their prioritization may differ from what developers expect.
Now, of course, I don't want to just talk about things you can't do with H3. I want to talk about things you can do. So the browser kind of shields you from these internal details. The protocol is kind of a black box. But it does give you these somewhat higher level features that you can use to tune some of these behaviours. And I'd like to talk about some of these with you today.
The first one is going to be about how we load individual resources on a page and how we prioritize when those should be loaded. As you probably know, HTTP 2 and also H3 use only a single network connection to load all the resources. This means we need to somehow decide in which order the resources are actually loaded on that one connection. You might think of a very naive solution which is going to load them in the order that they appear in the HTML but that would be rather inflexible in practice. And you can also see that there are many different options in which you might decide to send these resources. It doesn't just have to be back-to-back sequential.
So what happens in practice? Who decides how this gets done? Well, this is of course the browsers. For every request that the browser makes it is going to assign what is called a priority. An indication of the importance of the resource when it should be loaded. At least in HTTP 3 this is a very simple mechanism. It's just an HTTP request header with a very predictable name – priority. You can even see this in the browser dev tools. A priority has just two parameters. An urgency parameter which is kind of just a number indicating the importance and then incremental saying if this resource can be mixed with data from other resources or not. Now the details are not very important for us today.
What is more important and interesting is that there are a few problems with this approach. First of all, the browsers don't necessarily agree on which resources should be most important. And secondly, even if they do agree, they might come up with a different solution than what you as a developer might intuitively expect. So let's look at some examples for this. So I looked at how the browsers did this prioritization a couple months ago. And here you can see the top line. All the browsers kind of agree that HTML is indeed a very high priority, kind of important for loading a web page. That's logical. Same for CSS, the bottom line here.
You can see that the browsers agree it's quite important. Though it's a little bit more important in Chrome than the other two. But things are very different for fonts. For example, Firefox really does not care about your custom fonts marketing department, which is kind of the opposite of what Chrome is doing, which assigns the highest possible priority to the fonts. So there are already big differences here.
5. Fetch Priority and Resource Discovery
You can use fetch priority to control the loading order of different fetch calls. It's currently only available in Chrome but will be implemented in Safari and Firefox. Resource discovery can be improved by using 103 Early Hints, which allows the browser to discover resources before the HTML is generated.
But the second thing I wanted to talk to you about is resource discovery. Because of course we can only prioritize resources that we have identified as being needed. Now, usually, you know, how does the browser discover stuff? It's in the HTML. So if the HTML is slow to be generated, if we have a high time to first byte, the whole page load is also going to be slowed because the resources are discovered late. Wouldn't it be great then, if we could somehow do something like this, where we could actually have the browser discover the resources much earlier, even before any of the HTML comes in? Sounds magical, right? This is actually a feature that you can use in some setups, even today. This is called 103 Early Hints. Now, the setup I'm using here today, the example is that we are using an edge server, right? CDN something like CloudFlare or Akamai, or if you're very hip, Vercel or Netlify. This means that the browser will connect to the edge server.
6. Edge Server Fetching and Preloading
If the edge server doesn't have the HTML in cache, it fetches it from the origin. During this time, the edge server can send back 103 Early Hints, which is a list of links. The browser can then start preloading these files, so by the time the HTML arrives, the browser already has critical files. Preloading and preconnecting to third-party domains is also possible.
And if the edge server doesn't have, let's say, the HTML in cache, it needs to go fetch that from the origin. While that is happening, the edge server can send back to 103 Early Hints. And what this is, is really just a list of links. This is really, again, just preloads and preconnects. Usually you'd put those in the HTML, but of course, we don't have the HTML yet. We're waiting for it to be generated. So here, we just put these in the HTTP response headers directly. What then happens, the browser gets these links and it can then start preloading these files. So that by the time the HTML actually comes in from the origin, the browser should already have large parts of your most critical files. So this is what makes this magic happen, and it gets even better because you can even preload and preconnect to third-party domains as well.
7. Static Domain and Server-Side Rendering
You can open a new connection to a static domain and load more resources while waiting for the HTML. This relies on slow HTML generation, which is more common with server-side rendering. I suggest moving back to server-side rendering and dropping client-side rendering.
8. Introduction to Web Transport
Web transport is a powerful option for real-time use cases, providing low-level access to QUIC and HTTP3 features. It allows you to choose congestion control algorithms, send unreliable datagrams, and access raw HTTP3 streams. When combined with upcoming web features like WebAssembly and WebCodecs, it enables efficient data processing and rendering. However, WebTransport may fall back to HTTP 2 if HTTP 3 is blocked, and the browser abstracts some details. Overall, HTTP 3 offers high-level features and exciting possibilities, including 103 Early Hints and Web Transport.
Now the last thing I wanted to talk to you about is something called web transport. I've talked a bit about the Fetch API, and that is usually most of what you need, but for some use cases, especially some are live real-time use cases, you need a bit more power. And up until now, you would have to use something like web sockets over TCP or if you really needed UDP or unreliable data, you could use something like the WebRTC data channel for this. Both work, but especially the latter one is kind of difficult to use. It's not very intuitive to really get set up, especially in a client to server context.
Of course, there is always a catch. You might've seen this in one of the earlier slides. It's not raw HTTP 3 because some networks will actively block or disallow HTTP 3 in practice. So WebTransport will fall back to HTTP 2 if it's not available. And at least for now, the plan is to give you access to datagrams even on HTTP 2 even though they're not really unreliable. So, you know, something to watch out for again. The browser abstracts some of this sometimes a bit too much. With that, it's time to conclude this. I think it's clear that HTTP 3 is indeed a very powerful protocol. Even though you can't do much of it, there are some high-level features that you can use. Some of them are quite complex like prioritization and depend on the browser, but others should allow for many new, interesting use cases like for example, 103 Early Hints and especially Web Transport.