The Internet Engineering Task Force (IETF) approved the proposed HTTP/2 standard in February 2015. HTTP/2 is the first major update to HTTP (Hypertext Transfer Protocol) since HTTP/1.1, which was standardized in 1999. The primary objective of HTTP/2 is to maintain high-level compatibility with HTTP/1.1, while decreasing latency. In other words, avoid breaking the Web while making it faster.
Since late 2009 Google has been developing an experimental protocol called SPDY (pronounced speedy). SPDY is a trademark of Google and not an acronym. HTTP/2 was originally based on the SPDY experiment. In fact, many SPDY core developers were involved in the development of HTTP/2. As of February 2015, Google announced support for SPDY would be deprecated in favor of HTTP/2 and then completely withdrawn in 2016.
While HTTP/1.1 has served us well since 1999, it was designed for computers and the Web of that time. Needless to say, HTTP is long overdue for an update. To help describe how HTTP/1 works, I have put together the following diagram. Follow the numbers and you will see it starts with the client (possibly a web browser) establishing an HTTP/1 connection to the server on the right.
(2) Client/browser then sends a GET request (HTTP method) for the site’s
(3) Represents the sever responding with the requested resource.
(4-7) For our simple example, this request-response cycle continues for the style sheets and scripts in support of this HTML document.
(8) Finally, the HTTP/1 connection is closed.
As you can see, the client/browser spends a great deal of time waiting on each resource. Because HTTP/1 cannot make concurrent requests over a single connection, browsers usually attempt to expedite the process by opening multiple connections.
While multiple connections help, from a computer networking perspective, each is very expensive to open. Due to this expense, modern browsers are limited to a maximum of 6-8 HTTP/1.1 connections. With many websites now requiring 80 or more resources, these limitations create a significant performance bottleneck.
HTTP/1.1 attempted to correct this performance bottleneck with a technique called HTTP Pipelining. Unfortunately, it still allowed a single large or slow response to block all others that followed. HTTP Pipelining is not difficult to deploy, it is impossible. No modern browser supports HTTP Pipelining because many intermediaries and servers fail to process it correctly.
Multiplexing allows multiple request-response messages to be in flight over a single HTTP/2 connection, at the same time. To demonstrate how much more efficient an HTTP/2 connection can be, I prepared a side-by-side comparison to HTTP/1. Even in this simplistic example with only three required resources, note how much faster the web page can begin rendering.
Extrapolate this comparison to a more common situation of 80 required resources compounded by the expense of 6-8 HTTP/1.1 connections and the efficiency of a single HTTP/2 connection becomes clear.
In addition to multiplexing, HTTP/2 is binary instead of textual like HTTP/1. Compared to textual protocols, binary protocols are more efficient to parse, more compact “on the wire” and less error-prone.
HTTP/2 also reduces overhead by compressing its headers, whereas HTTP/1 does not.
Server Push is an HTTP/2 mechanism for sending data before clients request it. For example, if a request is made for your home page, the server could respond with the home page plus logo and style sheets because it knows the client will need them all. This is essentially the same as inlining all resources within an HTML document, except pushed resources would be cacheable.
A drawback of Server Push is possible redundancy in cases where the client has already cached the resource(s). This is why I recommend using Server Hints instead.
Server Hints notify clients of resources that will be needed, before clients can discover such resources. The server does not send the entire contents of the resource, but only the URL. Clients can then validate their cache and if needed, formally request the resource. Server Hints are not new to HTTP/2 but worth mentioning here because they do not suffer from the possible redundancy drawback of Server Push, as described above.
Server Hints are implemented using the Link header with HTTP and overlaps with existing link prefetching semantics. For example, an HTTP Link header looks like this:
Link: <https://example.com/images/large-background.jpg>; rel=prefetch
No server-side implementation is required if the HTML document includes a
prefetch link in the head tag. For example:
<link rel="prefetch" href="https://example.com/images/large-background.jpg">
To learn more about
rel="prefetch", see Link prefetching FAQ by Mozilla.
preload relationship is used to declare a resource and its fetch properties. This specification extends functionality with additional processing policies that enable efficient fetching of resources that might be required by the next navigation. For example:
<!-- fetch and preprocess for next navigation --> <link rel="preload" href="//example.com/next-page.html" as="html" loadpolicy="next"> <!-- fetch and do not preprocess for next navigation --> <link rel="preload" href="//example.com/next-component.html" as="html" loadpolicy="next inert">
"next inert" loadpolicy is equivalent to
rel=prefetch implemented by some browsers. The
"next" loadpolicy is semantically equivalent to
rel=prerender implemented by some browsers. This specification standardizes and extends previous
prerender functionality with additional capabilities.
To learn more, see Resource Hints edited by Ilya Grigorik and published by the W3C.
Although the primary objective of HTTP/2 is to make the Web faster, it has been heavily criticized for not mandating encrypted connections. However, the leading browser makers have thus far refused to implement HTTP/2 without encryption. So by proxy, HTTP/2 will require an encrypted connection to deploy. Please see my article, HTTPS Everywhere if you do not agree this is good for the future of the Web.
HTTP/2 is or will be supported by all major browsers.
Other known implementations of HTTP/2 can be found on the GitHub HTTP/2 wiki.
As we have explored, HTTP/2 is a long overdue update for the Web. As it becomes widely adopted over the next few years, websites and other web services will become faster and more capable than ever before. Thanks to forward-thinking browser makers, HTTP/2 will also enhance user privacy and security. While there is more that could be done, I feel that HTTP/2 is a significant step forward for the entire Web.