This blog post is part of an ongoing series where we will discuss a wide range of H2-related topics. In today's post, we talk about some of the misconceptions regarding HTTP/2 being a silver bullet for improved website performance.
Get In Touch
Recently by Stephen Ludin
Akamai was the first CDN to support HTTP/2. This blog post is part of an ongoing series where we will discuss a wide range of H2-related topics. In today's post, we are boding a fond farewell to SPDY.
When Let's Encrypt was founded at the end of 2014 it had a lofty goal: promote the use of TLS everywhere by making certificates free and server configuration painless. It was noted that for many web administrators, for both large and small sites, TLS was seen as expensive, difficult to configure, and slow. With that headwind, the return on investment was seen as too low to bother unless you were handling financial or other sensitive information. As it does, web security quickly evolved in the ensuing years. Firesheep, Snowden, and Google page ranking: these are just a few things that have changed how people think about the importance of encrypting everything online. And services like Let's Encrypt and Akamai deal with the problems head on, reducing the pain of Internet security tremendously.
If there was ever a truism it is that technology is rapidly evolving under our feet. What was right today, is likely to be sub-optimal tomorrow. This situation can cause a sense of paralysis leading to delayed action because next week the "Next Great Thing" is coming soon. With the advent of HTTP/2 (h2) that translates to holding off on optimizing your web properties. When you have large portions of your user base on h2 and a similarly large portion on h1, you need to double your efforts to keep up!
HTTP is old. How old? Let's look at a timeline to start:
1991 - HTTP/0.9
1996 - HTTP/1.0
1999 - HTTP/1.1
2013? - HTTP/2.0
Our beloved protocol that has been powering the information age in which we all live has been kicking around for over 21 years. Further, it has not had a major version change in 13! Using the dog year's metaphor, this puts the invention of HTTP back in the colonial time of the Internet (I have a marvelous proof of this but limitations to the margin property prevent me from including it). It is a rare occurrence when something can stand the test of that sort of time and remain relevant. Even the United States Constitution has needed a few major tweaks in that time (27 in all). So it should come as no surprise that the current version of HTTP is showing its age.
But before I list off HTTP's deficiencies, let me take a moment to reflect on the wonder of "the Little Protocol That Could." It is highly likely that every one of you reading this blog would not have the job you have today if not for HTTP. Think of the evolution of a "web page" since 1991. Think of the elements that we today take for granted that were never envisioned back when HTTP first displaced Gopher for file retrieval. The very fact that HTTP has been able to adapt to the rapidly changing web and power our modern marketplace is a testament to the brilliance of the protocol.
That said, it seems that web developers have been holding HTTP together with dental floss and glue for a number of years. We have desires for "instant" page rendering and good old HTTP/1.1 is seen as one of the bottlenecks.
HTTP is Dead - Long Live HTTP
That is what drove us to develop and announce the upcoming SPDY and WebSocket support at the recent 2012 Santa Clara Velocity conference. We have been working with and developing these protocols for a while now and are excited to bring them to our network. It is a fascinating time in the web world and SPDY and WebSocket are central themes in the raging debates around the direction of the basic protocols that make everything tick. Recently this pair of protocols has been cast as somehow competing for a virtual crown in a race to see who will win a standards war. Here at Akamai we see this as far from the case, and believe that looking at them through that sort of lens will distract from the basic fact that they are two tools for two jobs.
SPDY (pronounced speedy), for those who are not familiar with it is a proposal and implementation from Google for a faster version of HTTP. SPDY achieves its performance boost through a number of optimization such as request multiplexing, using fewer connections, and header compression to name a few. Benchmarks generally show that SPDY consistently improved a web page performance by 10-20%. In our millisecond mattering world, that is huge and worth taking notice.
Akamai's initial SPDY implementation will be targeting version 2 of the protocol. End users with SPDY speaking browsers will be able to converse with our secure edge network (ESSL) using this latest and greatest web development starting this fall.
Not Pixie Dust
Recent studies, particularly one from at Akamai, show that SPDY is not some magical engine that will remove all of the bottlenecks a web site might have. Do not take our criticism of SPDY as an indicator that we are not supporters of it. On the contrary, we believe in the direction and want to see it get better and better. Different bottlenecks require different solutions, ranging from better caching and route decisions to addressing third party content and Front-End Optimization. For the cases where HTTP between client-and-edge is holding you back, SPDY will come to the rescue.
At Akamai we aim to offer the complete set of tools to address each bottlenecks, and will help you use the right tool for the right job. We're excited to add SPDY to this suite, and help push the web forward.