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?

4 Answers 4


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.

  • 3
    Will modern web servers actually gzip the javascript files for every request? It seems likely that a server will cache static gzipped content, since it is unlikely to change.
    – aaberg
    Jun 29, 2012 at 11:27
  • @aaberg Even so, that's more cached data on the server. (not that caching isn't good)
    – chills42
    Jun 29, 2012 at 13:38
  • @chilis42: The servers are able to serve pre-gzipped file from the filesystem itself, if that's the problem.
    – herby
    Jun 29, 2012 at 15:45
  • +1 for scale. If you have 10 users and 100 hits a day its irrelavent. If you need to server 100k hits an hour it is a substantial savings. Jun 29, 2012 at 17:22
  • 2
    Something tells me that running full scale JavaScript compiler and several optimizing runs on internal representation, all of it often implemented in Java is not a low CPU overhead. Jul 2, 2012 at 10:24

Minification + gzip generally gives better results, because gzip is a general algorithm, not specifically adapted to one input or another, while minificator is aware about it's content and can do work that general compression algorithm can't. It can afford to be lossy as well (think: completely eliminate comments and whitespaces - that's 100% compression for this data, how you can beat that?), while general compression can't.


You may not get too much performance benefit but you will still reduce your bandwidth usage. If you can shave a few kb off your js (and css) files through minification (and use of css sprites to reduce number of requests) and you are serving 1000's of users a day, after a month you will significantly reduce your bandwidth.

  • 1
    +1: Minification is about savings in aggregate. It might help an individual request be faster, but the point of it is to decrease bandwidth usage over time. Jun 29, 2012 at 15:00

The single most expensive thing you do in a web application is send things down the wire. Sending less stuff down the wire is almost always a net win if you are paying in CPU cycles.

In addition, I don't have anything scientific to back this, but I'd expect that minification tools can probably compress javascript better than gzip if for no other reason than minification tools are domain specific and can be tuned to better compress javascript whereas gzip is a generic tool and will compromise into the middle.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.