Since HTTP/2 was introduced as SPDY, we've been covering it. As a result of the publication of the HTTP/2 specification, service providers, software vendors, and network administrators are gradually implementing it.

In 2016, AgileCDN will begin supporting HTTP/2. As long as your server and others that support HTTP/2 are still available, you can deliver content with AgileCDN while maintaining an HTTP/2 connection. In the next section, we'll go over HTTP/2 in more detail, but first let's review HTTP/2 quickly.

Here's why HTTP/2 is a good thing

HTTP/2 is essentially faster and uses less bandwidth. Additionally, it simplifies the lives of web performance advocates and developers by eliminating the need to use domain sharding or other HTTP/1.x workarounds. The following are some of the key features of HTTP/2:

A single connection can handle the loading of multiple resources in parallel. By avoiding TCP slow start and getting all headers out on the wire within one round trip (as opposed to 7, 8, 9, etc.), header compression reduces overhead. Push requests from your server to your client before the browser parses the HTML and sends requests for embedded assets, reducing round trips.

Firefox negotiates over HTTP/2 in 9% of all connections and Chrome negotiates over TLS in 45% of all connections as of early 2015. In light of the fact that HTTP/2 is a relatively new protocol, these numbers are pretty astounding and will only increase in the future.

Getting Started

CDNs are still relevant despite HTTP/2's improved load time, but HTTP/2 doesn't eliminate CDNs. In addition to improving the format of web content, HTTP/2 does not change how close the content is to the end user. Caching and servers are the only ways to accomplish this.

1）Your CDN shouldn't be axed

Long loading times are usually caused by high latency. You can improve performance far more by keeping a short distance between you and your users than by optimizing your backend. A CDN ensures that users can access your content as quickly as possible with HTTP/2.

Here's what Google's Ilya Grigorik has to say. Guy Podjarny, a web performance advocate, offered the following words of reassurance:

"I don't know why people think HTTP/2 will eliminate the need for a CDN, but I've heard this statement quite a few times. There would still be a need for a CDN if HTTP/2 were implemented.

Request multiplexing is true, but a 20ms round-trip time (RTT) [with a CDN] would still make your page faster than a 200ms RTT [with just HTTP/2]. Additionally, CDNs offer many benefits, including offloading, reliability, security, and more, which are little affected by HTTP/2."

2) Undo the HTTP/1.x hacks

A very different web was designed for HTTP/1.x. Since modern content is much more demanding than what HTTP/1.x was designed to handle, web developers came up with a long list of tricks and techniques to increase performance. Sharding domains, spriting images, and combining resources are some of these methods.

Despite their success in speeding up some of the world's busiest websites, these workarounds did not solve the underlying problems of HTTP/1.x.

In order to overcome HTTP/1.x's biggest shortcoming - the lack of multiplexing - domain sharding was used.

With domain sharding, resources were stored on different domains to circumvent the limit set by web browsers. As a result, more resources could be downloaded simultaneously by browsers due to an increase in available connections.

Using subdomains (e.g. subdomain1.cdn.com, subdomain2.cdn.com) helped CDNs facilitate domain sharding. Sharding domains, however, had its limitations. It was unclear how many domains were optimal, network architecture became more complex, and developers had to design sites to accommodate multiple domains.

Some of these workarounds actually reduce performance. While your web apps will continue to work as they do today, many of the old workarounds will have to be eliminated to take advantage of HTTP/2's new features.

3)Make sure all assets are encrypted

In the past, SPDY and HTTP/2 required encryption. IETF has since backtracked on this decision, but most browsers will only support HTTP/2 if the website uses TLS. HTTP/2 will require TLS in all major browsers, according to their announcements. For businesses that want to accommodate all clients, TLS is a requirement.

But just because encryption is mandatory doesn't mean that users can't access unencrypted sites. HTTP/1 will be used if the browser is unable to negotiate an encrypted connection. While unencrypted content won't benefit from HTTP/2, users won't be denied access simply because the site isn't encrypted. Some browsers, such as Firefox, will even support TLS over HTTP.

The good news is that AgileCDN makes instant SSL deployment easy. When we support HTTP/2, you will be able to utilize it when we deliver CDN assets over a secure connection.

The HTTP/2 protocol can be used by your users if they're using a HTTP/2-compliant browser and your server supports it. As long as your CDN does not support HTTP/2, cached content will be delivered via other protocols.

AgileCDN began implementing HTTP/2 support in 2016. Because HTTP/2 is fully backwards compatible, you won't need to change your origin server to use it.

We are happy to answer any questions you may have!