YUI Compressor vs Google Closure Compiler for Javascript Compression

November 24th, 2009 by pyrat

Introduction

In todays environment of Rich Internet Applications we rely heavily on Javascript. Often this javascript is in the form of a javascript framework. These typically enhance vanilla javascript and allow you to accomplish tasks with a nice syntax and more importantly abstract the differences in browser implementation.

Despite all the positives the main negative of javascript frameworks is the browser overhead when they are downloaded. Often the size of these assets can add up to a few hundred kilobytes. Coupled with the fact that they are normally split into a number of files (increases HTTP Overhead) this has the effect of decreasing the quality of the user experience while they wait for these files to load when loading your site.

There are a number of ways to increase client side performance specifically with javascript assets.

Decrease HTTP Overhead

Combining assets into single files is the best bet here. Prototype and Scriptaculous take up five or so separate uncompressed files. Decreasing HTTP overhead is one of the biggest time savers.

Caching

This involves telling browsers that they can cache a file for a time in the future. This is known as the expires header. Mod_expires is a way to achieve this with Apache. It is common to append a timestamp to the url eg.

/javascripts/defaults.js?343423434342

A technique which is applied by rails is that this number value is infact the last modified timestamp from the file so you can then set a long expires on this (maximum possible) as changing the default.js file will alter the file, change the timestamp and generate a new unique URL which can be recached.

Gzip Compression

Another big timesaver for big assets. This actually zips up the asset before pumping it down the pipe. You can configure this in your nginx configuration or use mod_deflate if you are on apache.

Javascript Compression and Optimisation

This area still developing, the main players at the moment at the YUI Compressor developed by Yahoo and the Closure Compiler developed by Google.

I use a basic prototype / scriptaculous framework for oentries so have used this for a little battle between the compressors.

Compilation commands are as follows for reference.

YUI

  java -jar /path/to/yuicompressor-2.4.2.jar --type js -o defaults.yui.js defaults.js

Closure (Standard mode)

  java -jar /path/to/compiler.jar  --js defaults.js --js_output_file defaults.google.js

Closure (Advanced Optimizations Mode)

  java -jar /path/to/compiler.jar --compilation_level ADVANCED_OPTIMIZATIONS --js defaults.js --js_output_file defaults.google-advanced.js

NOTE: You need to be running Java 6 to use the closure compiler.

This experiment was performed on a 1Gb Ubuntu Hardy Heron VPS Slice.

Comparison of Compression
Comparison of Compression (Kb)

YUI and Google Closure standard mode produce a similar result circa 60% of the original size. However closure with advanced optimisations leads the way at 43% of the original size!

There is however a BUT. The advanced optimisations mode actually removed methods which are not called! Have a look at these docs

In a standard RIA you will often call functions from inline HTML (onclick events) etc. This makes this form of aggressive optimisation too much for standard applications. You could however remove all javascript calls from HTML and so it all unobtrusively as it standard practice in JQuery.

Compression time
Comparison of Compression Time (Seconds)

YUI is substantially faster than google closure at JS compression. If you were to add this into your deployment strategy this gives YUI the advantage.

Compressor Conclusion

Whilst it looks like closure is a better compressor, I just don’t think it is safe to be this aggressive with compression for production environments.

If you then run closure on standard mode, the differences in compression vs YUI are minimal. With the speed advantage of YUI, I would definitely pick YUI. YUI has the other big advantage in that it can compress CSS as well.

Has anyone had any experience with Javascript Compressors? Comment if you do.

Conclusion

I hope this has given an insight into the wonderful world of speeding up the delivery of your javascript assets. Now get out there and compress!

2 Responses to “YUI Compressor vs Google Closure Compiler for Javascript Compression”

  1. Grincho Says:

    Hi!

    Recently I’ve met with both, YUI and Google closure (GC). I tested them on large project, with many complex js files. YUI was faster than GC, but compressed files were bigger than with GC. You allready know that. I’m trying to perform advance compression with GC, but I somehow can’t. The problem is in complexed prototype functions in js. My ant script makes one big js file, with all js code, and then compression is performed on this file. GC says that prototype functions are not defined. They should be treated as defined, because they are all in same file.. I think :) Did you have any similar problems? Personally I prefer using YUI.

    Greetings, Grincho

  2. Juan Mendes Says:

    Hi, I wanted to point out something about the google closure compiler/minifier that wasn’t mentioned. The compiler allows you to do type checking in js if you add type information for your methods, parameters and local variables through documentation. See http://code.google.com/closure/compiler/docs/js-for-compiler.html

    That really helps maintain my js files. I can be certain that there are no typos in property names, no methods being called with the wrong number of parameters or types. While at the same time still allowing the freedom of a dynamic language in places I deem necessary.

    If you can afford to start a new project, and follow the rules specified by the compiler, your javascript code will be much more solid. As for the deleted methods you mentioned, you can mark a method as @extern which will make sure that the method is exported even if not used

Leave a Reply