Does SPDY/HTTP2 concatenates responses?

Question

I have a question about SPDY/HTTP2: Normally you concatenate multiple CSS and JS files into one file to save requests and to get a better performance. I heard that SPDY/HTTP2 combines multiple requests into a single response. Would that mean that I don't need to pre-concatenate CSS and JS files anymore, because this is handled by the protocol?

To say it in other words: Can I use <script source="moduleA.js"></script> and <script source="moduleB.js"></script> with SPDY/HTTP2 in the same way as I would use <script source="allScripts.js"></script> with HTTP1? Is this the same from a response performance point of view, but with the benefit of caching each file on its own, so that I can change moduleB.js and keep moduleA.js cached?

Schappe

Answer 1

HTTP/2.0 does not (AFAIK) exist yet - it's still a proposed standard. But it seems likely that it will use similar connection handling to SPDY.

SPDY doesn't concatenate them it multiplexes the requests across the same connection - from the network's point of view the effect is the same.

Yes, you don't need to merge the content files by hand, yes they will be cached independently.

Model

Is there any kind of real world analysis available for this that goes beyond hello world? – Jacksmelt

Answer 2

SPDY3 and HTTP2 are multiplexing requests on the same physical connection. But even multiplexed, requests may be sent sequentially for each resource, causing major slowdowns due to roundtrip time waits.

Both SPDY3 and HTTP2 have a feature called "Resource Push" (also known as "SPDY Push", not to be confused with "Server Push") that allows related resources to be pushed without the client requesting them, and the Jetty project - I am a committer - is the only one to my knowledge that implements that feature.

You can watch Resource Push in action in this video: http://webtide.intalio.com/2012/10/spdy-push-demo-from-javaone-2012/.

With Resource Push, you save additional roundtrips to get all the different JS files and still benefit of the browser cache per single file. The whole point of resource concatenation is exactly to reduce the number of roundtrips necessary to get all the resources needed, and Resource Push helps to solve that problem.

Waggle

Answer 3

HTTP/2.0 allows for multiplexing, where multiple request/response streams exchange data over the same TCP connection.

Because creating and starting TCP connections is expensive, HTTP/2.0's multiplexing will usually be faster than the semi-parallel downloading of HTTP/1.1, where a limited amount of TCP connections is (re)used by the browser to perform a given amount of requests for resources.

But your mileage may vary. Measure it.

As a sidenote, you might want to reference all your libraries separately when developing and debugging, but bundle and minify the JS/CSS into one file upon a deploy.

Fluorosis

Sorry - but this is very confusing and wrong in several places. creating and starting TCP connections is expensive - yes, but keepalive and pipelining has been around for a long time - browsers have been re-using connections for at least the last 12 years. SPDY does not change this behaviour - it does away with the need for in-order delivery of requests on a single channel. SPDY can quite easily use multiple chanels - with the same caveat of undermining TCP slow start. – Model

@Model I did not intend to write a full comparison between HTTP/1.1 and 2.0. OP asks: will it make any difference between bundling files over HTTP/1.1 and not bundling files over HTTP/2.0, to which I responded by explaining the difference multiplexing can bring to the explained situation. Please point out where I am wrong. – Fluorosis