For small files you might be mostly correct, but for larger ones min+compress can product much better gains than compression alone.
IIRC the algorithm used employs a rolling compression window, and can only match strings of tokens whose distance apart is smaller than that window. IIRC the default window is 8KBytes and the maximum is 32KBytes. Even if you use the maximum at the expense of CPU time that isn't going to cover many large files. Minifying increases the effective range of the compression window, each match is shorter but you will find more matches and usually this balances out in a way that benefits the compression result.
It isn't quite that simple in reality as there is huffman encoding and other tricks in the mix. This means that even for inputs smaller than the compression window you may see some benefit as minifying can reduce the input data's alphabet significantly.
Ignoring the "why it helps", it is easy to show that it does help in a great many real cases:
ds@s2:/tmp$ wget --quiet https://code.jquery.com/jquery-3.2.0.min.js
ds@s2:/tmp$ wget --quiet https://code.jquery.com/jquery-3.2.0.js
ds@s2:/tmp$ gzip jquery-3.2.0.min.js
ds@s2:/tmp$ gzip jquery-3.2.0.js
ds@s2:/tmp$ ls -l j*
-rw-r--r-- 1 ds ds 79201 Mar 16 21:30 jquery-3.2.0.js.gz
-rw-r--r-- 1 ds ds 30023 Mar 16 21:30 jquery-3.2.0.min.js.gzFor completeness, minifying alone achieves less than compression alone:
-rw-r--r-- 1 ds ds 267686 Mar 16 21:30 jquery-3.2.0.js
-rw-r--r-- 1 ds ds 79201 Mar 16 21:30 jquery-3.2.0.js.gz
-rw-r--r-- 1 ds ds 86596 Mar 16 21:30 jquery-3.2.0.min.js
-rw-r--r-- 1 ds ds 30023 Mar 16 21:30 jquery-3.2.0.min.js.gz
Attempts at improvement don't hurt at all, and in some cases can help a ton.
Also, purifycss and uncss are your friends to cut stuff down, to reduce the final load for the user.
True, the difference between 10KB compressed and 7KB minified+compressed is negligible for your visitors, but it still takes 30% off of your traffic bill.
We can build a "prod" version of the app and the minifying process will drop all the debugging code as well as any unused or uncalled functions from the output.
I would have thought that understanding what functions of a dynamic language that can be safely removed would require parsing/AST analysis beyond those found in the typical minifier.
We use blocks like this throughout our codebase:
if (process.env.NODE_ENV === 'development') {
fancyDebuggingFunction(stuff)
}
// ... some code later
fancyDebuggingFunction(var) {
/* do debugging things here */
}
Throw in Webpack 2's import/export bundling stuff, you can exclude whole modules which you don't use in production which can really reduce the size of your code.
And moving forward if the JS ecosystem can ever get a handle on a good way to move to import/export by default, you'll start seeing massive gains in this area by being able to strip out any parts of a library that you don't use.
Also, I believe most widely used minifiers use AST parsing to do their work.
It was a script embedded to the other people's pages (and yes, it delivered substantial functionality, it was not just a tracker), so minification saved a lot of traffic/money for the company.
-) Less work for decompression
-) Less total length means lexing+parsing will be a bit quicker
-) shorter class names will also mean a lower memory consumption because of shorter strings, and ideally fewer allocations if some pooling or smart allocator is used
But those points can probably be completely ignored, since JS is a way way bigger factor.
Depending on the scale, shaving a few kB here and there can amount to significant savings in the long run.
Say you have a document structured like [boring data] [secret data] [boring data]. I don't know if any existing compressor lets you do this, but the gzip file format (really the 'deflate' format used inside it) allows you to encode this (schematically) as follows:
[compressed boring data] || [uncompressed secret data] || [compressed boring data]
where each || is i) a chunk boundary (the Huffman compression stage is done per-chunk, so this avoids leaks at that level), and ii) a point where the encoder forgets its history - ie, you simply ban the encoder from referencing across the || symbols.
If you wanted, you could even allow references between different "boring" chunks (since the decoder state never needs resetting), just as long as you make sure not to reference any of the secret data chunks.
Edit to add: Also, if the "boring" parts are static, you can pre-compress just those chunks and splice them together, potentially saving you from having to fully recompress an "almost static" document just because it has some dynamic content.
debatable with HTTP2 . Furthermore, separate files are easier to cache. If one of them doesn't change it doesn't have to be loaded again. That's my experience with bundles, especially when one uses asynchronous module definition instead of babel, webpack and co.
I mean if I split a file in 10 exact pieces or if I split two files in the exact same 10 pieces as well I still have the same data.
(Edit: Well basically two files have mostly more data since they both might contain a BOM or so)
And see Nginx's `http2_max_concurrent_streams` option: https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2...
Unfortunately every time I read something about minifiers I got the feeling that people are optimizing the wrong problem.
If you gzip data over the line it's already compressed. So minifying your stuff will only help you a little.
The problem is on the client side. You can compress what you like but if the browser starts dropping frames because it has to compile/handle a ton of Javascript and CSS then minifying doesn't help the end user.