In this article we’re gonna cover some essentials CDN users need to know when taking HTTP/2 into account. In order to do that, we first need to explain what HTTP/2 is.
HTTP/2 is the second major version of the HTTP network protocol used broadly across the web. Its main goal is to decrease latency to improve page load speed in web browsers by considering data compression of HTTP headers, server push technologies, and fixing the head-of-line blocking problem in HTTP 1. This must be done while supporting the common existing use cases of HTTP, such as desktop browsers, mobile browsers, and other web servers. In other words, HTTP/2 gives us lower bandwidth usage and better performance. It also removes the need for domain sharding and other HTTP/1.x workarounds, which makes things pretty easier.
How One AI-Driven Media Platform Cut EBS Costs for AWS ASGs by 48%
Let’s explain the key features of HTTP/2:
- 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 we all know, page speed is the key factor; the first step of optimal page performance. Although HTTP/2 improves load time greatly, it doesn’t rule out the importance of a CDN. Better web format can’t change the distance between the content and the end-users. This is where a CDN steps in and saves the day.
Start off by undoing HTTP 1 hacks
The web was very different back in the day when HTTP 1 was launched. Things used to be way more simple and web design has gone a long way, meaning that modern page design is much more demanding that it used to be a decade ago.
Pages were text-heavy, with a small number of images and external files. There were few external resources such as CSS files or JavaScript files. Styling was accomplished using tables and background images, and JavaScript was usually cut-and-paste into the middle of the content. The HTML code of these web pages was extremely ugly, but they did not put much strain on the web server because they were mostly self-contained.
One of HTTP/1.x’s biggest shortcomings – the lack of multiplexing – was managed through a technique known as domain sharding. In order to take advantage of HTTP/2’s new features, a lot of the old workarounds have to be removed. HTTP 1 used to work well back in 1997., but nowadays the Internet is a different animal.
Encrypt all assets
Encryption used to be 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. TLS is practically required. 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.
Deploy a CDN
Long loading times are mostly caused by high latency. But keeping a short distance between the user and the content can greatly boost the page performance, way more than any backend optimization. Using a HTTP/2 with a CDN is a double win combo. The main advantage of HTTP/2 (and SPDY before it) is the speed increase and reduces additional round trip times (RTT). It can make your web site load much faster without any manual optimization.
Fun fact: as of early 2015, 9% of all Firefox connections negotiate over HTTP/2 and 45% for TLS connections over Chrome. The numbers will only grow as things go forward.
If you have a server that supports HTTP/2 and if your users have a HTTP/2 compliant browser, you can already start using the new protocol, but your CDN has to support it as well. The upside is that HTTP/2 is fully backwards compatible, which means there’s no need to make changes to the origin server in order to make it function.
As a CDN serving many clients, securing our servers against attack is very important. The new standard is more secure than SPDY, as it uses a fixed Huffman code-based algorithm (HPACK) to compress HTTP headers. SPDY uses a less secure stream-based compression, so this change will make our infrastructure even more secure. HTTP/2 allows you to “push” resources to the browser, anticipating the files which will be requested before the browser even asks for them.
The primary gain of HTTP/2 and CDN pairing is better performance and better security, which, at the end of the day is what every internet user should strife for. So there really is no point in standing in the sideways, as “optional” is about to turn into “required”.
This post is based on this great article from MaxCDN.
