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.
(about:config, network.http.spdy.enabled = true)
[Note: I am a Firefox developer.]
[Note: I literally just downloaded it, upgraded, and had this experience.]
The bug is 8 years old and nobody seems to be working on it. I wouldn't hold my breath that it will be fixed soon.
[1] http://arstechnica.com/information-technology/2012/06/may-br...
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.
[1] http://gs.statcounter.com/#browser_version-ww-monthly-201206...
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.
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."
Stats are based on http://gs.statcounter.com/#browser_version-ww-monthly-201206... and http://gs.statcounter.com/#browser-ww-monthly-201206-201206-...
Lots of detail about SPDY for those like me who didn't know.
Also Spdy only had 23% faster page load times than non-pipelined HTTP (in other words, enabling networking.http.pipelining is just as good).
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).
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).
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.
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.
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.
"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.
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?!
https://developers.google.com/speed/articles/spdy-for-mobile
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.
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:
Bug 264354 - Enable HTTP pipelining by default https://bugzilla.mozilla.org/show_bug.cgi?id=264354