Google speeds up the Web with SPDY
I'm inclined to believe these claims because when I opened some moderately complex spreadsheets in Google Docs using both Chrome 10 and Firefox 4, and taking into account their differences in JavaScript rendering speed, Chrome 10 was still rendering pages about 20% faster than Firefox from what I would have expected.
I saw similar results on Gmail, iGoogle, and Google Advanced Scholar Search. I don't know about you, but a 20% boost in Web site performance is impressive to me.
When I used Google's own SPDY benchmarking tool, I saw similar results. This, which only compares Chrome with and without SPDY activated, showed that SPDY gave me a 15% improvement in Web site performance.
I've seen claims that SPDY can cut Web page load speeds by 50%, but I didn't see that kind of boost. Try it yourselves and let me know what you find.
Keep in mind, as you play with SPDY, that there are almost endless variables that can effect how fast a Web page will load for you. These include your ISP backbone speed, your broadband rate, the quality of your connection, how busy the Web site is when you reach it, and on and on and on.
You should also recall that SPDY only works if it's working in both the browser and the Web site server, so if you use Chrome 10 on Facebook or Yahoo you won't see any speed increase. For now, it only works with Chrome 10 and, so far, all the Google Web sites I've tried it on. It wouldn't surprise me though if SPDY hasn't been activated on all of Google's services and sites yet.
SPDY also won't work equally well on all kinds of data. According to a note in the SPDY developers' mailing list, "SPDY requires that the client support gzip compression [a data compression program] of payloads. The hope is that gzip quickly, simply and automatically gets pretty good compression of the payload."
This use of data compression means that data's that already compressed, such as a video MP4 streams or a JPEG image, will not get as much performance benefit from SPDY as straight text or JavaScript. Still, no matter what content you're trying to view you should see some speed improvements.
That's because SPDY also compresses the HTTP header information. What's far more significant though is how a SPDY handles Web requests. According to the second draft of the SPDY specification, SPDY "adds a framing layer for multiplexing multiple, concurrent streams across a single TCP connection (or any reliable transport stream). The framing layer is optimized for HTTP-like request-response streams."
Besides header compression, SPDY improves on HTTP by multiplexing data requests. Under SPDY, there is no limit to the number of requests that can be issued concurrently over a single SPDY connection. Because requests are interleaved on a single channel, the protocol is more efficient over TCP. HTTP, on the other hand can only fetch one resource at a time and support, at most six connections at a time with most Web browsers. The net effect is to cut down on latency as the Web browser and server don't have to waste time ping-ponging data requests and responses back and forth.
With SPDY, a Web browser can also prioritize requests. This way you can get the most critical data first, say a video stream, rather than wasting waiting around for an ad to appear before starting the video.
The bottom line is that while SPDY may not cut Web page load times in half, it can significantly improve your Web browsing performance.
Google plans on open-sourcing SPDY and the C++ code is available today. There's also an experimental SPDY Apache Web server module and Ruby code if you want to tinker with it yourself on the server side.
Hopefully, Google will soon officially open the source and submit SPDY to the World Wide Web Consortium (W3C) to make it an official standard. After all, we could all use faster and more efficient Web servers and browsers.
Related Stories:
Chrome 10: Close to a perfect Web Browser 10
Juniper Networks Introduces new Internet Service and Content Provider Architecture