Minification v Obfuscation

Blog
About

March 6, 2006 at 7:08 pm by Douglas Crockford | In Development |

JavaScript is a load-and-go language. Programs are delivered to the execution site as text (not as executable or semi-compiled class files) where it is compiled and executed. JavaScript works well with the Web, which is a text delivery system, because it is delivered as text.

There are two downsides of textual delivery of programs. The first is code size. The source can contain material (such as whitespace and comments) which aids in the human interpretability of the program, but which is not needed for its execution. Transmitting superfluous material can significantly delay the download process, which keeps people waiting. If we could first strip out the whitespace and comments, our pages would load faster.

The second downside is code privacy. There might be a concern that someone could read the program and learn our techniques, and worse, compromise our security by learning the secrets that are embedded in the code.

There are two classes of tools which deal with these problems: minifiers and obfuscators.

A minifier removes the comments and unnecessary whitespace from a program. Depending on how the program is written, this can reduce the size by about half. An obfuscator also minifies, but it will also make modifications to the program, changing the names of variables, functions, and members, making the program much harder to understand, and further reducing its size in the bargain. Some obfuscators are quite aggressive in their transformations. Some require special annotations in the source program to indicate what changes might or might not be safe.

Any transformation carries the risk of introducing a bug. Even if the obfuscator didn’t cause the bug, the fact that it might have is a distraction which will slow down the debugging process. The modifications to the program also add significantly to the difficulty of debugging.

After minifying or obfuscating, you should GZIP. GZIP can further reduce the size of the program. GZIP is so effective that the difference in the efficiency between minification and obfuscation becomes insignificant. So I prefer minification with GZIP because I don’t have time for programming tools that can inject bugs into good programs.

	Full Source	Minified
Uncompressed	78151	38051
Compressed with gzip	15207	10799

The table shows the results of using a minifer and gzip on a 78K source file. The result of using the two techniques together produced a result that is only 14% the size of the original source file.

Then finally, there is that question of code privacy. This is a lost cause. There is no transformation that will keep a determined hacker from understanding your program. This turns out to be true for all programs in all languages, it is just more obviously true with JavaScript because it is delivered in source form. The privacy benefit provided by obfuscation is an illusion. If you don’t want people to see your programs, unplug your server.

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

48 Comments »

RSS feed for comments on this post. TrackBack URI

[…] Douglas Crockford […]

Pingback by Painfully Obvious » Blog Archive » Quotation: Douglas Crockford — March 6, 2006 #
Has there been any update on IE6 and its caching ability with PHP’s ob_start()? Nevermind the fact that I’d prefer someone to download something that’s 10k over 80k… just wondering.

Also, is there a difference between mod_zip and g_zip etc.??

Comment by Dustin Diaz — March 6, 2006 #
There’s a good utility called ‘packer’ which compresses and obsfucates (by virtue of compressing) your code:

http://dean.edwards.name/packer/ (Note, site down when I posted this — doh!)

While it’s not hard for someone to reverse engineer his algorithm to decode the javascript, it will deter most people from looking at your source and copying it.

Cheers,
–Bill

Comment by Bill Lynch — March 7, 2006 #
[…] Douglas Crockford has written a piece on Javascript minification and obfuscation over at the Yahoo! User Interface blog. […]

Pingback by Web 3.11 » From the Yahoo! User Interface Blog: Minification v Obfuscation — March 7, 2006 #
How have you dealt with the issue of some browsers not correctly handling gzipping of external js and css files? I prefer the benefits given by externalizing presentation logic - modularization and caching - but can’t fully enjoy it unless the files are inlined into the parent page and THAT page is gzipped. Have you found a way around this?

Comment by Joe Pearson — March 7, 2006 #
Good post.

To extend your comment that code privacy is an illusion ….. if people build really good, usable code with a really good API and really good tutorials then everyone will use the code and help you fix bugs and help you build new features.

I really hope you guys don’t obfuscate anything … it doesn’t sound like you actually said this. :)

Comment by Scott Fitchet — March 7, 2006 #
I don’t understand the gzip comments. Are web browsers able to automatically extract/interpret zip’d javascript source?

