What are the benefits of concatenating all Javascr

For example, if you have

<body>
    <script src="someLibrary.js"></script>
    <script src="someLibrary2.js"></script>
    <script src="someLibrary3.js"></script>
    <script src="someLibrary4.js"></script>
    <script src="myApp"></script>
</body>

What is the benefit aside from prettiness in the html to having all of those be concatenated and minified by a task running (Grunt/Gulp) before sending it to client in form of

<body>
    <script src="allTheJavascripts.js"></script>
</body>

回答1:

Combining multiple JS files into one file has the following benefits:

Browsers can download a single file more efficiently and faster than downloading multiple smaller files. One http connection downloading the file is usually faster than many http connections downloading smaller files.
The browser has a limit on how many simultaneous connections it will make to the same domain and, if it reaches that limit, some connections have to then wait until others finish. This causes delays in download. Downloading fewer files make it less likely to hit this limit. This limits applies to all connections to a domain (download of JS files, download of CSS files, download of frames, ajax calls, etc...).
Server scalability can be increased because each page download requires fewer http connections to serve the content.
There are cases where version control and the interaction between version upgrades and browsing JS file caching can be simpler with one larger JS file. When all your JS files are concatenated, you can assign a single version number to that combined JS file (like jQuery does with its versions). Then, any change to the JS anywhere causes a bump in the version number for the master combined file. Since a given browser gets the entire combined file all or nothing, there is never an opportunity for a browser to accidentally get one version of one file fresh from the server and another version of another file from a stale browser cache. Also, maintaining one master version number is a lot simpler than versioning lots of smaller files.

Minifying a JS file makes it smaller to download and parse which increases download performance.

If you are both combining multiple files AND minifying, the minifying can be more effective. When minifying multiple small files separately, you cannot minify variable names that are shared between the different files - they must retain their original names. But, if you combine all the JS files and then minify, you can minify all symbols that are shared among the different JS files (as long as they aren't shared externally).

Obviously, there are some limits here and things don't get arbitrarily better if the whole world puts their JS into one file. Some things to think about when deciding what to package together into one file:

You don't want a large group of your pages to be parsing and executing a large block of code that they will not use. This is obviously a tradeoff because if the code is being effectively cached, then it's not so much a download issue, but rather just a runtime efficiency issue. Each use will have to decide how to draw that tradeoff line.
You may not want to package code that is revised fairly regularly with code that hardly ever changes because this degrades the efficiency of browser caching if the large combined JS is always changing.
In a team environment with multiple projects sharing code, it is very important to think about packaging things into combined and minified chunks that work for the largest number of projects sharing the code. You generally want to optimize the packaging for the broader needs, not just for a single project.
Mobile access often has smaller caches, slower CPUs and slower connections so its important to consider the needs of your most accessed mobile pages in how you package things too.

And some downsides to combining and minimizing:

Directly debugging the minimized site can be quite difficult as many symbols have lost their meaningful names. I've found it often required to have a way of serving an unminimized version of the site (or at least some files) for debugging/troubleshooting reasons.
Error messages in browsers will refer to the combined/minimized file, not to the actual source files so it is can be more difficult to track down which code is causing a given browser error that has been reported.
The combined and minimized site has to be tested to make sure no issues were caused by these extra steps.

回答2:

Many browsers limit the number of concurrent HTTP requests to a particular domain. Concatenating the JavaScript files reduces the number of HTTP requests needed, allowing the files to be downloaded faster.

The same is true for CSS files.

Separately, such combined files are sometimes put through a minification process that produces syntactically equivalent files, that are smaller.

One downside is that, if any component file changes, the cache for the entire combined file must be invalidated and the combined file reloaded. This is a very small downside for most scenarios.

回答3:

Very simple:

Reduced Latency (1 file mean one HTTP GET) traded for wasted bandwidth and unnecessary consumption of memory resources. (Scripts needs to be loaded, parsed, execute even if not needed)
More difficult to debug (1 import) vs. easier to read.

If your page is definitely going to use them all, then go ahead and load them as one. But that's a gross over assumption that generally breaks down. As a general rule, monolithic code base is bad.