SPDY is an alternative protocol to HTTP that is specifically designed to reduce page load times. I heard that Google Chrome, Firefox, and Internet Explorer 11 support it. Google uses it to load pages. Will Stack Exchange sites start supporting it? More info: http://isspdyenabled.com/ (should give YES result on Chrome, Firefox, and Internet Explorer 11 (in Windows 8.1, not Windows 7))

  • The standard SE policy is they don't support things that aren't official standards, same deal with the numerous requests for different HTTP status codes that have popped up. – Richard J. Ross III Sep 14 '13 at 18:24
  • 8
    @RichardJ.RossIII - Hardly the issue here, though true enough. We use IIS on Windows - until Windows supports SPDY natively, we most probably won't. See: stackoverflow.com/questions/6210557/spdy-module-for-iis7 – Oded Sep 14 '13 at 18:25
  • 1
    @Oded why not make it official response with status-deferred then? :) – Shadow Sep 14 '13 at 19:11
  • 1
    @ShaWizDowArd - It is more of an educated guess than an official response - need to talk it over with other team members before making it "official". – Oded Sep 14 '13 at 19:20
  • @ShaWizDowArd - It is possible that some of our infrastructure can (or already does) support spdy - for instance the HAProxy nodes. I just don't know enough to give an authoritative answer without consulting with some of the more ops devs... – Oded Sep 15 '13 at 8:59
  • 1
    @Oded I guess Nick knows more, can you Summon him? :-) – Shadow Sep 15 '13 at 9:00
  • @ShaWizDowArd - Sunday is the weekend for him (and me, actually). I am sure it can wait for Monday. Most of the Western world doesn't work on Yom Rishon ;) – Oded Sep 15 '13 at 9:01
  • 3
    @Oded sure thing, just don't let it become 6-8 weeks! ;) – Shadow Sep 15 '13 at 9:22
  • It's not an "alternative protocol." It's still HTTP, it just modifies how information is sent over the wire. – Michael Irigoyen Nov 8 '13 at 15:41

Nope, not in the foreseeable future.

Why? Almost all of the gains from SPDY come from many requests on a single connection - it's designed around removing duplication and advances in compression over HTTP by not doing extra work, mainly:

  • Spinning up multiple TCP connections (one shared, rather than one per request)
    • avoiding TCP slow start as a result
  • Compressing things like headers (including cookies) sent every request (we can only send them once too!)

All of this is good stuff, it's awesome...if you have multiple requests. However, you don't send multiple requests to us on a page load, we do our best to make sure of that. You make a single request to us on almost every page, then additional requests to our CDN, but not to us. Take a look at this page, what do you get from our data center? The HTML for the page then in the background, later a token that we use to track view counts on questions (but you don't see or feel the load time on this).

If HAProxy implements SPDY support/batching later (not pass through) we'll of course take a look, but as it stands now the protocol itself doesn't really gain us much except another layer to debug and very little to no more performance for our users. Given that, it's just not a win.

Also, practically speaking SPDY requires SSL (technically it's not required, I'm aware), which we haven't deployed yet. We're working with the HAProxy author on a bug that causes our load balancer to overload and stop responding suddenly - let's just go ahead and agree it's best we not deploy that until we find the cause. After that's solved we'll have more to talk about with respect to what's going default SSL - the latency penalty is pretty severe, especially for our non-US users.

When you're as big as google and you're not using a CDN then SPDY makes a lot more sense, not so much for us...at least not yet.

  • So, if all of Stack Exchange content came from only the Stack Exchange servers and not from a CDN, SPDY would be implemented earlier? – user215114 Sep 17 '13 at 15:09
  • @gparyani Not earlier, more of at all...that's when it would make sense. But that would mean slower content for everyone outside the eastern US, plus we couldn't handle the bandwidth of serving our own static content at peak traffic after a build anymore I'm pretty sure. In either case that scenario would only result in a slower page load for most of our users. – Nick Craver Sep 17 '13 at 15:42
  • So you mean that it would bias those living in eastern U.S.? – user215114 Sep 17 '13 at 15:44
  • In the end, would this be status-deferred or status-declined? – user215114 Sep 17 '13 at 15:47
  • @gparyani It biases towards those by sheer speed of light, yes. For status: [status-declined] at the moment since it just doesn't make sense, but our architecture shifts to meet our needs all the time. Will we have data centers all over the world this time next year? Maybe. We'll be discussing that in a few weeks when the dev and sysadmins teams head to NYC for a meetup. – Nick Craver Sep 17 '13 at 19:09
  • So, what were the results of the meetup? – user215114 Nov 7 '13 at 22:49
  • @gparyani we may do away with the CDN, kinda, sorta :) A global local proxy where SPDY makes sense and moves termination local for example. We'll be actually putting some changes to the test in a few months - busy wrapping up other things right now. – Nick Craver Nov 8 '13 at 0:53
  • So, has the HAProxy bug been sorted out yet? – user215114 Nov 8 '13 at 1:24
  • @gparyani yep - you can access all our primary domains on SSL now, we'll be working on the mixed content in the coming weeks. SQL upgrade this weekend is the focus at the moment. – Nick Craver Nov 8 '13 at 1:27
  • You should update the answer then. – user215114 Nov 8 '13 at 1:29
  • MaxCDN just added support for SPDY... blog.maxcdn.com/now-serving-spdy-3-1 You guys are still using them as your CDN provider, right? – Steve Wortham May 28 '14 at 22:10
  • @SteveWortham We are not, we are using CloudFlare which is more than a CDN and actually lets us use SPDY for acceleration when we begin proxying through them (they've had SPDY support for some time). – Nick Craver May 29 '14 at 1:44

You must log in to answer this question.