Comment by Nathan Rutman — March 7, 2006 #
Crockford on JSMin and Obfuscation…

Douglas Crockford knows a thing or two about compressing JavaScript. He wrote JSMin which IMHO is the simplest and fastest JavaScript minifer out there today. Coupled with his lint checker JSLint you’ve got two really good tools to write good s…

Trackback by Kevin Henrikson — March 7, 2006 #
[…] Douglas Crockford en Yahoo! User Interface Blog[en]. Traducido sería algo como: Si no quieres que la gente vea tus programas, desconecta tu servidor Enlace permanente | Trackback […]

Pingback by Concept&Development » Privacidad en el código javascript — March 7, 2006 #
Well, the snippet of code to produce this compression using gZip looks like this:

<?php ob_start ("ob_gzhandler"); header("Content-type: text/javascript; charset: UTF-8"); header("Cache-Control: must-revalidate"); $offset = 60 * 60 * 24 * 365; // one year $ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT"; header($ExpStr); ?>

that will typically get you what you need, I was just wondering about the caching thing for IE. I don’t know if that’s just a rumor or for real since I don’t know how to check for that.

Comment by Dustin Diaz — March 7, 2006 #
@Bill: In my conversations, many security pros don’t believe in “security by obscurity”.

@Joe: You’re right that not all browsers accept compressed content. Without getting into detail (perhaps we’re write more on this in the future), those that can handle compressed content generally report as such to the server, sometimes with an “accept-encoding: gzip” header.

@Scott: You’re very welcome to join the ydn-javascript community of developers using and contributing to the Yahoo! User Interface Library.

@Kevin: I’m glad you like JSLint, we do too. I also concur that having Douglas around “putting focus back on JavaScript” is definitely a good thing.

Comment by Nate Koechley — March 7, 2006 #
[…] Douglas Crockford has post on the Yahoo! User Interface Blog discussing ways to reduce the size of your Javascript code, Minification v Obfuscation. […]

Pingback by Joseph Scott’s Blog » Blog Archive » Minification vs. Obfuscation — March 7, 2006 #
@Dustin — I see that you picked up on this as well (if you recall I brought up this question on your post “Forget addEvent…”). It would be nice to put this to rest once and for all. I’m using carefully configured mod_gzip on my own server, and the one thing I don’t send compressed is JavaScript.

Comment by Douglas Clifton — March 8, 2006 #
Wrong: ‘minification’ is _not_ good obfuscation!
after many attempts I belive I can say that ‘minification’ is much worse then ‘biggification’ when it comes to obfuscation.
Since it’s impossible to avoid de-obfuscation then the goal is to make it uneasy and annnoying, so to make it not worth for the attacker.
Here we should remember that programmers are accustomed at using short variable names and once they understand what a variable/method does then they can easily use a text editor to replace occurences with a meaningful one.
On the contrary using extremely long (200+ chars) variable names will make code almost impossible to read, simply because programmers can’t easily read the code!

Obviously heavily loaded sites will find it a bit hard to adopt this approach, even when using caches and gziping such files will be way longer then they would once ‘minified’

BTW: we applied this tecnique to java code/bytecode and it resulted to be much more robust to de-obfuscation simply because most decompilers are file based and/or C/C++ based and will not be able to save the files by the original names and/or will break the stack!

Comment by Simone — March 8, 2006 #
I absolutely amused and agree with your quote:

“If you don’t want people to see your programs, unplug your server”

Besides, what harms will “copying javascripts” does to your site? A successful site does not depend on javascripts alone. I think should be rephrased to be “will never”.

Comment by Herryanto Siatono — March 8, 2006 #
[…] Do you post-process your Javascript? Are you an obfuscator, minifier, or gzipper? Douglas Crockford discusses these three forms of post-processing. […]

Pingback by Ajaxian » Obfuscating and Minifying Javscript — March 10, 2006 #
Obsfucation is like a lock on your house door - it is just a mild deterrent.

If somebody really wants to get understand your code, they can de-obsfucate it by hand. Many people will not bother (because of the deterrent).

If somebody really wants to get into your house they will just break a window, or kick your door through.

Now - who here doesn’t have a lock on their door???

