views:

505

answers:

4

We’re coming to a big release in a web project I work on, and I’m starting to think more and more about javascript/css performance and versioning. I’ve got a couple high level ideas so far:

  1. Write (or customize) an http handler to do this for me. This would obviously have to handle caching as well to justify the on the fly IO that would occur.
  2. Add these steps into a custom msbuild script that would be ran for deployment only.

I’m also looking at automatically generating config files for each of the servers I deploy to, which lends itself to the second idea. The major advantage I see with the first idea is that I could dynamically handle versioning (at least that’s what one of my links at the bottom says, I’ve yet to convince myself that this would actually work).

Anyway, I’m curious if any of these problems have already been solved. I’d love any feedback. Thanks!

Here are some resources that I've been looking at so far:

http://madskristensen.net/post/Combine-multiple-stylesheets-at-runtime.aspx http://madskristensen.net/post/Remove-whitespace-from-stylesheets-and-JavaScript-files.aspx http://www.west-wind.com/WebLog/posts/413878.aspx http://svn.offwhite.net/trac/SmallSharpTools.Packer/wiki

A: 

In addition for 1), Microsoft has built in support for embedding resource files into DLL. This will always get updated when your project is changed and recompiled.

The problem is, you don't have control over caching and file name. When debugging, it's hard to pick which one to debug when everything is called "webresource.axd" something. That was hell.

Would love to read how others do it, too.

Adrian Godong
A: 

Personally, I rather have it done as part of the build process as to avoid the performance cost of dynamically doing this on each request. I guess you can lessen the hit by implementing proper caching, but why bother... IIS can handle that for you already (unless you are not running on top of IIS, I guess).

As a general recommendation, things that Steven Souders talk about is also great if you want to speed up browser rendering. If you have not already, take a look at this.

Jimmy Chandra
A: 

My team recently moved away from keeping scripts as embedded resources and we are very happy with the results. Yes, you can combine and minify them using handlers, but it's a bit of a hassle, especially when you want to host them from a separate domain.

What we do now is we keep all of our control script files separated and then use a tool, like js-builder, during the build process to combine and minify them. We actually output two files from the tool, one simply combined for debugging, and the combined and minified one for production use.

Michael Morton
Thanks for your comment.After another hours worth of research, this is what I'm leaning toward. As a bonus, I think I may integrate JSLint (errors only) into our build process.Just curious - do you handle configuration in the same manner? I'm between using the wdproj 'web config replacements' (simple) and writing/finding a tool to do it inside our build process (more configurable).
Joe Behymer
+1  A: 

You do this as part of the continuous integration build process you have.

Compare all JS to the previous checked inversion, for each that have changes, call out to the YUI Compressor on that JS file and name the output with the current revision number. Add that file to your repository, and change a config file to have the latest revision number for that js file. Then you will write a custom control that imports a js file. This control will either use the uncompressed js when running on a development machine, or the compressed file with the revision number from the config file when it is run on a deployed setup.

dlamblin