Isn't this what source maps are for anyway?

Low footprint by default, anyone who wants to inspect then downloads the extra, and for bonus points can even see the original typescripted version instead of the js.

Doesn't gzip compression & source maps take care of this withou the abomination that is minification ?

Using the largest, unminified, single file I could find in my node_modules folder (which happened to be tsserver.js from typescript, 11mb and 185 000 lines long)

Raw: 11 403KiB

Raw gzipped: 1 881 KiB

Minified: 3 543 KiB

Minified gzipped: 865 Kib

A 2.17x reduction between the two gzips

Even with GZip, minification is huge

Most people aren't making webpages that need a quarter million lines of JS. For a normal sized webpage, difference between raw gzipped and minified gzipped is negligable.

Or maybe even "modern front end" hello world apps now need a quarter of a million lines because "modern" JS devs use super mega react typescript which installs 1000 npm dependencies and requires a 30 second "build" to generate a huge monolithic minified tree-shook js blob. I wouldn't know, I just use vanilla JS for my web pages.

Okay. Let's move goalposts.

For a small file (github.com/runk/node-chardet, release version 0.7.0, index.js, 154lines, 4KiB)

Raw - 3.30 KiB

Minified - 2.05 KiB

Gz - 1.01 KiB

Minified+Gz - 0.81 KiB

That's a 25% reduction

Still huge. If minifying before gzipping multiples the size of my transfers by a factor between 0.75 and 0.40, I'm not skipping it for the one oddball that wants the sources in a human-readable format on the production environment

They can use the sourcemaps, or find the files on github

Saving 200 bytes is "still huge"? For me 200 bytes is not worth the extra headaches minification introduces.

You're the one who complained my examples files were too big.

This is about the general discussion around minification. I don't care the specifics of your particular usecase.

The point is that it reduces filesizes even after gzip. You having an arbitrary threshold around 200 bytes is not interesting.

My point is that for most people, the size savings of minification are going to be miniscule because most people are dealing with small JS files. Not only that but it makes debugging a much bigger pain. You start needing to generate and distribute map files, you can no longer easily observe or modify state from Dev console, etc.

I'm not completely opposed to minification. Distributing some self contained library like OpenCV.js? Minify away. But minifying everything even application files under active development just impedes developer velocity IMO for very little benefit. You shave off a couple hundred bytes in exchange for worse development/debugging and ostensibly faster page loads but realistically the same page loads.

Hi! Website owner here. How quickly did this page load for you?

I make up for performance in other ways.

It seems you've stirred up the minification cargo cult, who all seem to be ignoring the actual performance data vs compression . Thank you for the article!

Doesn't really matter after compression unless the bulk of your code can be culled from the end product. Tbh the largest business value this has is slowing down people trying to use your internal APIs.

It would be nice to have experimentally-derived numbers to point to in order to help people visualize whether or not minification actually improves compression to any significant degree.

Quick test I've done with some popular frameworks. I wonder if minification affects to parsing speed.

    +--------------------------+---------+---------+---------+--------+
    |         Library          |  Size   | gzip -1 | gzip -9 | brotli |
    +--------------------------+---------+---------+---------+--------+
    | bootstrap.css            |  280813 |   47312 |   33109 |  24533 |
    | bootstrap.min.css        |  232948 |   42003 |   30776 |  22695 |
    | react.development.js     |   87574 |   28733 |   23513 |  19818 |
    | react.development.min.js |   25612 |   10217 |    9224 |   8052 |
    | tailwind-2.2.19.css      | 3642321 |  376787 |  304100 |  82049 |
    | tailwind-2.2.19.min.css  | 2934019 |  354063 |  294632 |  72803 |
    | vue.global.js            |  476920 |  134655 |  105130 |  87121 |
    | vue.global.min.js        |  167898 |   74769 |   65582 |  57922 |
    +--------------------------+---------+---------+---------+--------+

Edit: something important to note: some frameworks (e.g. React) have lots of comments on their un-minified versions, that are removed when minified. That affects their size greatly.

> Edit: something important to note: some frameworks (e.g. React) have lots of comments on their un-minified versions, that are removed when minified. That affects their size greatly.

Are you telling us your code doesn't? :-)

Hah! It's self-documenting!

Nah, in a more serious note, to properly compare the impact of minification, I should remove the comments from the unminified (maxified?) version first. :)

Nah that wouldn't be fair, the code I serve my users initially has comments too and the arguments that people bring to criticize minification is that it adds complexity if you want to read the code in the browser. The comments should stay

Often I avoid comments by using long names for functions and variables (e.g. the test whose name is a statement of the postulate behind it) and minimization squashes many of those.

Here's an old article: https://css-tricks.com/the-difference-between-minification-a...

In the example given:

Original - 147 KB

Minified - 123 KB (83%)

Gzipped - 22 KB (15%)

Both - 20KB (14%)

Compression is waaay more effective, so if you have to pick one, go with compressing. Is having readable source code worth the other 2KB? That's up to you. Source maps can do the same thing with less, though. Also, modern devtools have ways of de-minification (if you don't mind all the mangled variable names).

I've seen the same thing with different jQuery versions: https://stackoverflow.com/questions/3239125/is-there-any-poi...

At least with jQuery, it seems that minification matters considerably.

Can client/browser choose if to use compression? If so, this is a problem for the website

Yes, HTTP Accept-Encoding

Or people who cannot afford unlimited data plans.

Preempting because I know we tend to be a little out of touch here: yes there are still plenty of cell plans without unlimited data, mostly among the pay per month options.

Very few websites have optimised their assets and number of connections enough that the size of the code is the bottleneck. Moreover, code tends to be highly compressible. I doubt it really saves much bandwidth. All javascript build systems out there already does it, though. Not doing it would require people to go out of their way. I think that's ultimately the main reason people do it.

There are different aspects of minification though, right?

I don't know if you count tree shaking but I do know my main project at work has 60,000 files in node_modules and if all of those were incorporated in my bundle that would be a big problem. The "modern web stack" just wouldn't work without it.

I've done a lot of photo projects where asset optimization is pretty important because it is easy to get in a place where your site costs 4x as much to run as it should and just as easy to get in a place where you compressed files too much and your images suck.

I am getting into WebXR and facing even tougher problems of asset optimization since I do want to support 90 fps on the not-too-terribly-fast generic ARM Meta Quest 3. I'm sure there is more than one reason you can't upload images to Horizon Worlds but avoiding too many textures with too much detail has to be one of them.

Fair enough. All node_modules I've worked with this far has been huge. Including everything is definitely not an option.

An easy solution would be integrating a code unminifier/beautifier and viewer into browsers.

Source maps are a thing, which has the added benefit of letting you ship the comments if you actually care to educate your users on how your website works.

IMO, if minification is the difference between a slow and fast page load, it means you aren't utilizing compression. Minification is more obfuscation than anything, it doesn't really bring much to the compression table.