Scroll down halfway to the waterfall charts. Out of 35 requests, 31 were for static files, where there is no blocking. These are bandwidth limited so the main difference is whether they complete one at a time somewhat regularly spaced (pipeline) or interleaved (Spdy), but total throughput will be roughly the same.
For the 4 dynamically generated files the HTTP version actually finished these sooner.
"The waterfall diagrams clearly show SPDY's main advantage over HTTP: The use of out-of-order responses. ... [vs HTTP] handling requests in a FIFO fashion".
Oh really? More like the diagram clearly shows they weren't using pipelining. If they had been using pipelining then requests would have been sent immediately instead of blocking. The bars would be blue, with more variety of length but averaging to the same as for Spdy (as clearly this case was bandwidth limited).
To put this into context, they replaced the Android browser that did do pipelining with Chrome and then post a comparison of Spdy vs no pipelining. Seriously ask yourself why they compared Spdy to non-pipelining HTTP to trumpet their +23% claims when they were previously using pipelining. My hunch is they are just lazy and disengenuous... or are they purposely pushing Spdy, or are they incapable of believing Google doesn't produce the best at everything?
I don't know what Google's motivation is with Spdy, but the claims they make are just absurd. The actual real-world problems with pipelining are that some server/proxy software borks it up.
Thanks for the link. I haven't benchmarked pipelining myself, just read others' tests.
Broken servers and proxies should become less of a problem now that iPhone and (non-Chrome) Android browsers enable pipelining by default. And, after many years, Mozilla may enable pipelining by default for desktop Firefox, too:
