Single bundle with minification vs multiple files over http/2

Question

What is the general recommendation when it comes to CSS and JS bundling: Is it better to bundle everything into one file or is it better to serve multiple files?

I personally say that multiple files are better, especially with http/2, but there're good reasons for bundles: Minification and gzip have better results when everything is in one file, because of all the recurrences you typically have when writing lots of code. Serving multiple files on the other side improves caching and allows parallel downloads, but includes equal code across files that could have been minified.

Are there any good statistics that compare file size, compression size and download times for multiple and bundled files?

There're already several topics on Stack Overflow regarding this question, but I wasn't able to find one that takes http/2 and minification/gzip into mind as much as I would like.

Wormwood

I have been actually wondering the same for a site I have been optimizing. Normally I would go with "many" files, where "many" is three or four. But in a Wordpress site "many" means an entirely different thing, and the overhead in request processing, exchanged headers and missed compression opportunity may be a lot more significant. I have to make the time to dig into the data up to the level of HTTP/2 headers though. – Haugen

Possible duplicate of Optimizing File Cacheing and HTTP2 – Irremeable

I don't think there's an answer for all, the best way is always doing some tests before you decide. – Coen

Answer 1

Here are some of the features of http/2 that mitigate the benefits of concatenation (from High Performance Browser Networking):

Bundling multiple assets into a single response was a critical optimization for HTTP/1.x where limited parallelism and high protocol overhead typically outweighed all other concerns—see Concatenation and Spriting. However, with HTTP/2, multiplexing is no longer an issue, and header compression dramatically reduces the metadata overhead of each HTTP request. As a result, we need to reconsider the use of concatenation and spriting in light of its new pros and cons:

• Bundled resources may result in unnecessary data transfers: the user might not need all the assets on a particular page, or at all.

• Bundled resources may result in expensive cache invalidations: a single updated byte in one component forces a full fetch of the entire bundle.

• Bundled resources may delay execution: many content-types cannot be processed and applied until the entire response is transferred.

• Bundled resources may require additional infrastructure at build or delivery time to generate the associated bundle. Bundled resources may provide better compression if the resources contain similar content.

...

HTTP/2 removes this unfortunate trade-off by providing support for request and response multiplexing, which means that we can now optimize our applications by delivering more granular resources: each resource can have an optimized caching policy (expiry time and revalidation token) and be individually updated without invalidating other resources in the bundle. In short, HTTP/2 enables our applications to make better use of the HTTP cache.

I don't think that recurrences will decrease file size very much. Also, the file size is just one aspect of latency and percieved speed. For example, even if the initial load is faster, what happens when the user visits for a second time? What if one file needs to be invalidated?

Although I have not seen any specific data regarding your question, here are results from Google for http/1.1 vs SPDY, a predecessor to http/2:

Ultimately the answer to your question will be an opinion, unless someone does some testing to find out.

Electrician

Answer 2

From the Front-End Performance Checklist 2017:

Again, serving assets over HTTP/2 requires a major overhaul of how you’ve been serving assets so far. You’ll need to find a fine balance between packaging modules and loading many small modules in parallel.

On the one hand, you might want to avoid concatenating assets altogether, instead breaking down your entire interface into many small modules, compressing them as a part of the build process, referencing them via the “scout” approach and loading them in parallel. A change in one file won’t require the entire style sheet or JavaScript to be redownloaded.

Still, you can try to load CSS progressively. Obviously, by doing so, you are actively penalizing HTTP/1.1 users, so you might need to generate and serve different builds to different browsers as part of your deployment process, which is where things get slightly more complicated. You could get away with HTTP/2 connection coalescing, which allows you to use domain sharding while benefiting from HTTP/2, but achieving this in practice is difficult.

What to do? If you’re running over HTTP/2, sending around 10 packages seems like a decent compromise (and isn’t too bad for legacy browsers). Experiment and measure to find the right balance for your website.

Wormwood