> Personally, I would hesitate to implement them unless they had wide browser support.

When "implement them" means either "change one config option in your web server" or "install one package containing a SPDY implementation for your server", it seems worth doing just to provide a better experience for the browsers that support it so far.

You got me there. That does seem reasonable. I guess I need to do a bit more investigation. :-)

I believe Firefox + Chrome easily qualifies as "wide browser support." IE is really the only one left now.

Uhh, Safari? Safari is the number one browser on one of my (non-technical) websites, primarily because of mobile traffic (iPhone and iPad).

Mobile browsers are already slow and playing catchup with the desktop web. They're hardly the place cutting edge innovation is taking place.

SPDY "gracefully degrades" to HTTP, so there's not really a chicken and egg problem. If your web server makes it easy to enable SPDY, there's not a big reason not to (that I'm aware of).

Technically SPDY is an application layer protocol, but you shouldn't need to change your existing HTTP application to enable it.

Surely you just need your webserver to support the protocol. I don't think most apps will directly speak SPDY.

That's true for the most part. But if you want to leverage certain SPDY features like SPDY server push, then your app must be SPDY aware. Likewise, if you want to undo normal HTTP optimizations like hostname sharding which are damaging for SPDY, your app should be SPDY aware. Check out http://dev.chromium.org/spdy/spdy-best-practices for other recommendations.