Minification and compression are not the same thing (use both)

Both make your files smaller, at different points in the process, using completely different mechanisms. Understanding which does what explains a result that surprises people: minifying a file that is already being gzipped saves far less than the file-size difference suggests.

Minification: rewriting the source

Minification transforms your code into equivalent code that is shorter. It happens once, at build time, and produces a real file.

For JavaScript that means removing comments and whitespace, shortening local variable names (userAccountBalance becomes a), dropping optional semicolons and braces, folding constant expressions, and — with a modern tool — removing code nothing reaches. That last part, tree shaking, is where the significant savings are on a real application.

For CSS it means collapsing whitespace, shortening colours (#ffffff to #fff), merging duplicate rules and removing the last semicolon in a block.

For HTML it is mostly whitespace and comments, and it needs more care than the other two: whitespace is significant between inline elements, and an over-eager minifier will join two words that were meant to have a space between them.

Typical savings: 30–60% for JavaScript, 20–30% for CSS, 10–20% for HTML.

Compression: squeezing the transfer

HTTP compression happens at the server, per request, on whatever bytes you are sending. The browser advertises what it supports in Accept-Encoding, the server compresses, the browser decompresses. Your file on disk is unchanged.

gzip has been universal for twenty-five years. Brotli is newer, supported by every current browser, and typically 15–20% better than gzip on text. Both are lossless.

They work by finding repetition and replacing repeated sequences with references to earlier occurrences. Source code is extraordinarily repetitive — the same keywords, the same identifiers, the same indentation patterns, over and over — so it compresses exceptionally well.

Typical savings: 70–90% on text. Substantially more than minification.

Why they overlap more than you would expect

Here is the part worth internalising. Take a 100 KB JavaScript file:

• Original: 100 KB
• Minified: 45 KB — a 55% saving, and it looks dramatic
• Original + gzip: 25 KB
• Minified + gzip: 18 KB

Minification cut 55 KB from the raw file but only 7 KB from what actually crosses the network. The reason is that gzip was already handling most of what minification removes: whitespace and repeated identifiers are exactly the redundancy a compressor eliminates. Deleting them first means there is less repetition left for gzip to exploit.

So minification is still worth doing — 18 KB against 25 KB is a real 28% saving — but it is a refinement on top of compression, not the main event. If you are choosing where to spend an afternoon and compression is not enabled, enable compression.

What compression cannot help with

Files that are already compressed. JPG, PNG, WebP, MP4, MP3, ZIP, PDF, WOFF2 fonts — all of these have had their redundancy removed already. Gzipping them saves a fraction of a per cent and costs CPU on every request.

Configure compression for text types only: HTML, CSS, JavaScript, JSON, XML, SVG, plain text. Most default server configurations get this right; hand-written ones often gzip everything.

The thing minification does that compression cannot

Compression only affects transfer. Once the file arrives, the browser decompresses it and parses the original size.

Minification reduces what has to be parsed and executed. On a mid-range phone, parsing and compiling JavaScript is frequently a larger cost than downloading it — and it is CPU-bound, so a fast connection does not help. A file with tree-shaken dead code removed is genuinely less work for the device, in a way that gzip cannot replicate.

This is why bundle size targets are quoted in minified size, not compressed size, when the concern is execution rather than network.

A practical setup

1. Enable Brotli, with gzip as a fallback, for text content types. Highest impact, usually a few lines of server or CDN configuration.
2. Minify at build time. Every bundler does this by default in production mode. Ship source maps so debugging still works.
3. Pre-compress static assets. Generating .br and .gz files at build time lets the server use maximum compression settings, since the cost is paid once rather than per request. Dynamic responses compress at a lower level for latency reasons.
4. Set long cache headers on hashed filenames. The fastest asset is one that is not requested at all. A content hash in the filename makes a one-year cache lifetime safe.

Our JavaScript, CSS and HTML minifiers run in the browser, which is useful for one-off files, a snippet you are about to inline, or checking what a minifier does to something before wiring it into a build.

When not to minify

Never minify in development. Debugging minified code without source maps is miserable and completely avoidable.

Be careful with HTML that contains <pre> or <textarea>. Whitespace is content there, and a minifier that collapses it changes what the user sees.

Watch for code that depends on function names. Anything using Function.prototype.name, or a dependency-injection system that reads parameter names — older Angular being the notorious example — breaks when a minifier renames things. Modern tools have flags to preserve names; the failure mode is a runtime error in production only, so it is worth knowing about before it happens.