Is UglifyJS Really Worth It?
Like the rest of the world, RightScale has been moving more and more of its application from the server to the client. That means we’ve suddenly found managing larger and larger piles of JavaScript. All that JavaScript needs to be delivered to clients as quickly as possible in order to minimize the time customers spend waiting for web pages to load.
So we created a nice little build tool leveraging Grunt which among other things takes all that JavaScript and compiles it into one big blob for each application. In order to make that big blob as small as possible, we use UglifyJS.
Unfortunately, some of our apps are so big that running the uglify Grunt task can take a long time. Ideally, this task would be fast enough to where it could be run at or just before deploying. Fast enough is a pretty subjective term, but we deploy code all the time to production and various kinds of staging systems, so fast enough becomes however long you want to wait for code deploys in addition to the time it already takes. In my case, three extra minutes is not fast enough.
So I theorized about the virtue of using UglifyJS at all and my reasoning went something like this: Any sane person who’s delivering a lot of JavaScript to clients on the web is going to be using some kind of HTTP compression algorithm like gzip or deflate. And hardcore file size optimizations prior to compression seem like exactly the kind of things that would make regular file compression less efficient. So wouldn’t we be better off with something fast and simple like Douglas Crockford’s good old JSMin? We could just rely more on the file compression than mifification or uglification to reduce file size.