> Most performance impact of SPDY over HTTP comes from its single TCP connection
This is not a surprise at all, because Google never tested SPDY against HTTP pipelining. And at least in their mobile test they included the TCP connection time for HTTP but not for SPDY; I suppose their test software just reused the same SPDY connection since the mirrored web pages all were served from the same IP.
They compressed sensitive headers with data leading to CRIME attacks.
They had a priority inversion causing Google Maps to load much slower through SPDY than HTTP.
This new protocol is a complete mess, from beginning to end.
Leaving aside the technical statements about SPDY, the reality of HTTP pipelining is that no-one uses it. According to Wikipedia, Opera is the only major browser that ships with pipelining enabled. Most intermediaries don't support pipelining either.
Pipelining was a well-intentioned feature which didn't solve the core problem: namely, that a big or slow request can block you from doing anything else for a really long time unless you open another TCP connection.
Except that Microsoft tested SPDY against pipelining and found that pipelining was essentially just as good. So we're left with a situation where Google could have used HTTP pipelining over SSL (so there's no buggy proxies interfering, just like what SPDY does) and gotten pretty much all the benefit with no extra complications at all, but instead there's old HTTP and a new, much more complicated protocol.
And this "head of line blocking" problem... who said it was a problem, Google? In reality you have 4 or more connections that automatically work like spread spectrum where most resources aren't stuck behind a big or slow request. But even if this was an actual problem, a simple hint in the HTML that the resource might take a while and to put other ones on a separate connection would optionally solve this problem, and with almost no extra complexity.
>> the core problem: namely, that a big or slow request can block you from doing anything else
> Why is that the core problem?
Head of line blocking leaves the network idle, and one of the key factors to good front end performance is to overcome network latency and start using the network / growing the congestion window as soon as possible.
I'm pretty sure Opera doesn't ship with it enabled any more, since the move to Chromium. There were all kinds of crazy heuristics to work out whether to use pipelining or not.
"...Google never tested SPDY against HTTP pipelining."
I use pipelining on a daily basis. And, vis-a-vis using HTTP/0.9 or 1.0, I have never been dissatisfied. It just works. (Before you comment, please note I never said I make my HTTP requests using a particular browser.)
This is why I can never take SPDY for what they say it is (or what the silly acronym suggests).
And if in fact the goal was faster speeds and in fact this alternative was faster, why should I accept the opacity it introduces? Does this protocol make it easier or more difficult to view one's own traffic?
Once more, with HTTP pipelining I only request the resources I want. In my case, this does not include advertisements. Is that possible with SPDY? I do not know, but I doubt they would promote such fine grained selection as a feature.
If HTTP pipelining does not work satisfactorily in [ad-supported browser], does that necessarily mean it does not work, full stop? I have tested it thoroughly and my answer is no; but I could be biased.
Because HTTP pipelining has worked beautifully for me over the years, I would be quite disappointed if it were supplanted by some protocol introduced a company that relies on ad sales to stay in business.
This is not a surprise at all, because Google never tested SPDY against HTTP pipelining. And at least in their mobile test they included the TCP connection time for HTTP but not for SPDY; I suppose their test software just reused the same SPDY connection since the mirrored web pages all were served from the same IP.
They compressed sensitive headers with data leading to CRIME attacks.
They had a priority inversion causing Google Maps to load much slower through SPDY than HTTP.
This new protocol is a complete mess, from beginning to end.