This is the first release with SPDY enabled by default. Once most Firefox users have updated, about half of all web traffic will be from SPDY-enabled browsers.
Chrome has had SPDY enabled for at least a year now -- since around Chrome 10, I think? And according to Statcounter measurements for this month to date [1], 28.75% of all page views currently come from Chrome 19.
From the same Statcounter numbers, 17.27% of all page views are from Firefox 12. So that's over 46% of page views this month using the latest versions of Chrome and Firefox. And another few percent are just one or two versions behind. So a couple of months from now, 50% of page views measured by Statcounter should come from SPDY-enabled browsers, especially if IE marketshare keeps shrinking rapidly.
Also interesting: according to that graph, as of June 2012, Firefox's major stable release at last surpassed IE's major stable release--just a few months shy of the 10-year anniversary of the release of Firefox 0.1.
EDIT: Ha, actually, drilling back further, looks like that's not true at all: Firefox's major release has surpassed IE9 for a while now. I was misled by IE9's slow adoption curve.
Apparently not. There's an ever growing tail of users who get stuck with an outdated version [1]. It's not as bad as Firefox yet but surprising nonetheless given how much effort Google put into Chrome's update system.
I have personally experienced and seen Chrome get “stuck” and kind of just fail to update itself until a manual re-download of the installer is performed. It does usually work, but sometimes just stops. For example, I recently saw a bug report from someone who thought they were on the most recent version of Chrome — 10. (It’s currently at 19 or so.)
Well, about 12% of Chrome page views are from old versions so "almost no users" is a bit of a myth or exaggeration. But it's definitely a smaller proportion than other browsers.
Firefox also auto-updates, but has a longer tail of users from old versions since it's been around longer and had a more obtrusive update process until recently. Currently about 32% of Firefox page views come from old versions, but this is decreasing steadily now that Firefox 3.6 users are being auto-updated to the current release channel, and now that updates are more "silent."
Once SPDYv3 is enabled in a release channel the Chrome installations which only support an outdated SPDY version will rise suddenly if the current update trend is not reversed in a future version.
Score one for mediocrity. Microsoft's Speed + Mobility version of Spdy has some good improvements, but I guess Google will just declare their version to be the standard.
Also Spdy only had 23% faster page load times than non-pipelined HTTP (in other words, enabling networking.http.pipelining is just as good).
SPDY is not something that Google just implemented and froze as a standard. Mozilla and others are still working on the SPDY spec in the IETF, and we're happy to see improvements. Mike Belshe continues to work on evolving the SPDY protocol even though he no longer works for Google. The latest development builds of Chrome and Firefox have just been updated to SPDY draft3.
So speaking for Google, if IETF results in changes from Speed + Mobility then Google will commit to implement it?
From what I can see the Spdy draft 3 doesn't include any improvements from Speed + Mobility so I don't see the relvance of your post. It's a shame because Speed + Mobility has real improvements (yes Microsoft does things right sometimes).
"Our plan is to continue what we've been doing: experimenting with new ideas in SPDY and recommending the good ones for standardization in IETF (http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00). In the end, we only want one protocol, so we don't intend to keep a SPDY track alive longer than a successful standards process."
Out of curiosity, what changes from Speed + Mobility would you like to see in SPDY? We'd love to hear your recommendations on spdy-dev@googlegroups.com.
What changes would I like to see? I'd like to see you work with Microsoft (and others) to improve the protocol. Microsoft with S+M has made real improvements.
Ask them. They know their stuff.
For me though, I think Microsoft held back on changes so it would be more accepted as Spdy-like. For instance the whole HTTP format seems pretty lame to me... a 16-bit string length count... amazing, iirc it's 32-bit now but who ever thought that was a good idea?!
Umm, I can't speak for Google, because I work for Mozilla. I can't speak for Mozilla's networking team either, since I'm a UI developer on the mobile team. But I feel safe saying that Mozilla is (a) committed to the standards process and (b) wants whatever final result is best for our users.
If you have questions about Mozilla's SPDY and HTTP plans, or if you want to suggest areas of work (or even contribute yourself!), you should attend the networking team meetings [1], join #networking on irc.mozilla.org, or ask on mozilla.dev.tech.network.
SPDY is in a better position to dictate the development of HTTP 2.0 as there are already two independent implementation in the wild, unlike S+M which so far only exists as a concept paper AFAIK.
That's a shame, since S+M has the potential to become the true next-gen HTTP, an improvement for everyone, while SPDY only is useful for "the elite" websites who has purchased a SSL certificate.
Most small websites with no need for SSL, unless they're hosted on a service like Tumblr or Webly, will be stuck on HTTP 1.1 "forever". It sucks that independently hosted "real" websites will have a technological disadvantage to websites hosted on third-party services unless they're willing to shell out a not insignificant amount of money ($15+ USD per year per site).
Personally, I'm glad that SPDY is providing an incentive for people to use SSL.
Also, just because SSL costs money today (it doesn't if you use startssl.com), doesn't mean it will continue to do so into the future. DANE (once the spec is finalised) will allow people to store fingerprints of their SSL certs in DNS records, signed using DNSSEC. This will remove the existing CAs from the loop.
Cool, I hadn't heard about DANE/DNSSEC. How automated will the process be?
I hope you don't have to apply/renew it manually. Buying a SSL certificate and installing it was a hassle even for me (a geek), it would have been horrible for a normal website owner.
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:
