e-testing Blog


By Howard Osborne


In this deep dive, we are going to be looking at what minifying is, then why and when we should do it.

JavaScript has become the de facto client-side language for browsers and this popularity is in large part due to it being an interpreted language.

Compiled Languages
With compiled languages, the programmer writes their code in source files which they can understand but the machine cannot execute them. The source code is compiled into an executable file for each specific system. These files can be very efficient to run, however, an executable file on Linux contains different instructions to one running on Windows.


Interpreted languages
For interpreted languages like Javascript, there is no compilation. Instead, the source code is executed by an interpreter and so different systems have different interpreters.


This makes it very flexible however, unlike its binary counterpart, the file has to perform two functions. It needs to be executable by an interpreter but it also has to be understandable to a human. All those extra comments and spaces which make the file readable are wasted on a computer and add extra bulk to that needs to be downloaded. So is there anything that can be done?

Cue the minifyer
A minifyer will take a source file and strip out all the unnecessary stuff making it ready for download and client-side execution.

So what does minifying do?

Let’s take this file below:

example.js – filesize 393 bytes

/* this is my lovely although not very useful script

   and it can contain lots of comments

   such as this…



//this is a variable I am going to use

var message = “Hello World!”;

var shouldWrite = false;


//here I am testing to see whether the message should be written

if (shouldWrite == true){




                console.log(“OK, I say something else!”);


After this code has been run through a minifyer, it becomes:

Example.min.js – file size 144 bytes

var message=”Hello World!”;var shouldWrite=false;if(shouldWrite==true){console.log(message);}

else{console.log(“OK, I say something else!”);}

Instead of sending a file which is 393 characters, we now send one which is 144 characters. All that needs to be done now is to think about what to do with all that saved space and time.

And the catch is?
There are drawbacks. Whilst the JavaScript language and its interpreters aren’t as easy going as some (try perl), losing spaces can make some scripts behave differently such as in operator precedence. Consequently, it make sense to identify sources of potential ambiguity up front using a tool such as jslint or jshint before you minify. In fact, why not do it anyway?

Also, this is a one way process, unlike compression, you can’t un-minify a file. The minified file is very hard for a human to read and all of those nice comments have gone. Debugging web pages that use minified files can be very painful, so only minify once you are sure the code is working well and just in case it wasn’t clear before, don’t dispose of your original file…

Of course, hard to read but functional JavaScript code can work in your favour as it becomes difficult for others to copy and then modify your work. Consequently, minifying is, for those who want to protect their intellectual property, as much about obfuscation as it is about optimisation.

Cascading stylesheets (CSS) which contain instructions to the browser on how to render particular elements can also be minified and offers the same advantages.

What next?
Well have a go yourself…

Two examples of minifyers by Douglas Crockford and Dean Edwards are found here:



… and as seems to be the case for most tools and technologies, Google has come up with their own great version: http://closure-compiler.appspot.com/home

Have fun!

Ready for Part 2? Read about Compression Here >>


Subscribe to our RSS feed and get the latest updates in your inbox weekly