For a new technology enthusiast it’s always exciting to see Google throw its weight behind a new piece of technology, like it did with HTML5 or open video web formats. As a large web company devoted to open standards, Google sets the bar pretty high for the tools that it open sources. On the other hand, more often than not, some Google projects fail miserably at ever reaching a a wider audience before they fall into oblivion. Google Wave has left bitter memories; no one remembers the PubSubHubbub extension to RSS; no browser apart from Chrome has announced plans to support the Dart language; WebP has failed –until now– to replace JPG as the default image format on the web.
So despite all the hype, the release of the SPDY protocol should be taken with at least a pinch of salt. Let’s start with the beginning: in November 2009, Google blogged about SPDY, pronounced “speedy”, a lab experiment designed to accelerate HTTP by addressing some of its most fundamental design flaws. By certain aspects, SPDY is Google’s most ambitious endeavours to reform the very fabric of the web. HTTP is the layer on which the Web is transported, and the aim of SPDY is to replace it. The question is: will it catch? and should you use it?
The pledge of SPDY is to accelerate the delivery of web pages by 50%. The only substantial experiments conducted until now have been performed at Google; they boast a 27-60% improvement over HTTP, and a 39-55% improvement over HTTPS.Other experiments report a 23% over HTTP on mobile networks. Now, you mention these figures to an IT department manager and you’ll see him drooling. But in which cases are you most likely to see a performance gap?
SPDY = HTTP++
SPDY shines most in three respects: first, it drastically reduces the size of HTTP headers sent in each request and response using simple compression techniques. HTTP headers contain data that serve to identify the client and server, including cookies. They can represent a disproportionate amount of data compared to the request/response body itself, for instance in lightweight Ajax requests, so compression is almost certainly a good idea — at least if the server CPU can handle the load. Second, SPDY tolerates unlimited streams (i.e: requests) in a single client/server connection. That means that multiple concurrent requests will finish faster; this will be most beneficial if you need to serve many small pieces of content in a single webpage. Finally, SPDY allows the server to initiate streams, sort of “push notifications”, without the client having to ask for them. That means that rather than having the client constantly asking the server whether there is any new data to display, the server can signal the client in a just-on-time fashion. The typical example of a web service that would benefit from these three SPDY features is an online stock exchange monitor: with traditional HTTP, the client needs to ping the server many times a second to receive price updates and stay current: large HTTP headers clog the TCP connection and the many HTTP connections saturate the web server. With SPDY, the server pushes lightweight updates to the client whenever necessary. Most importantly, all this is done without any change to the webpage content itself (HTML remains HTML), and without any conscious action by the user. All is needed is a compatible web browser and an SPDY server. In fact, in many respects, SPDY should not be considered as a replacement of HTTP, but an incremental improvement. Sort of an HTTP on steroids.
It’s getting big
All this looks great on paper, but SPDY won’t go anywhere if the technology does not mature and if there is no smooth transition from HTTP. As far as server management goes, conventionalism and conservatism are virtues. But a succession of recent events have caused people to reflect that SPDY might be here to stay: first, the adoption of SPDY by Twitter, making the social network the second biggest website serving webpages through SPDY. Then, Google released an SPDY module for Apache, the most popular HTTP server in use worldwide. This move puts the technology within reach of smaller website administrators by offering them a plug-and-play solution for serving web content over SPDY (note that if you run PHP code on your server then you will probably run into some issues). Finally, Firefox started supporting SPDY from version 11 onwards, and SPDY is activated by default in version 13; together with Chrome, the two browsers represent a substantial market share of about 45%.
Should I use it?
SPDY will be most beneficial to those services for which real-time response is a critical, competitive asset. But the people who need it most are likely to have a plartform based on responsive, less popular web servers than Apache, such as Nginx. Unfortunately, the SPDY module for Nginx is still in beta stage. Aside from Twitter and Google-owned websites, the biggest French players on the web have not made the jump to SPDY yet. The only exception to be found is Pixmania, the online retailer. This means that we have some time to see where the technology will be going, in particular if it will be integrated in the new HTTP 2.0 standard that Microsoft is pushing for.
Did you like it? 4.4/5 (30)
