HTTP/2 - What Does It Mean for a CDN?

By Sven Baumgartner
Updated on February 17, 2023
HTTP/2 - What Does It Mean for a CDN?

As the Internet evolves, so do the protocols that govern its operation. KeyCDN announced support for SPDY in 2014, which was a big improvement in terms of speed, but Google's update to drop SPDY heralds the start of the next big protocol change. One of the latest protocols is HTTP/2, which aims to address the shortcomings of its predecessor, HTTP/1.1. This new protocol is intended to enable faster and more efficient data transfer between web servers and browsers. In this article, we discuss the transition from SPDY to its successor, HTTP/2, the impact of HTTP/2 on content delivery networks (CDNs) and how this protocol changes the way CDNs operate.

SPDY's technology is by no means a dead end. It is the core of HTTP/2 and removes the limitations in the SPDY draft.

What is HTTP/2?

HTTP/2 ((Hypertext Transfer Protocol version 2)), originally named HTTP 2.0, is the successor to HTTP/1.1, the protocol that has been in use since 1999. It is a major revision of the HTTP protocol that is used by web browsers and web servers to communicate and transfer data over the internet. HTTP/2 was first introduced in 2015 and is designed to address some of the shortcomings of HTTP/1.1, such as slow page load times and inefficient use of network resources.

HTTP 1.1 has been serving us well since 1997, but today its limitations are slowing down the web.

In 1997, websites were generally much simpler. They 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.

Today's web pages are very nicely coded, but they contain a lot of external files. Web developers have learned to separate the layers of markup, design and behaviour into different files, which makes code maintenance much more efficient, but introduces overhead when the page is loaded. At the same time, large CSS frameworks and JavaScript libraries are now the norm. Web applications can include dozens of large files to control behaviour and appearance of web pages.

Under the weight of this overhead, HTTP 1.1 is showing its age.

In order to address the shortcomings of the old standard, many different organizations and companies have spent a lot of time trying to develop a replacement. One of these replacements was a protocol called SPDY, developed by Google. SPDY (pronounced "speedy") aimed to increase the speed of websites by up to 55% - in most tests, it achieves an improvement of at least 27%, even on sites which have already been optimized for speed.

HTTP/2 is based on SPDY, with some improvements which make it even faster and more secure.

Google started to experiment with HTTP/2 as early as 2013 and it was one of the first major companies to implement the protocol on a large scale. As of now, the majority of Google's traffic is delivered over HTTP/2.

According to Google's transparency report, as of February 2023, over 96% of Google's traffic is delivered over encrypted connections, and the majority of that traffic is delivered using HTTP/2. Google has stated that they have seen a 10% reduction in page load times since implementing HTTP/2, which has led to better user experiences and improved engagement.

Additionally, Chrome, Google's web browser, has supported HTTP/2 since 2015, which has helped to accelerate adoption of the protocol.

Downfalls of HTTP/1.1

While HTTP/1.1 has been the primary protocol used for the World Wide Web for over two decades, it has several significant downfalls that can impact the performance and security of web browsing. Here are a few of the key downfalls of HTTP/1.1:

  • Latency: HTTP/1.1 has a high level of latency, which is the time it takes for a server to respond to a request. This is because each resource, such as an image or a script, requires a new connection to the server. This can slow down the load time of a web page, especially on slower connections.
  • Head-of-line blocking: In HTTP/1.1, resources must be requested and received in the order that they appear in the HTML document. This can result in head-of-line blocking, where a large resource, such as an image, can block the loading of subsequent resources until it is fully downloaded. This can lead to slower load times and a less efficient use of bandwidth.
  • Lack of compression: HTTP/1.1 does not support efficient compression of headers, which can add significant overhead to web requests and responses. This can slow down the load time of a web page, especially on slower connections.
  • Limited server push: HTTP/1.1 does not support server push, which means that a web server cannot proactively send resources to a browser before they are requested. This can result in unnecessary round-trips between the browser and server, slowing down the load time of a web page.
  • Security issues: HTTP/1.1 has several security issues, including the lack of encryption for data in transit, which can make it easier for attackers to intercept and manipulate web traffic.

HTTP/2 was developed to address many of these issues and provide a more efficient and secure protocol for web browsing.

Why should we care about HTTP/2?

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.

The same could be said of SPDY, but it has some limitations of its own:

  1. It was not universally supported - it was an open source solution, but it wasn't a web standard. HTTP/2, however, is a full web standard by the IETF, and servers and browsers are expected to comply fully.
  2. It required everything to be sent over a secure HTTPS connection. This isn't a barrier for larger ecommerce firms, but it did prevent smaller sites from benefiting, as there are many basic hosting accounts that do not include an SSL certificate.
  3. HTTP/2 supports multi-host multiplexing which further reduces RTTs. SPDY only supports single-host multiplexing.

