SPDY is Dead. Long Live HTTP/2!
Earlier this week Google announced that they will deprecate support for SPDY and transition to HTTP/2. As we have discussed before, SPDY was Google's experiment in making the web faster by improving the way your browser communicates with websites. SPDY formed the basis for HTTP/2 and has been largely replaced by it. With HTTP/2 is on track to published as an IETF standard in February 2015, it makes sense for Google to shift focus and resources away from SPDY and to its offspring.
To celebrate this transition, I wanted to briefly reflect on the need for SPDY and where we are going.
Dirty, hacky HTTP/1.x work-arounds
You only need to do a trivial amount of web performance optimization before you learn that HTTP has many shortcomings. Chief among them is how inefficiently HTTP/1.0 and 1.1 utilize the network when transferring content to the browser. If you want the details, I've discussed them at length before. Suffice it to say that HTTP/1.x does a poor job of utilizing the network so that making requests, especially when multiple requests to the same server, can be quite slow. Furthermore, our high bandwidth Internet connections don't help us with this problem.
But we no longer need to try and work around HTTP/1.x shortcomings. SPDY, and thus HTTP/2, does a much better job utilizing the underlying network and largely alleviates the need for these hacks. I for one cannot wait stop having to use dirty hacks like summing ASCII codes to get consistent domain sharding!
SPDY is Dead! Love Live HTTP/2!
SPDY was an amazing experiment that birthed HTTP/2. In that regard it was a great success. And while SPDY certainly encountered problems along the way (hello CRIME vulnerability!), this created a strengthened HTTP/2 standard. While SPDY is dead the HTTP/2 future is bright as support among browsers and servers continues to grow. If you want to get started, we have a great article about implementing HTTP/2 for your website, as well as SPDYCheck.org, our online tool to help you troubleshoot along the way. (And yes, we will be changing its name to HTTP2Check!).