Akamai Diversity
Home > Web Performance > SPDY and WebSocket Support at Akamai

SPDY and WebSocket Support at Akamai

Now, more than ever, time is money. The four two second rule is a thing of the past and companies today are not simply looking at performance as a specific bar to get over, but rather as an element that has a direct effect on their conversion rates. Akamai has supported this view this for a long time, and to that end have continually come up with new technologies to make the web faster.  End-user expectations do not stand still, and neither will we.

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

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.
WebSocket

SPDY is targeted at improving the performance of web pages. It is an evolution of HTTP. WebSocket is targeted at the real time interactive web. Its roots come from the world of Ajax, Comet, and Bayeux.  All of these technologies ride on top of HTTP and push the protocol to the limits of the standard to provide an experience of a bidirectional communications channel.  The goal of WebSocket is to provide that natively without stretching HTTP into unnatural contortions. 

WebSocket is similar to SPDY in many respects but it was designed with a different use case in mind. WebSocket is all about real time, interactive data.  Think stock quotes, sports scores, gaming, even interactive presentations and collaborative application. As a developer, the simplicity involved in setting up a subscription channel for streaming data to a browser using WebSocket is incredibly appealing.  As a consumer, the experience is potentially something that has never been seen before over the web.  Take a moment and examine the demos the WebSocket company Kaazing has developed. WebSockets mean pushing the interactive web to new exciting frontiers.

WebSocket Versus SPDY?

There has been press recently that attempts to pit SPDY and WebSocket against each other. There is perception that they are somehow competing protocols. Some of this comes from the similarities between the two. They are so similar in fact that there are proposals for putting SPDY over WebSocket and WebSocket over SPDY. Mostly though it seems to be the splash effect of the media attempting to set up the debate around the upcoming HTTP/2.0 protocol as a sensational grudge match, the Octagon of Geekdom, between SPDY and HTTP Speed + Mobility. Though entertaining, this misrepresentation has a damaging effect on what is likely to be one of the most important discussions the web developer community has had in over a decade.

My view on this is quite different.  I use the metaphor of hammers and screwdrivers and their associated fasteners.  Both tools are indispensible in my workshop.  Both tools 'join things together'. But both are highly specialized in how they go about their job. So much so that though you could use one to do the job of another, your results will be suboptimal. Don't do this.

Use the right tool for the job. In the case of page and object delivery use SPDY. In the case of lightweight or streaming data delivery look to WebSocket. This is the best possible situation to be in: the community has given us two tools to do the specialized work that HTTP does today.

Stephen Ludin is a chief product architect at Akamai

4 Comments

If I am a site developer, how can I take advantage of Akamai's SPDY in ESSL? Is there any documentation on this yet?

Thanks!

Peter

Peter - The goal is to have it be completely seamless for users of our new site delivery products. The initial implementation will be between the browser and the edge. Once SPDY is enabled on your configuration, all SPDY enabled browsers will start negotiating SPDY. Edge to origin SPDY is still in the works. If your question is more geared toward 'how do I adjust my site to best take advantage of SPDY', let me know. That will make a great follow up post.

good to see support for websockets, but two pieces of info missing from this post are 'when' and 'how'.

how soon will support be available and how does one connect?

Kaazing's CTO, John Fallows, just posted a related post, titled: SPDY and WebSockets, a powerful combination: http://cto.kaazing.com/2012/08/06/speedy-and-websockets-3/

Leave a comment