Javascript – Why is HTML/Javascript minification beneficial

htmlhttpjavascriptminify

Why is HTML/Javascript minification beneficial when the HTTP protocol already supports gzip data compression?

I realize that Javascript/HTML minification has the potential to significantly reduce the size of Javascript/HTML files by removing unnecessary whitespace, and perhaps renaming variables to a few letters each, but doesn't the LZW algorithm do especially well when there are many repeated characters (e.g. lots of whitespace?)

I realize that some Javascript minification tools do more than just reduce size. Google's closure compiler, for example, also tries to improve code performance by inlining functions and doing other analyses. But the primary purpose of Javascript minification is usually to reduce file size.

I also realize there are other reasons you might want to minify aside from performace, such as code obfuscation. But again, that reason is not usually emphasized as much as performance gain and file size reduction. For example, Closure Compiler is not advertised as an obfuscation tool, but as a code size reducer and download-speed enhancer.

So, how much performance do you really gain from Javascript/HTML minification when you're already significantly reducing file size with gzip compression?

Best Answer

Because gzip compression does have its own overhead (CPU). Minification is the first "low hanging" compression that can be applied without the CPU hit.

These may seem insignificant however, the numbers soon make sense when scale is involved.

Further, with minification you have less to gzip.

Related Solutions

Javascript – PHP, HTML, Javascript and writing good practices

Some general rules I follow:

General

Indents are 4 spaces.
Indent new levels
Comments are < ~80 chars from the indent level. If I'm in two levels (8 spaces) that means the cursor stop will be around 88 characters.
Use multi-line comments. I prefer the look, however this is a subjective point.
Comment now rather then later when you have no idea what's going on.
Allman style braces. It's cleaner and is more readable. Subjective.

JavaScript

Use a library. jQuery in particular is very good. It eliminates all cross browser headaches.
Understand that ID's are for particular elements, classes are for styles. ID's shouldn't be used more then once per page and they will have particular hooks attached to them. Use classes for things like navigation.
Out source into methods. It's tempting to put all the code into the bind call, however putting it in it's own function will increase the flexibility of your code.
Use functions instead of evals. That means setTimeout(function(){ /* Do something */ }, 1000); instead of setTimeout('doSomething', 1000);
Use local variables with var.

HTML

Semantic markup. Use appropriate tags. Don't put <br />'s in there to add space, adjust margins and CSS rules.
All tags are lowercase.
All tags should end with a closing tag or be self closing.
Make use of classes for layout that is similar. Have a couple of predefined classes like hide, clear, error, etc.
Everything (scripts included) should go in <head>. Worry about optimizing (moving stuff around) when it presents a problem.
External stylesheets and JavaScript source is a must unless it is page specific.

PHP

Frameworks are good, I recommend CodeIgniter.
If you don't want to use a framework, try to use the latest version of PHP possible. (That means 5.3).
Use includes to your advantage.
Clear injections or use prepared statements.

Perform if checks on preconceived fail-secure values.

$logged_in = false;
if(check_user($user))
{
     $logged_in = true;
     $user = load_user($_SESSION);
}

Know the difference between single and double quotes. Use single quotes when possible.
Don't echo HTML.

JavaScript and HTML – When Should JavaScript Generate HTML?

Whenever I have encountered heavy HTML generation in javascript, it was almost solely in a stand-alone UI plugin. It makes sense, as it allows to encapsulate the entire plugin in a single .js file (+ a .css to customize styles), thus making it easily reusable, distribuable, and independent from the framework used in the application.

So if you're writing a stand-alone javascript plugin or a generic UI component which you would like to use across different applications, such an approach has its upsides. Otherwise, I think it's both cleaner, easier to write and easier to maintain when you keep html generation away from javascript and on the server side.

Related Topic