0

I always hear in production, you want to combine multiple .js files into 1 to make it load faster.

But since browser actually makes multiple request concurrently, there's a chance that multiple files can be loaded faster than a single file, which has to be downloaded from beginning to end.

Is this reasoning correct?

JJJ
  • 32,902
  • 20
  • 89
  • 102
Saitama
  • 477
  • 6
  • 18
  • another point is that you might be combining files that user has already cached because they're popular eg. jquery. – apieceofbart Jul 25 '16 at 06:28

3 Answers3

1

It's a complex area.

The browser making multiple concurrent connections to the same server (which are usually quite limited in number) doesn't make the connection between the client and server faster. The pipes between them are only so big, and the server only has so much delivery capacity. So there's little if any reason to believe 4 parallel downloads, each of 10k, from the same server are likely to be faster than 1 download of 40k from that server. Add to that the fact that browsers limit the number of concurrent connections to the same server, and the expense of setting up those individual connections (which is non-trivial), and you're still better off with one large file for your own scripts.

For now. This is an area being actively developed by Google and others.

If you can load scripts from multiple servers (for instance, perhaps load common libraries from any of the several CDNs that make them accessible, and your own single combined script from your own server [or CDN]), it can make sense to separate those. It doesn't make the client's connection faster, but if the client's connection isn't the limiting factor, you can get a benefit. And of course, for a site that doesn't justify having its own CDN, loading common libraries from the free CDNs and just your own scripts from your own server lets you get the advantage of edge-casting and such on the scripts you load from the free CDNs.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
0

For Large JS files:

Not Good idea,If you have small JS files then its good idea to merage otherwise suppose if JS files is more than 500kbs then single file will make in MBS and take huge loading HTTP request time.

For small JS files:

Good idea ,for small it has good idea but its better to use only 3rd party tool which will also compress your final single file so that HTTP request time will take less time. I would suggest using PHP Minify(but you can find other which suit you), which lets you create a single HTTP request for a group of JS or CSS files. Minify also handles GZipping, Compression, and HTTP Headers for client side caching.

demo status of PHP minify

Before

enter image description here

After

enter image description here

sms247
  • 4,404
  • 5
  • 35
  • 45
0

It depends on if your server is HTTP/2 or HTTP/1.1.

HTTP/2

HTTP/2 (H2) allows a server to quickly respond to multiple requests, allowing the client to streamline all the requests without waiting for the first one to return and parse. This helps to mitigate the need for concatenation, but doesn't entirely remove it. See this post for an in-depth answer to when you should or shouldn't concatenate.

Another thing to keep in mind is that if your server gzips your assets, it can actually be better to concatenate some of them together since gzipping can perform better on larger files with lots of repeating text. By separating all your files out, you could actually hurt your overall performance. Finding the most optimal solution will require some trial and error (a lot of this is still new and so best practices are still being discovered).

HTTP/1.1

With HTTP/1.1, as the other answers have pointed out, for the majority of cases combining all your files into one is better. This reduces the number of HTTP requests, which can be slow with HTTP/1.1. There are ways to mitigate this by requesting assets from different subdomains to allow multiple concurrent requests.

I recommend reading High Performance Browser Networking for a complete understanding on strategies for HTTP/1.1.

Community
  • 1
  • 1
Steven Lambert
  • 5,571
  • 2
  • 29
  • 46