HTTP/2 does away with these limitations, which is why Google themselves plan to drop support for SPDY and adopt to the latest standard.

There are several key features that differentiate HTTP/2 from SPDY:


One of the primary differences between HTTP/2 and SPDY is that HTTP/2 is an official internet standard, while SPDY was an experimental protocol developed by Google. HTTP/2 was developed through a formal standardization process by the Internet Engineering Task Force (IETF), which ensures that it is an open, transparent, and widely adopted protocol.

Binary protocol

HTTP/2 uses a binary protocol, which makes it more efficient for computers to parse and process than SPDY's text-based protocol. This allows for faster and more efficient transfer of data.


Both HTTP/2 and SPDY support multiplexing, which allows multiple requests and responses to be sent over a single connection, reducing latency and improving performance. However, HTTP/2's implementation of multiplexing is more efficient than SPDY's, as it can handle more concurrent requests.

A simple example of multiplexing in our daily lives might be going grocery shopping. Imagine that you need to buy five different items at the store, and each item is in a different aisle. In the past, you would have to walk down one aisle to get the first item, then walk all the way back to the front of the store to get the second item, and so on. This would take a lot of time and be very inefficient.

Now, imagine that the store implements multiplexing. With this feature, you could request all five items at once and the store would gather them for you while you wait at the front of the store. This would save you a lot of time and make your shopping experience much more efficient.

In a similar way, HTTP/2's multiplexing feature allows web browsers to request multiple resources from a server in one go, rather than having to wait for each resource to be delivered separately. This can greatly improve the speed and efficiency of web browsing.

Header compression

Both HTTP/2 and SPDY support header compression, which reduces the amount of data that needs to be sent between a browser and a server. HTTP/2's implementation of header compression uses a more sophisticated algorithm to compress headers.

Server push

Server push allows a web server to send resources to a browser before the browser requests them. Imagine that you order a burger, and the restaurant knows that most customers who order burgers also want fries and a drink. With server push, the restaurant could proactively bring your burger, fries, and drink to your table, without you needing to specifically request them. This would save you time and make your dining experience more efficient.

In a similar way, HTTP/2's server push feature allows a web server to send resources to a browser before the browser requests them. For example, a web server might anticipate that a browser will need a CSS file and some images to display a web page, so it could proactively send those resources to the browser before the browser requests them. This can greatly improve the speed and efficiency of web browsing.

However, it's important to note that server push needs to be used carefully, as it can potentially send resources that are not needed or that the browser already has in its cache. If used improperly, server push can actually slow down web browsing.

Performance is important

In the context of the ever-increasing use of the internet by smartphones, performance is particularly important. Mobile devices typically have slower connections than desktop computers, and users are more likely to abandon a website if it takes too long to load. By improving the performance of web pages, HTTP/2 can provide a better user experience on mobile devices and reduce the risk of user abandonment.

Furthermore, with the increasing use of mobile devices, there is a greater need for efficient use of data. HTTP/2's multiplexing and header compression features can help reduce the amount of data that needs to be sent between the browser and server, which can reduce the amount of data used and potentially reduce costs for users with limited data plans.

Overall, performance is a critical aspect of HTTP/2, particularly in the context of the ever-increasing use of the internet by smartphones. By improving the performance of web pages, HTTP/2 can provide a better user experience, reduce the risk of user abandonment, and potentially reduce data usage and costs for mobile users.

The importance of HTTP/2 to a CDN

As a content delivery network, our job is to speed up the delivery of resources over the web. Part of that job is making it faster for each packet of data to reach its final destination by hosting the content close to the end user. HTTP 1.1 is a limitation that CDNs have had to work around for too long. With SPDY, we began to see the light at the end of the tunnel.

HTTP/2 is a big step forward for the whole industry. It will allow us to offer an even faster experience for our users and clients, without them having to make any changes at their end. In fact, the job is about to become easier for web developers as complex methods such as sharding become less important.

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 to "push" resources to the browser, anticipating the files which will be requested before the browser even asks for them.

For web users, you can expect to see a noticeable boost in performance in all of the websites supporting HTTP/2. This is why we at KeyCDN are taking HTTP/2 very seriously. We launched HTTP/2 support for all customers on October 15th, 2015.

  • Share

Supercharge your content delivery 🚀

Try KeyCDN with a free 14 day trial, no credit card required.

Get started


Comment policy: Comments are welcomed and encouraged. However, all comments are manually moderated and those deemed to be spam or solely promotional in nature will be deleted.
  • **bold**
  • `code`
  • ```block```
KeyCDN uses cookies to make its website easier to use. Learn more