Web Performance – Pros and Cons of Including JS/CSS Inside HTML

I worked on a project which were very close to your situation. The requirements were the following:

1. On development side, each page can have one or several JavaScript files and one or several CSS files. All those files are local.
2. In production, there must be one and one only JavaScript file and one and one only CSS file. Those two files are hosted on a distant server, optimized for static files and configured for client and server side caching.
3. Each page has a link to JQuery hosted at Google CDN in both development and production environments.
4. The deployment process must be automated.
5. The deployment process must not modify files other than JavaScript and CSS files for compression.
6. The website is written in ASP.NET.
7. Every page of the website uses the same CSS and the same JavaScript.
8. On development side, CSS and JavaScript files are always in a specific predefined directory.

Here what was done by my colleague who worked on this part of the project.

1. All files except JQuery are minified and combined into two files: g.css and g.js, g for global. This is simply done by walking though the specific directory and searching for those files. After minifying them, the two files are send to the static content server, if they were changed since the last deployment.
2. The process is executed at every build, since we couldn't find how to execute it at deployment only. It doesn't matter, after all, since it takes a few milliseconds to walk through all files and check if they were modified since the last build.
3. The website is deployed as is, except the original JavaScript and CSS files. We don't need them in production.
4. The masterpage (in ASP.NET) contains a specific method which is adjusting the calls to the JavaScript and CSS files depending of the context.

This method is like this:

public string MakeCssCalls(IList<string> cssFiles)
{
    // ...
}

In development environment, it returned the links to CSS files inside the cssFiles argument. In production, it ignored this argument and just returned "<link rel="stylesheet" href="http://static.example.com/g.css" type="text/css" />". It made the difference between production and development by comparing the machine name to the list of names in Web.config file: some machines were configured as being development machines; all machines outside this list were assumed production servers.

Performance-wise, it would be smarter to have a different Web.config file for production, indicating that we are actually in production (and, for example, precising the exact link to the static server with those files; in our case it was hardcoded, and that sucks). We couldn't do it this way because one of the requirements of this project was to have a single Web.config file for all environments, but if you can, do it.

Also when is the testing generally performed? I think it should be performed on the optimized files (just in case the compressors have some bug).

We tested the website on non-minified versions of files. We never had any bug coming from Google Closure (nor our home-made crappy CSS minifier).

One tool that appears to do part of what you need, at least for Java webapps, is Web Resource Optimizer for Java (wro4j).

Free and Open Source Java project which brings together almost all the modern web tools: JsHint, CssLint, JsMin, Google Closure compressor, YUI Compressor, UglifyJs, Dojo Shrinksafe, Css Variables Support, JSON Compression, Less, Sass, CoffeeScript and much more. In the same time, the aim is to keep it as simple as possible and as extensible as possible in order to be easily adapted to application specific needs.

Easily improve your web application loading time. Keep project web resources (js & css) well organized, merge & minify them at run-time (using a simple filter) or build-time (using maven plugin) and has a dozen of features you may find useful when dealing with web resources.

You might also check into RequireJS to see if that would help you define which js files the client should download in a particular environment.

RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used in other JavaScript environments, like Rhino and Node. Using a modular script loader like RequireJS will improve the speed and quality of your code.