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: https://insouciant.org/tech/prioritization-is-critical-to-sp...
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.
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
pipelining can break sites because of broken proxies that don't understand pipelining (and there are many). without pipelining, keep-alive only saves you from extra TCP connections. This is a big improvement, but not enough to go all the way to what SPDY offers.
Yeah, this is a pretty old post.. Domain sharding, which is how resource rich sites enhance parallel loading, doesn't suit SPDY at all.
domain sharding has been unnecessary since 2011 when browsers increased the number of parallel connections they make to a single domain. With these increased connections, domain sharding might end up hurting performance if all shards point to the same IP address. This is so because many home wireless routers and DSL modems start dropping packets if too many SYNs go out to a single IP without an ACK coming back -- they think the client is mounting a DoS attack and try to block it.