Is relying on a few, large files, as dependencies efficient?

Question

I am developing a web application with many 3rd party javascript and css dependencies. Since I discovered Node.js, bower, and gulp, finding and installing such dependencies has been a breeze. However, I've been aggressively pursuing a policy of concatenating all my javascript into a single file, and ditto for all my stylesheets. After concatenating and minifying, my web application depends only on two fairly large files (main.js and main.css). For reference, my main.js file is 1.6MB in size, and my main.css file is 261KB in size. Not huge by any means, but far larger than any one of the individual dependencies by themselves. Is this optimal, or does the growing size of these files eventually outweigh the optimization gained by making fewer requests? Is there a scenario where this strategy would be a bad idea?

Answer 1

Yes. Not consolidating resources incur network overhead. But when the js gets so big, it should be split.

All major browsers preload your script and css. So, if you split your 1.6 MB js into 3, the browser will load all three and the css together in 4 connections.

You may think the total bandwidth is the same so why bother? But it may be faster, because:

1. It draws more bandwidth from the server.
2. It draws more bandwidth from other programs / service.
3. It draws more bandwidth from other tabs in the same browser.
4. Parts can be parsed and perhaps executed when other parts are still downloading.
5. If you update only one of the parts, the other parts can be read from cache.

1.6MB is very big, and you should see speed improvement if you split it up. But the sweet spot depends on a lot of factors, so you need to experiment to see what part size work best for you.

In fact, it is so big, you should defer the script, as Mr_Green commented. Let your css and html go first, show a loading icon, and then load your big scripts.