Comment by Jamie — March 10, 2006 #
[…] If you want to make your JavaScript smaller and harder to read then Douglas Crockford has the skinny on Minificaction vs Obfuscation. […]

Pingback by Javascript Post-Processing » Web 2.0 Blog — March 10, 2006 #
Dojo’s compressor:

http://dojotoolkit.org/docs/compressor_system.html

uses a full-on Javascript parser to accurately swap in short names, etc.

Comment by Gavin Doughtie — March 10, 2006 #
I have been using the JS Cruncher Pro fo a while.

http://domapi.com/jscruncherpro/

It support a project base minification and obfuscation. It also has nice UI.

Comment by Henry — March 10, 2006 #
Minimizar, comprimir y obfuscar JavaScript…

En este artículo se discute brevemente y se demuestra cómo aliviar el peso de las páginas que contienen JavaScript mediante minimización, obfuscación y compresión (gz). Interesante si tenéis un server apretado o queréis ahorrar algo en ancho de banda….

Trackback by meneame.net — March 12, 2006 #
I have a suggestion for an even better download time optimization. Yahoo is one of the few companies that can reduce the download time of a lib to zero!

Just not release the libs, but also host them and set generous cache parameters.

If I use the lib in my site and someone visit it after having visited other site that also uses it, the lib won’t be download.

As an example, see this Google logo that is put in sites that use their search service: http://www.google.com/logos/Logo_25wht.gif

This image HTTP headers are:Content-Type: image/gif Last-Modified: Mon, 25 Apr 2005 21:10:59 GMT Expires: Sun, 17 Jan 2038 19:14:07 GMT Server: GWS/2.1 Content-Length: 1607 Date: Tue, 14 Mar 2006 15:35:19 GMT Connection: Keep-Alive

See the very hight expiration date. If you access it in any site, it won’t be download anymore (at least, until 2038)

The libs should be avaiable in an URL with the specific version number, so the release of new versions won’t break all the existing sites.

As a global company, Yahoo can do this easily, using negligible resources and improving the user experience for everybody that uses the library.

Note: I’m not really sure if there are cross scripting security issues using this aproach. I haven’t looked at your libs yet.

BTW, thanks for releasing this cool software.

Comment by Paulo Eduardo Neves — March 14, 2006 #
Minification v Obfuscation �…

"Then finally, there is that question of code privacy. This is a lost cause. There is no transformation that will keep a determined hacker from understanding your program. This turns out to be true for all programs in all languages, it is just mor…

Trackback by Tambel Weblogs.or.id — March 17, 2006 #
One thing which is often overlooked by people using obfuscators/crunchers is that they require an unpack-routine to run on script-start. Since the browser can’t cache the unpacked script, this will have to happen everytime the page is loaded (even if the script-source is cached).
In contrast, a large file is only a problem on the first pageload.

Comment by Troels — March 21, 2006 #
Sviluppare Ajax con l’aiuto di Yahoo!…

…

Trackback by FoxyBlog — March 21, 2006 #
[…] Minification v Obfuscation - Yahoo! User Interface Blog […]

Pingback by alexking.org: Blog > Around the web — April 3, 2006 #
[…] This applies to HTML, JavaScript, and CSS equally well. Concerned about someone being able to see your code? Get over it. Minification v Obfuscation » Yahoo! User Interface Blog Then finally, there is that question of code privacy. This is a lost cause. There is no transformation that will keep a determined hacker from understanding your program. This turns out to be true for all programs in all languages, it is just more obviously true with JavaScript because it is delivered in source form. The privacy benefit provided by obfuscation is an illusion. If you don’t want people to see your programs, unplug your server. […]

Pingback by ArtLung Blog : Archives : » Best Web Code Comment Ever — April 9, 2006 #
[…] http://yuiblog.com/blog/2006/03/06/minification-v-obfuscation/ […]

Pingback by Project :: penk i blog » Blog Archive » 本日書籤 — April 11, 2006 #
Maybe I am missing an important ingredient here, but I don’t see how to reference the Javascript stored in a GZipped file.

If anyone has a simple working example, I would appreciate it.

