Not as SPDY as You Thought

This was on HN eight months ago, when the post was actually made. And the takeaway is pretty clear, you probably won't see a benefit in using SPDY in front of a site optimized in ways that don't take advantage of SPDY's strengths. If you want to see big improvements with SPDY (like Google does) then you need to adjust how you're serving your resources. Resource prioritization is a perfect example of this: <a href="https://insouciant.org/tech/prioritization-is-critical-to-spdy/" rel="nofollow">https://insouciant.org/tech/prioritization-is-critical-to-sp...</a>

<a href="http://www.belshe.com/2012/06/24/followup-to-not-as-spdy-as-you-thought/" rel="nofollow">http://www.belshe.com/2012/06/24/followup-to-not-as-spdy-as-...</a>

Like others said, an old post. To be sure, he is testing the SPDY speed from a client to a SPDY proxy that then connects to a real HTTP site.<p>It makes no sense to correlate these results with real SPDY web servers serving real traffic.

Http vs Spdy: He didn't mention http features like, keep-alive and pipelining both can make huge difference when sending data over connection having notable latency

Yeah, this is a pretty old post.. Domain sharding, which is how resource rich sites enhance parallel loading, doesn't suit SPDY at all.