HTTP2: A New, Improved Web Protocol
HTTP2, the new Web protocol slated to go live any day now, aims to be a faster, more efficient protocol. HTTP1.1 is the current predecessor and has been around for about 15 years. The problem with HTTP1.1 is that can only load requests one at a time, one request per one TCP connection. Basically, this made browsers run parallel requests to multiple TCPs for the same Web asset. This clogs up “the wire” with multiple duplicate data requests, and can hurt performance if too many requests are made.
In short, HTTP1.1 makes loading a web page more resource-intensive than ever. This led to the industry utilizing Best Practices like concatenation, data inlining and domain sharding in an attempt to fix the underlying problems of the protocol.
HTTP & SPDY: The Basis of HTTP2
Enter SPDY in 2012. SPDY was the next open source protocol that was developed, this time by Google, in an attempt to reduce web page load latency and increase security. SPDY modified the way HTTP requests and responses are sent over the wire and made an effective base for HTTP2. Just recently Google announced it will be removing SPDY in favor of HTTP2 and that we can expect HTTP2 to come to browsers in a few weeks.
These are the high-level differences between HTTP1 and HTTP2:
- HTTP2 is binary, instead of textual
- HTTP2 is fully multiplexed, instead of ordered and blocking
- HTTP2 can therefore use one connection for parallelism
- HTP2 uses header compression to reduce overhead
- HTTP2 allows servers to “push” responses proactively into client caches
There’s a really great article on Moz about HTTP2 that gives some clever analogies and can help the non-technical SEO visualize this rather-technical issue.
To sum up: HTTP2 is already available. It’s recommended to use HTTP2 as support for a faster website and better user experience, but the old standby recommendations of losslessly optimizing images etc. still hold true.
What this means for businesses
HTTP2 is a replacement for how HTTP is expressed “on the wire” and is not a ground-up rewrite of the protocol. That means HTTP methods, semantics, and status codes will stay the same. To use APIs that work with HTTP1, there may need to be small additions made.
HTTP2 does not require encryption, for URLs to be restructured or rewritten, or any changes to how existing web applications work. However, new applications can take advantage of HTTP2’s features for increased speed, especially important for mobile search. Clients do not need to contact their webhosts, they can get access to application data, HTTP2 FAQ and implementation questions here.