[vidarh]

> So unlike the graphs you typically see in chrome network inspector where one resource request ends and another begins, frames (the unit of data) from multiple streams are sent in parallel.

Connections are already processed in parallel whenever they can. That is, when the browser knows what to request, and it fits in the execution model. If there's a huge number of assets on a single hostname, this has been a limiting factor because the browsers have limited the number of requests to a single hostname to avoid overloading the server. But that will remain an issue even if the requests are multiplexed over a single connection.

Most of the time when I see graphs in the network inspector that aren't massively parallel it's because nobody have spent time optimizing where/how assets are requested in ways that will make them just as bad with connection multiplexing.

There certainly can be benefits to reap from it, but the worst offenders are already ignoring best practices.

[youngtaff]

Multiple parallel connections increases the likelihood of packet loss due to network congestion, is also imposes a larger load on servers and intermediate proxies.

A TCP handshake has to take place for each connection and this isn't cost free, and there's the SSL negotiations on top (though techniques like OCSP stapling help)

Going massively parallel isn't free - Will Chan of Chrome did a good write up here: https://insouciant.org/tech/network-congestion-and-web-brows...

[vidarh]

True, but my point is that unlike what zaptheimpaler seemed to imply, if you don't see massively parallel downloads in the network tab already, you are not going to see massively parallel downloads just because you get multiplexed streams, and the sites that do see parallel downloads are already for the most part going to do well.

So the real world impact for users is likely to be small:

Lowering the cost of multiple streams will likely give you decent percentage wise improvements on page download times that are already so good that the absolute improvements are likely to be small, and likely minimal to no improvements on the pages that are actually slow.

[dcsommer]

The real world impact is incredible, not small. Opening new connections is horribly, horribly bad for internet performance. http://www.chromium.org/spdy/spdy-whitepaper

[youngtaff]

Akamai report a 5-20% increase with some sites seeing no improvement.

With the advent of the browser pre-loader then as long as the resources are declared in the markup then the browser should discover them and issue the request.

Currently browsers often seemed to blocked on waiting for a connection to come free