HTTP/2 and CDNs

We’ve been covering HTTP/2 since its introduction as SPDY. And now that the HTTP/2 specification has been published, service providers, software vendors, and network administrators are gradually rolling out support for it.

MaxCDN will start supporting HTTP/2 in 2016. But, until that time comes, you can still maintain an HTTP/2 connection over your server and others that support it while delivering content with MaxCDN. We’ll talk about this more below, but first let’s quickly review HTTP/2.

Why HTTP/2 is Good News

HTTP/2 essentially offers better performance and lower bandwidth usage. It also makes life easier for web performance advocates and developers as it removes the need for domain sharding and other HTTP/1.x workarounds. Some key features of HTTP/2 include:

• True Multiplexing: Multiple resources can be loaded in parallel over a single connection.
• Header Compression: This reduces overhead by avoiding TCP slow start and getting all headers out “on the wire” within one round trip (compared to 7, 8, 9, etc.)
• Server Push: Your server can push requests it thinks the client will need before the browser parses the HTML and sends requests for embedded assets, thereby reducing round trips.

As of early 2015, 9% of all Firefox connections negotiate over HTTP/2 and 45% for TLS connections over Chrome. Given the newness of HTTP/2, these numbers are pretty astounding and will only continue to grow.

What You Need to Know

HTTP/2 improves load time, but that doesn’t mean CDNs are no longer relevant. HTTP/2 makes many improvements on the format of web content, but it can’t change how close content lives to the end-user. Only servers and caching can do that.

1) Don’t Axe Your CDN

In most cases, long loading times are caused by high latency. Keeping a short distance between you and your users can have a far greater impact on performance than any optimizations made to your backend. By using HTTP/2 over a CDN, you’re ensuring that users can access your content as quickly as possible.

If you don’t want to just take our word for it, take Google’s Ilya Grigorik’s word. And if you need further reassurance, take web performance advocate Guy Podjarny’s word that reads:

“I don’t know what makes people think HTTP/2 would remove the need for a CDN, but I’ve heard this statement from quite a few people. The short statement here is – no, HTTP/2 would NOT take away the need to have a CDN.

“It’s true that request multiplexing would mitigate the cost of having high latency to your server, but a 20ms round trip time (RTT) [with a CDN] would still make your page faster than a 200ms RTT [with just HTTP/2]. In addition, CDNs bring to fore a huge set of other values, like offloading, reliability, security and more, which are hardly affected by HTTP/2.”

2) Undo HTTP/1.x Hacks

HTTP/1.x was designed for a very different web. Modern content is much more demanding than the sites it was originally designed to handle so web developers came up with a long list of tricks and techniques for squeezing performance out of the old protocol. Some of these include domain sharding, image spriting, and combining resources.

These workarounds have been used to speed up some of the world’s busiest websites, but they failed to address the underlying problems of HTTP/1.x.

One of HTTP/1.x’s biggest shortcomings – the lack of multiplexing – was managed through a technique known as domain sharding.

Web browsers only allow a limited number of connections to a domain, and domain sharding skirted this limit by storing resources on different domains. This effectively multiplied the number of available connections, allowing browsers to download more resources simultaneously.

CDNs were particularly helpful with domain sharding by using subdomains (e.g. subdomain1.cdn.com, subdomain2.cdn.com). However, domain sharding had its shortcomings. There was no clear way of knowing the optimal number of domains, network architecture became more complicated, and developers had to design sites around the use of multiple domains.

In some cases, using these workarounds will actually lower performance. Your web apps will continue to work exactly as they do today, but in order to take advantage of HTTP/2’s new features, a lot of the old workarounds have to be removed.

3) Encrypt All Assets

At one point, encryption was a requirement for SPDY and HTTP/2. While the IETF has since backtracked on this decision, a lot of browsers will only use HTTP/2 if the website uses TLS. All of the big-name browsers have already stated that they will require TLS for HTTP/2. So if you’re a business that wants to accommodate all types of clients, TLS is required.

But just because encryption is mandatory doesn’t mean that users won’t be able to access unencrypted sites. If the browser can’t negotiate an encrypted connection, it will fall back to HTTP/1. Some browsers, such as Firefox, will even support TLS over an HTTP URI. Users won’t see the benefits of HTTP/2 when accessing unencrypted content, but they won’t be denied access just because a site isn’t encrypted.

Fortunately, MaxCDN, makes it easy to instantly deploy SSL. This way you can ensure all CDN assets are delivered over a secure connection, so when we do start supporting HTTP/2, you are able to take advantage of it.

How You Can Start Using HTTP/2

Given you have a server that supports HTTP/2, your users can start receiving content over the new, optimized protocol if they’re using an HTTP/2-compliant browser. However, until your CDN supports HTTP/2, cached content will be delivered through other protocols.

As mentioned at the beginning of this article, MaxCDN will start rolling out support for HTTP/2 in 2016. And since HTTP/2 is fully backwards compatible, you won’t even need to make changes to your origin server to make it work.

If you have any more questions, feel free to contact us!