[dcsommer]

Consider if the client makes a large POST followed by a few GETs. If the client has little upload bandwidth, the GETs will be delayed until the POST completes. With SPDY, they all can proceed concurrently. Similarly, if the client makes 5 GET requests, with the first being a heavy/slow/expensive resource for the server, the cheap resources can't be delivered until the slow resource finally is computed and returned.

[thwarted]

Yes, that's the reason that SPDY exists, but my point is that that's actually a rare implementation in the real world. As was said elsewhere in this thread, and what I was saying, is that the most likely implementation is that one request goes to, say, www.example.com, which serves a single HTML file, and remaining requests for resources that that HTML references go to outsourced-cdn.example.com. So it's actually more important to have pipelining and SPDY support on outsourced-cdn.example.com than it is on www.example.com. That is, chances are you don't need to worry about it, that's why you pay outsourced-cdn to. There is less of a need for multiple simultaneous requests when you have good client-side caching of resources too. The usefulness of multiplexed requests is negated if you only serve one request.

The above has been the exact case at a number of companies I've worked at.

Sites and companies like Google or Facebook, that serve all their own traffic, it becomes more important for.