SPDY Gonzales: Google Continues Its Push To Take The Web To Breakneck Speeds

speedy-gonzalesGoogle is obsessed with speed. By many accounts its Chrome web browser is already the fastest out there, and it runs laps around the two big boys: Firefox and IE. But that’s not good enough for Google. And so now they’re also working on their own web content transportation protocol.

To be clear, despite some of the wording ins its blog post, SPDY (pronounced “speedy”) isn’t about fully replacing HTTP, the standard web protocol since 1996, but it is about augmenting it, to make delivery faster. How much faster? After doing some initial internal tests with Chrome, Google claims that the top 25 websites in the world can load up to 55% faster with SPDY.

Of course, as Google notes, those tests were done in Google’s labs, likely under optimal conditions. SPDY in an average home during daily use may produce different results. But again, this protocol is still very young, so it’s entirely possible that things could get even faster. To that end, Google is asking for the development community’s help. They’ve posted some early documentation and code samples, hoping for feedback.

In the docs, Google lays out the difference between HTTP and SPDY:

SPDY is intended to be as compatible as possible with current web-based applications. This means that, from the perspective of the server business logic or application API, nothing has changed. To achieve this, all of the application request and response header semantics are preserved.  SPDY introduces a “session” which resides between the HTTP application layer and the TCP transport to regulate the flow of data. This “session” is akin to an HTTP request-response pair.

I reached out to Google just to confirm that they weren’t going to try and do something completely crazy like change the “http://” we all know and love with “spdy://”, don’t worry, they’re not. As stated above, SPDY will create a session of sorts that resides between HTTP and the data transportation.

What will be interesting about this protocol is if it’s optimized for Chrome over the other web browsers. It would seem Google wouldn’t do that, since its ultimate goal is to have people using the web through any means as quickly as they can (so as best to serve their ads more often). But when you’re developing both a protocol and a browser, it seems likely that Google will have an advantage to offer the best experience.

A few startups are also working on ways to deliver web content faster. One, FasterWeb, which we covered in July, is hoping to improve web surfing speeds tenfold next year. Their approach is different, optimizing content on the provider or ISP end.