The results show SPDY, on average, is only about 4.5% faster than plain HTTPS, and is in fact about 3.4% slower than unencrypted HTTP. This means SPDY doesn’t make a material difference for page load times, and more specifically does not offset the price of switching to SSL.
He also dismisses the benefits of having encryption by default on every connection, that itself is worth a 3% slowdown.
SPDY hits you a bit harder in setup costs to be able to sling lots of requests back and forth faster. This is great for someone like Google who serves 100% of the on page content themselves. Anyone with advertising, third party content, or using a CDN for delivery might want to do some extensive real world testing before bothering to implement.
At an absolute minimum he should have enabled caching and then measured performance on the second run both with and without SPDY. As someone who has setup a rig exactly like this, using a SPDY enabled reverse proxy, the benefits are enormous.
Many, many absolutely terrible ideas have persisted on HN because of the appeal to authority (like listening to Digg's opinion on databases). It is not useful.
But again, feel free to suggest better testing methodologies. I look forward to your results.
It's not a "study", per se, but it does corroborate Google's claims.
Google's documentation seemed quite sufficient to implement, and until we have a proper reference implementation, this seems a little half-cocked.
Maybe I misunderstand the point of the IETF draft?
I don't know what qualifies as widespread to you, but this is at least a great start. And there are plenty of good implementations to reference.
1) What is the advantage of SPDY over HTTP/1.1? (Besides a possible (and debated?) speed up? (Due to sending assets w/o a request for them?))
2) Is it as easy to debug with tools like curl, wget, and telnet?
2) curl and wget will probably eventually add support. telnet not so much, but then again you can't really debug HTTPS or even HTTP/1.1 (with chunked encoding) with telnet.
openssl s_client is useful for debugging SSL issues. It gives you just about all the info you could want about the certs and then gives you an open pipe to the server that I treat like telnet above.
(Not really trying to argue. As things grow up more tools will support them and engineers like me will learn to adapt and debug them as they do the current generation of protocols.)