Comment by Adam Zuckerman — April 20, 2006 #
[…] Douglas Crockford has written a piece on Javascript minification and obfuscation over at the Yahoo! User Interface blog. […]

Comment by Pozycjonowanie — October 15, 2006 #
[…] 縮行的單位是四個空白。避免使用Tab字元。就算是在21世紀，Tab字元到底該空多少空白依然沒有一個標準。雖然使用空白字元會增加檔案大小，但在內部網路並不會造成影響。透過最小化(minification)的技巧，還可以再降低使用空白字元的影響。 […]

Pingback by DeepMind Programmer Club » Javascript Code Convetion — December 10, 2006 #
Thanks for this very good article … Can i translate this and insert on my site in Poland? … Thanks

Comment by Aukcje — February 1, 2007 #
[…] GZIP the code, don’t obfuscate: Minification v. Obfuscation […]

Pingback by The Dr0p » Blog Archive » Javascript Coding rules — February 1, 2007 #
Yes, please translate it. And please share the URL when it is ready.

Comment by Douglas Crockford — February 1, 2007 #
The question about GZip was asked three times and totally ignored. Why?
I will repeat the question - Can browsers directly import & unpack as GZip file containing Javascript code? How about a ZIP file?

Comment by Art K — April 30, 2007 #
The question about GZip was not ignored, it was answered above.

To reiterate, and add a bit of detail, HTTP allows for gzipping through both the Content-Encoding and Transfer-Encoding headers. Alas Transfer-Encoding isn’t supported by many browsers, though it’s superior in a few ways I won’t get into.

Content-Encoding is supported by many browsers, including just about all popular ones.

Browsers report their willingness to accept g-zip, so a server can only serve g-zipped files to those browsers that can handle them.

Unfortunately though, recent versions of IE (though I *think* it is fixed with IE7) had a bug whereby they would sometimes incorrectly handle compressed javascript files (though they were fine with compressed HTML) which is a bit of a bother as it required server side browser sniffing or else turning off server-side compression in the case of javascript files.

Comment by Jon — May 27, 2007 #
Maybe I am missing an important ingredient here, but I don’t see how to reference the Javascript stored in a GZipped file.

Comment by Apteka internetowa — June 26, 2007 #
Get over it. Minification v Obfuscation » Yahoo! User Interface Blog Then finally, there is that question of code privacy

Comment by Apteka — June 26, 2007 #
I totally agree with your quote ‘If you don’t want people to see your programs, unplug your server’

Comment by sao — July 6, 2007 #
I have a suggestion for an even better download time optimization. Yahoo is one of the few companies that can reduce the download time of a lib to zero!

Comment by Serg — July 15, 2007 #
I never realised that these tools existed. Thanks for the information. The ability to reduce the size and loading time is fantastic. I shall have to try it out on all our sites.

Comment by Noosa Accommodation — August 8, 2007 #
Julien Lecomte has produced a tool that reduces more effectively than JSMin, and is safer than the other obfuscators. JSMin is still the best option if you have to minify in realtime. Usually you don’t.

Comment by Douglas Crockforrd — August 13, 2007 #
Douglas Crockford knows a thing or two about compressing JavaScript. He wrote JSMin which IMHO is the simplest and fastest JavaScript minifer out there today.

Comment by gry — September 5, 2007 #
Thanks for this very good article … Can i translate this and insert on my site in Poland? … Thanks

Comment by Gry — September 6, 2007 #
Of course. Please share with us the URL of the translated page.

Comment by Douglas Crockford — September 8, 2007 #
Hey
I totally agree with your quote ‘If you don’t want people to see your programs, unplug your server’

Comment by netsearch — September 18, 2007 #
[…] GZIP the code, don’t obfuscate: Minification v. Obfuscation […]

Pingback by neyric’s JS » Blog Archive » Javascript Coding rules — February 6, 2008 #
[…] The unit of indentation is four spaces. Use of tabs should be avoided because (as of this writing in the 21st Century) there still is not a standard for the placement of tabstops. The use of spaces can produce a larger filesize, but the size is not significant over local networks, and the difference is eliminated by minification. […]

Pingback by HelpingGuru » JavaScript Coding Standards — April 24, 2008 #

Yahoo! User Interface Blog