Quick and dirty test of the YUI Compressor

As a part of our quest trying to optimize the speed of our search front end I recently tried out the Yahoo js and css minifyer – YUI Compressor.

At first glance the nice things about the YUI Compressor are that it is a Java based (we are a Java friendly team), open source and fairly easy to work with. The YUI Compressor handles both javascript and css but in this post I have chosen to focus on the js part.

The test integration into my IDE (Intellij IDEA) and the project was quite easy because somebody has taken the time to write YUIAnt. I just downloaded the YUI compressor version 2.4.2 and the YUIAnt.jar and added them to the project and modified my build scripts to run the compressor when the website is deployed to the web server. The beauty of this is that you naturally don’t have to look at the minified javascript when editing and if you for some reason want to debug the code run time you can easily setup a debug option in your build script and bypass the compressor for on the fly debugging. If you aren’t into all this build script stuff or have a simple project there are lots of online YUI Compressor sites out there where you can paste you js code or css and get a compressed version in return.

The version 2.4.2 of the YUI Compressor nearly worked without problems. For some reason – I didn’t bother to investigate further – the YUI Compressor had some issues with unterminated Strings in the jscalendar-1.0 library. I just excluded the directory and went on with my small non scientific test using Firebug as my test environment.

The first screen shot shows the size and load times for our js files. Business as usual – the YUI Compressor is disabled.

nocompress2Scaled

The next screen shot shows the size and load times for the same js files now with the compression enabled.

compress2Scaled

The file sizes have been reduced and the overall load time has shrunk approximately half a second. When the file sizes are very small the load times are very sensitive to queing effects but the file size is in most cases reduced. In the case of bigger js files the improvement in speed as well as size is clear. I have tried to compensate for caching effects in both cases (compress/not compressed). It seems that there is about a 20-25% reduction in file size and approximately the same reduction in load time for the js. These numbers are without using the obfuscation option (reduction of variable names to the shortest possible length and other tricks) simply because I don’t thing we will be comfortable with this knowing that it might cause errors.

As I am new to this I am interested to hear about any major drawbacks compressing/minifying may have.

This is of course a small step and not something which alone makes the difference between a slow and a fast site but I am hoping that attention to a number of different optimization issues will make a big difference in the long run.

This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.

4 Responses to Quick and dirty test of the YUI Compressor

  1. jrochkind says:

    That should really only effect load times the FIRST time a user visits your site, because after that their browser should have the JS cached—true? I’d be interested to learn if my assumption there is incorrect, or if you’ve tested it yourself too, first load vs. subsequent loads.

    The only downside I see is some additional complication in debugging, and the possibiilty that the compressor may introduce bugs (although I’d assume that’s a pretty small risk). But just generally having another layer to deal with and debug. If you aren’t writing your own JS but only using third party JS libraries that are reasonably mature and tested, perhaps this is less of an issue.

    But personally, based on my assumption that it only would effect the first un-cached page view (not that that’s not important too, it is, but balanced overall…) vs having another layer in my environment to effect debugging and stuff, I’ve never pursued that compression stuff.

  2. Jørn Thøgersen says:

    Yes the load times should only be effected the first time before the cache kicks in. Actually I just tried it out and the load times the second time around are nearly the same with the minified and normal version. The minified version is a tiny bit faster but probably nothing that would be noticed by the user and not near the half a second that was shaved off the first time you load the page with the minified version.

    We do have a lot of home grown JS and rely on Prototype (we are in the process of switching to JQuery) for the rest. I agree that there is a small risk for errors and actually I have had a lot of compressor errors with the jscalendar-1.0 library. As long as obfuscation is not used I still think that this is a small issue as it is easy to disable/enable the compressor and/or exclude certain problematic files.

    It’s a good point that the extra layer of complexity vs the ‘one time only effect’ may turn out to be not worth the hassle. We haven’t concluded anything yet but are in midst of trying different things out and seeing what will yield the most benefit compared to the implementation effort needed.

    Thanks for your comment!

  3. kamstrup says:

    I am wondering whether it would make sense to roll up all linked .js and .css files into big catenated files? And maybe also do js-mangling on these files.

    It would be an attempt to minimize the number of network roundtrips the browser has to do to load the page. I just checked that Firefox 3.5 (at least) does not have HTTP pipelining enabled by default, which means the browser must do a HTTP GET for each linked file.

    Anyways – just a thought.

  4. Jørn Thøgersen says:

    I think it should make a difference as we have many .js files for the sake of overview as we are several developers working on the same rather large project. So one big file in our case should minimize network overhead. The question is how effective this trade off between number of files and ‘large file download’ is.

    For now I am buried in other work as I have just returned from holiday but it is worth a quick and dirty try when I catch up with my pending tasks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s