How to Organize Minification and Packaging of CSS and Js Files to Speed Up Website

Does minified JavaScript code improve performance?

Minifying improves performance for your page overall by decreasing the load time (even if only slightly).

Neither minifying nor obfuscating alter the execution time by any perceivable amount for the vast majority of JavaScript code out there.

I do recommend minifying for those reasons and more. Minifying multiple scripts together (like jQuery and its plugins) can yield even greater savings.

As pointed out, on constrained devices and/or with very large codebases minifying could yield a noticeable result.

Does minifying and concatenating JS/CSS files, and using sprites for images still provide performance benefits when using HTTP/2?

They're still useful. HTTP/2 reduces the impact of some of these practices, but it doesn't eliminate their impact.

Minification remains as useful as ever. Although HTTP/2 introduces new compression for message headers, that has nothing to do with minification (which is about message bodies). The compression algorithms for message bodies are the same, so minification saves just as much bandwidth as it did before.

Concatenation and sprites will have less of an impact than before, but they will still have some impact. The biggest issue with downloading multiple files instead of a single file with HTTP/1 isn't actually an HTTP-side problem, per se: there is some bandwidth-based overhead in requesting each file individually, but it's dwarfed by the time-based overhead of tearing down the TCP/IP session when you're done with one file, then starting up a new one for the next, and repeating this for every file you want to download.

The biggest focus of HTTP/2 is eliminating that time-based overhead: HTTP/1.1 tried to do this with pipelining, but it didn't catch on in the browser (Presto is the only engine that got it completely right, and Presto is dead). HTTP/2 is another attempt, which improves on HTTP/1.1's methods while also making this kind of thing non-optional, and it stands to be more successful. It also eliminates some of the bandwidth-based overhead in making multiple requests, by compressing headers, but it cannot eliminate that overhead completely, and when downloading multiple files, those requests still have to be made (as part of a single TCP/IP session, so there is less overhead, but not zero). So while the impact of concatenating and spriting is proportionally smaller, there is still some impact, especially if you use many files.

Another thing to consider, when it comes to concatenation and spriting, is compression. Concatenated files of similar types tend to compress better than the individual files do, because the compression algorithm can exploit similarities between the concatenated pieces of data. A similar principle applies to sprites: putting similar images in different regions of the same file usually results in a smaller file, because the image's compression can exploit similarities in the different regions.

Deploying my site, lots of small script files. Long loading time

Join all JavaScript and all CSS files into one big JS and one big CSS file, and minify them.

Is there a benefit to pack third-party JS & CSS libraries along with my project assets?

It depends.

You should try packing everything together, measure the file size, and see how much space you save versus separate library files. You can at least then compare that saving against other factors.

How you balance HTTP requests vs. total bytes is pretty much up to you. If lots of your users are on mobile connections, additional HTTP requests might be of more concern, because of the extra latency you tend to get on mobile connections.

I think under both options in modern browsers, the HTTP requests will be made in parallel (even old browsers would make two HTTP requests at once per domain). Not sure about mobile browsers.

It's difficult to judge how many users are likely to have the library CDN version already cached when they first visit your site. I think I remember reading something that suggested it was fewer users than you might think (possibly some data from Yahoo, where about 25% of users had it cached), but I can't find the reference.

It's worth considering how often you're expecting the various files to change. If you update your own JavaScript every week or two, but keep your libraries and plugins on the same version for months/years, then it might well be worth keeping those files separate so that returning users don't have to re-download one big packed file just because you changed one line of your own JavaScript.

To be honest though, if you're already minifying, gzipping AND serving from CloudFront, then when people do download files from you, they're going to be coming down pretty damn quickly anyway. And after each user's first empty-cache visit to your site, your files will be cached too. Overall I don't think you'll see a big difference between these options.

One definite drawback of 3rd-party CDNs is that you have no power at all to fix them if they go wrong.

Put CSS and JavaScript in files or main HTML?

http://developer.yahoo.com/performance/rules.html#external

Yahoo (even though they have many inline styles and scripts), recommends making them external. I believe google page speed used to (or still does?) do the same as well.

It's really a logical thing to have them separate. There are so many benefits to keeping CSS and JS separate to the HTML. Things like logical code management, caching of those pages, lower page size (would you rather a ~200ms request for a 400kb cached resource, or a 4000ms delay from having to download that data on every page?), SEO options (less crap for google to look through when scripts/styles are external), easier to minify external scripts (online tools etc), can load them synchronously from different servers....

That should be your primary objective in any website. All styles that make up your whole website should be in the one file (or files for each page, then merged and minified when updated), the same for javascript.

In the real world (not doing a project for yourself, doing one for a client or stakeholder that wants results), the only time where it doesn't make sense to load in another javascript resource or another stylesheet (and thus use inline styles/javascript) is if there's some kind of dynamic information that is on a kind of per-user, per-session or per-time-period that can't be accomplished as simply any other way. Example: when my website has a promotion, we dump a script tag with a small JSON object of information. Because we don't minify and merge multiple files, it makes more sense to just include it in the page. Sure there are other ways to do this, but it costs $20 to do that, whereas it could cost > $100 to do it another way.

Perhaps Amazon/Facebook/Google etc use so much inline code is so their servers aren't taxed so much. I'm not too sure on the benchmarking between requesting a 1MB file in one hit or requesting 10 100KB files (presuming 1MB/10 = 100KB for examples' sake), but what would be faster? Potentially the 1MB file, BUT smaller requests can be loaded synchronously, meaning each one of those 10 requests could come from a separate server/domain potentially, thus reducing overall load time.

Further, google homepages for example seem to dump a JSON array of information for the widgets, presumably because it compiles all that information from various sources, minifies it, caches it, then puts in on the page, then the javascript functions build the layout (client side processing power rather than server-side).

Are page speed , yslow tools enough to know about website organization and performance

Perhaps they're not the ULTIMATE tools for determining your site's performance, but they do have a few things that you must consider:

They we made by huge companies: Google and Yahoo spend millions in research. Is a good thing that they develop tools like these to help developers who heed advice.
They do a pretty intense checking: If you are using browser's cache and compressing data and all those small tweaks are just the things that make the difference between a slow site and a fast one.

My opinion (which I think is bottom line of what you want: opinions) is that these tools should be taken very seriusly, because they bring lots of adjustments that you should make to your web applications and these adjustments may mark the difference between a few users and lots of them.

Hope I can help!

What are the benefits of concatenating all Javascript files into one before sending it to client?

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.