FWIW, Opera 12.1 and Firefox 15+ support SPDY, so it's not a Google-only protocol. The only major browsers left are Safari and IE, which are both slow at adopting new tech.<p>Source:<p><a href="http://caniuse.com/#search=spdy" rel="nofollow">http://caniuse.com/#search=spdy</a>
I'm so surprised that the security consideration section has no reference to CRIME [1], which has made Google and Mozilla to turn off SPDY's header compression in Chrome and Firefox.<p>[1] <a href="https://docs.google.com/presentation/d/11eBmGiHbYcHR9gL5nDyZChu_-lCa2GizeuOfaLU2HOU/present#slide=id.g1d134dff_1_100" rel="nofollow">https://docs.google.com/presentation/d/11eBmGiHbYcHR9gL5nDyZ...</a>
<a href="http://www.guypo.com/technical/not-as-spdy-as-you-thought/" rel="nofollow">http://www.guypo.com/technical/not-as-spdy-as-you-thought/</a><p><i>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.</i>
While I appreciate SPDY, what's the point of a draft if adoption is so far not widespread?<p>Google's documentation seemed quite sufficient to implement, and until we have a proper reference implementation, this seems a little half-cocked.<p>Maybe I misunderstand the point of the IETF draft?
I guess this is my naïveté showing:<p>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?))<p>2) Is it as easy to debug with tools like curl, wget, and telnet?
there should be a disclaimer that you will only see performance gains if you make a lot of HTTP connections on your site. people expect some magic happening once they install SPDY, which is just not the case. but if your site is heavily on SSL, then you have nothing to lose by installing SPDY, but not much to gain either.