Now that SPDY has been enabled across our projects (T35890), it's time to start thinking about various optimizations we could do to take more advantage of it.

Right now, connecting to production means estabilishing a lot of different connections with different domains & IPs, which means RTTs wasted to make a TCP & TLS handshake and not taking advantage of SPDY's multiplexing.

It should be noted that:

• SPDY has a feature called "IP pooling", in which UAs opportunistically multiplex over the same session requests to different domains that a) resolve to the same IP and b) are valid according to the TLS/X.509 certificate presented. The latter is not the case for projects vs. wikimedia.org and would need new certificates, with a non-trivial cost attached to them.
• Completely undoing domain sharding will have an impact for non-SPDY clients, which would need to be factored in and taken into account as a tradeoff.

So far we have:

1. bits (T95448) — we should probably fold bits into text. This can happen at least in the edge caching layer (which we'd probably want to do anyway). bits is also sort of a hack MediaWiki-wise with Varnish rewriting URLs, so we could possibly undo all of it with the caveat of undoing an optimization for non-SPDY UAs.
2. upload — problematic for multiple reasons: at least security separation for third-party data and possibly Wikipedia Zero IP-based traffic separation. upload is also much heavier in traffic than text and the distinction is now an implicit load-balancing technique. A potential merge would present scalability problems with at least LVS & Varnish.
3. login.wikimedia.org (for checkLoggedIn), meta.wikimedia.org (CentralNotice, gadgets) — theoretically good candidates for SPDY IP pooling, with the caveat of the certificate troubles mentioned above. Those two should already use the same SPDY connection now, but in quick tests I've done they do not appear to do so, although I see a common connection between login/commons. This needs further debugging.
4. www.mediawiki.org, commons.wikimedia.org, <random projects> (gadgets) — already a performance issue, not much we can do about them; hopefully Gadgets 2.0 can.