Ivan Kovalenko

My first question on any minification claim is whether it survived a round trip. A file that got smaller and no longer parses is a regression wearing a saving as a disguise, so I run the output before I measure it. What a minifier does is narrower than people assume. It removes whitespace and comments, folds constants, drops unreachable code and renames local variables. Property and function names are usually left alone unless the tool has proof they are private, which is why a JavaScript bundle keeps its exported names. Compression is the part that changes the arithmetic. Gzip and Brotli operate on repeated byte sequences, and a minified file with mangled names already removed much of the redundancy a compressor was going to exploit. The gain from doing both is smaller than doing compression alone, and the gain from compression alone is frequently most of the available saving. Measuring this properly means comparing the compressed size, never the raw file size. Source maps are the other half. A minified bundle without a map cannot be debugged in production, and the map itself should be served privately while the generated file is served with the correct header. Modern map formats let you hide sources entirely, which stops the source leaking to anyone who views it. Treeshaking belongs in the same conversation. It removes exports nobody imports, and it only works when a module system marks side effects correctly. A file with a top-level side effect that is not declared keeps itself alive. There are cases where minifying is the wrong call, and I say so on the page: code you intend to read in a debugger, and files whose size is dominated by data rather than logic.