How speedy is SPDY? [pdf]
usenix.org
usenix.org
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.
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.
Hmmm, starting to use it seems like less effort than introducing an entirely new protocol.
> 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.
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.
Can you point to that?
It's a bit sketchy on the details and data - reading it I certainly end up with more questions than answers
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.
End rant. Sorry, but I am not a fan of SPDY.
I agree with the conclusions, mostly the very last one.
> To improve further, we need to restructure the page load process
To fully utilise the potential of HTTP/2, we will have to rethink the way we create and manage websites. I've posted more thoughts on this on my blog; https://ma.ttias.be/architecting-websites-http2-era/
Throwing many TCP connections into a congested network can let you get a higher share of that limited pipe though...
It's somewhat humorous because wireless networks are one of the main purported benefits of SPDY.
The main result is that most of the benefit comes from putting everything through one TCP pipe. This, of course, only works if almost everything on a site comes from one host. This is a good assumption for Google sites, which communicate only with the mothership. It's not for most non-Google sites.
Looking at the facts, it seems pretty obvious that whatever theoretical gains you can get in select scenarios with SPDY, this super-minor gain is not worth it compared to the associated complexity cost.
Not to mention I don't like the idea of Google now not only running the worlds tracking units, the worlds most popular browser and most popular websites, but now also dictating internet-protocols without taking input from other parties.
For most optimised HTTP/1.x sites there's already a complexity cost of merging JS files, merging CSS files building sprites - including the tradeoff of getting the bundles right, which of course reduces cachability.
If you are revving your bundles with hashes (main.8a4ce55.js), caching shouldn't be a problem. Not sure what your build process is, but there are plugins to do this on most setups.
When two separate resources together at build time they're being coupled from a caching point of view if one gets changed and the other doesn't they they both have to be re-downloaded because the bundle has changed.
And all of this is a build-time problem.
If we're going to engineer the HTTP-protocol to solve build-tooling and development related problems, we might as well add JS-linting and minifying to HTTP itself as well.
Seriously: This problem is best solved elsewhere.
Also, this is not part of a big, evil Google master plan. The engineers who developed it are well known and they presumably tried to do their best from a technical point of view.
Just testing SPDY on a site I was building last year, it seemed to provide double digit speedups. Not bad for my effort of typing SPDY into nginx.conf.
So yeah, I dislike Google. I use FF and disconnect search. I hate Google's intrusiveness and anti privacy stance. But at least SPDY provides actual benefits today, versus complaining about standards.