debugger;

While this all just seems like common sense to me, it apparantly isn’t to some people / development teams. As I said before, I’ve been stumbling onto more and more sites lately that exhibit JavaScript programming practices that seem a little off at best. Some sites just seem to slap together frameworks without thinking about the repercussions and just call it a day. Yeah, for the most part it doesn’t matter in the short run, but in the long run, poor programming can drive up IT costs in the form of additional hardware and bandwidth as well as drive away your website visitors due to frustration with loading times

Other individuals / companies have certainly written about this before, but I haven’t seen anything on it in a while now and I figured it’d be nice to have a refresher. Without further ado, following are some practices that we follow at Diverse Solutions that, as a website visitor, I wish more companies would follow.

1. Shrink Your Code: This really seems like common sense to me, but far too many people aren’t even aware of the tools available to help developers in this area or just don’t care enough about the benefits. JS compressors, in case you’re not aware, do anything from strip unnecessary whitespace and comments to actually changing the names of private variables to smaller names to save space. We use Dojo ShrinkSafe, but I’ve heard JSMin does a pretty good job too, and I know that there are a number of others that will probably fit the bill as well. They are pretty easy to use if you take the time to set them up, and the benefits are definitely worth it. In most of our apps, we’ve created batch files that run ShrinkSafe on most JS files in the deploy directory so that we don’t have to really mess with it after we’ve set it up.
2. Compress Your Code: Use server-side compression if the client truly supports decompression. GZIP can be your friend, but it can also be your enemy if the client doesn’t support it properly but says it does (looking at you, IE6). Some claim it’s not that big of a deal and that the problem isn’t very widespread, but we’ve had our fair share of clients who had problems with us compressing JavaScript. The problem is primarily related to this bug, but there are other things that can cause problems with compressed content as well. Basically, we’ve found that you’re best bet is just to conditionally serve compressed JS to browsers that say they support it except for anything below IE6 SP2. You can do this with server-side code if you intercept your requests to JS files. We run IIS 6 and use ZipEnable so that we don’t have to write anything extra to take care of this.
3. Don’t Include Libraries You Don’t Use: This, again, seems like common sense. I’ve happened upon way too many sites that include Prototype or Dojo or something just because they likely think that they are going to use it, but they never end up using a single part of it. My advice is to only include the library after you’ve learned how to use it, not before.
4. Use Versioning: This is something we fairly recently started doing, and we don’t know why we never did it before. Versioning is especially important because of this bug in IE6. Basically, versioning involves appending a querystring to the end of every script’s tag src attribute. The querystring doesn’t / shouldn’t change the file being requested, but because you can change the querystring when you deploy, the browser will re-request the file with the next request and get the new version of your script. It can definitely be a pain to manually manage changing the querystring at the end of all of your JS files, so we have the value of the querystring variable set as a server side variable that we can just change in one place to make everyone’s browser reload everything. Sure it reloads some files unnecessarily, but like everything else regarding JS optimization, it’s a balance between extra work and better practices.
5. Minimize Client Requests: Yahoo! pre-compiles some of their YUI libraries so that developers can just include one or two files in their apps and get the functionality they need, and we do the same thing with most of our libraries / applications. Separating thousands of lines of JS into separate files can really help with organizational purposes, but serving those multiple files to the client can really be a drag to visitors, especially in light in of studies like these. What we’ve done to help fix this is create a quick server-side app that reads an XML config file to determine which JS files to include in the single request. We can then ask for something like /CompressedScripts/Prototype.js to get our Prototype.js file, the Event.onDOMReady file, Justin Palmer’s awesome EventSelectors extension, something we wrote for generating SOAP requests, and Sylvain Zimmer’s impressive $$ addon. That’s five potential requests that we’ve merged into one request, saving an incredible amount of unnecessary requests over the lifetime of our app. I should note that we don’t use versioning (point 4) on our libraries just because it would probably degrade performance most of the time since the libraries rarely change.

Anyway, that should get you started. Of course you can do even further, but like I said, it’s definitely a balance between extra work on your end and unnecessary bandwidth / slow-ish performance on the client end.