Minification v Obfuscation
By Douglas CrockfordMarch 6th, 2006
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.
March 6, 2006 at 7:42 pm
[...] Douglas Crockford [...]
March 6, 2006 at 8:25 pm
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.??
March 7, 2006 at 1:45 am
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
March 7, 2006 at 3:08 am
[...] Douglas Crockford has written a piece on Javascript minification and obfuscation over at the Yahoo! User Interface blog. [...]
March 7, 2006 at 5:54 am
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?
March 7, 2006 at 6:05 am
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. :)
March 7, 2006 at 6:15 am
I don’t understand the gzip comments. Are web browsers able to automatically extract/interpret zip’d javascript source?
March 7, 2006 at 8:44 am
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…
March 7, 2006 at 10:28 am
[...] 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 [...]
March 7, 2006 at 10:32 am
Well, the snippet of code to produce this compression using gZip looks like this:
<?phpob_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.
March 7, 2006 at 10:48 am
@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.
March 7, 2006 at 1:02 pm
[...] Douglas Crockford has post on the Yahoo! User Interface Blog discussing ways to reduce the size of your Javascript code, Minification v Obfuscation. [...]
March 8, 2006 at 12:08 am
@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.
March 8, 2006 at 4:04 am
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!
March 8, 2006 at 8:06 am
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”.
March 10, 2006 at 4:18 am
[...] Do you post-process your Javascript? Are you an obfuscator, minifier, or gzipper? Douglas Crockford discusses these three forms of post-processing. [...]
March 10, 2006 at 5:37 am
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???
March 10, 2006 at 6:27 am
[...] If you want to make your JavaScript smaller and harder to read then Douglas Crockford has the skinny on Minificaction vs Obfuscation. [...]
March 10, 2006 at 7:00 am
Dojo’s compressor:
http://dojotoolkit.org/docs/compressor_system.html
uses a full-on Javascript parser to accurately swap in short names, etc.
March 10, 2006 at 12:25 pm
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.
March 12, 2006 at 7:57 am
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….
March 14, 2006 at 9:28 am
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.
March 17, 2006 at 3:40 am
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…
March 21, 2006 at 9:35 am
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.
March 21, 2006 at 10:06 am
Sviluppare Ajax con l’aiuto di Yahoo!…
…
April 3, 2006 at 9:58 am
[...] Minification v Obfuscation – Yahoo! User Interface Blog [...]
April 9, 2006 at 3:19 pm
[...] 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. [...]
April 11, 2006 at 6:58 am
[...] http://yuiblog.com/blog/2006/03/06/minification-v-obfuscation/ [...]
April 20, 2006 at 10:57 am
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.
October 15, 2006 at 2:58 am
[…] Douglas Crockford has written a piece on Javascript minification and obfuscation over at the Yahoo! User Interface blog. […]
December 10, 2006 at 1:20 am
[...] 縮行的單位是四個空白。避免使用Tab字元。就算是在21世紀，Tab字元到底該空多少空白依然沒有一個標準。雖然使用空白字元會增加檔案大小，但在內部網路並不會造成影響。透過最小化(minification)的技巧，還可以再降低使用空白字元的影響。 [...]
February 1, 2007 at 5:05 am
Thanks for this very good article … Can i translate this and insert on my site in Poland? … Thanks
February 1, 2007 at 5:24 am
[...] GZIP the code, don’t obfuscate: Minification v. Obfuscation [...]
February 1, 2007 at 8:35 am
Yes, please translate it. And please share the URL when it is ready.
April 30, 2007 at 5:26 am
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?
May 27, 2007 at 4:44 pm
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.
June 26, 2007 at 2:10 pm
Maybe I am missing an important ingredient here, but I don’t see how to reference the Javascript stored in a GZipped file.
June 26, 2007 at 2:12 pm
Get over it. Minification v Obfuscation » Yahoo! User Interface Blog Then finally, there is that question of code privacy
July 6, 2007 at 1:24 pm
I totally agree with your quote ‘If you don’t want people to see your programs, unplug your server’
July 15, 2007 at 4:01 am
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!
August 8, 2007 at 4:00 am
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.
August 13, 2007 at 3:43 pm
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.
September 5, 2007 at 5:05 pm
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.
September 6, 2007 at 9:50 am
Thanks for this very good article … Can i translate this and insert on my site in Poland? … Thanks
September 8, 2007 at 10:29 am
Of course. Please share with us the URL of the translated page.
September 18, 2007 at 5:43 am
Hey
I totally agree with your quote ‘If you don’t want people to see your programs, unplug your server’
February 6, 2008 at 10:01 am
[...] GZIP the code, don’t obfuscate: Minification v. Obfuscation [...]
April 24, 2008 at 11:22 pm
[...] 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. [...]
July 9, 2008 at 3:24 pm
#
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 #
I think much of the confusion regarding the idea of GZipping JavaScript is that people may be actually trying to zip or gzip the file using a file compression utility like tar, winzip, etc. This is not what we mean when we say we will gzip the JavaScript.
When you see people refer to the concept of GZipping JavaScript, they are referring to an Apache module called mod_deflate or mod_gzip (I think it’s called mod_gzip). There may be other modules for other servers. There is one for Java applications that will work with Jetty or Tomcat.
You don’t actually zip your JavaScript, you serve it as you normally would in a script tag with a *.js extension, but the Apache server will compress, gzip, or deflate the JavaScript on the fly and serve it to the browser. The response will include a “content-encoding: gzip,deflate” entry in the headers, which will tell the browser to uncompress it.
The files will only be gzipped by the server if the browser includes “accept-encoding: gzip, deflate” in the headers. You can see what request and response headers are being sent using Firebug.
I hope this helps eliminate the years of misunderstandings that I’ve seen in this thread.
Please let me know if you found this information helpful.
Thanks,
James Mortensen
September 20, 2008 at 3:36 pm
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