[HN Gopher] JavaScript Minification Benchmarks
___________________________________________________________________
JavaScript Minification Benchmarks
Author : wagslane
Score : 46 points
Date : 2021-02-06 17:49 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Xevi wrote:
| I wonder why SWC is so far behind the rest in terms of minified
| size. Kinda makes me not want to use it to be honest. Maybe
| there's some low hanging problems to tackle to make it better?
| kaleidawave wrote:
| Awesome benchmarks. Would be interesting how much minification
| affects actual client and server performance?
|
| And as understand all these tools use a lexing and ast parsing
| stage. It would be interesting if you could build a very simple
| minifier (at least a whitespace one) that could skip that step
| through just working on input buffer?
|
| There is also the fact that more code means longer minification
| time. You can praise esbuild for building a CRA in 2 seconds but
| there are workflows/frameworks that compile sub second by using
| less runtime code.
| bumbledraven wrote:
| Wow, esbuild comes away as the clear winner overall. It's always
| the fastest -- often at least 10x as fast as many of the others -
| and its compression ratio was within 2% or so of the best in all
| cases.
| bastawhiz wrote:
| I'm very bullish on esbuild. But in testing with my own app, it
| produces output 8-12% bigger than the same files processed with
| terser. I would bet that it's a small number of optimizations
| that are missing that benefit codebases like mine (JSX-heavy).
|
| My biggest frustration is that I am not nearly as skilled in Go
| as I am in other languages, and don't have the confidence
| jumping into a large existing Go codebase than I would with
| JS/TS/etc. I have the same issue with Flow, which is written in
| OCaml.
| capableweb wrote:
| > clear winner overall. It's always the fastest
|
| If you're mostly worried about how quickly you can minify when
| you do minify, then you're worrying about the wrong thing. You
| want as small results as possible that can be executed the
| fastest, how long time it takes doesn't really matter as you
| only minify on delivery to end-users, not every time you make a
| change locally.
|
| So instead it seems Google Closure is the best, in the cases
| the author got it to work. Otherwise it's UglifyJS/Terser,
| depending on your needs.
| randomfool wrote:
| Working on codebases where the compilation times can often be
| 30-60s, a 10x improvement makes a massive difference in
| development flow and is definitely worth a 2% regression in
| size. It's the difference between being multi-tasking while
| compiling and not.
|
| Of course you could use esbuild for dev and terser for prod,
| but maintaining two may be a support headache.
| [deleted]
| danappelxx wrote:
| When would you need to minify in dev?
| wgjordan wrote:
| > If you're mostly worried about how quickly you can minify
| when you do minify, then you're worrying about the wrong
| thing.
|
| You don't need to be 'mostly' worried about how quickly you
| can minify for esbuild to be the top choice- if you're only,
| say, 10% worried about build times and still 90% ('mostly')
| worried about size + execution speed, esbuild still comes out
| on top from these benchmarks.
| capableweb wrote:
| Or, put in another way: If you're are 10% worried about
| that you get to do production deploys 10% faster and 90%
| worried about how fast you can deliver the code to your
| users when they load your site (and/or bandwidth costs that
| increases with each user), then esbuild might make more
| sense for you.
|
| For the rest of us that are 100% focused on the best
| experience for our users, we stick with the tools that does
| the best minification while being a bit slower, and throw
| more hardware at it if needed for the deploys.
| yoz-y wrote:
| If you can do 10x the builds in a day, you can end up
| catching more issues before your users. Meanwhile the
| difference for them is in single digit percents.
| Interesting test to do next would be how performant are
| the compiled versions.
| Griffinsauce wrote:
| > throw more hardware at it
|
| And pay more. ESBuild is so much faster that I imagine it
| could have a significant impact on costs.
|
| Besides, yes you make a good point about the size savings
| scaling with users, but development speed compounds
| changes over time.
|
| The choice is a bit more nuanced than "smaller build
| always === 100% focused on the best experience"
| shirakawasuna wrote:
| A 2% difference is pretty small, though. Small enough that
| the top four or so minifiers appeared to have very similar
| performance - just depended on which codebase you were using.
| If you're picking a minifier, I'd definitely go with esbuild
| given that it falls in that 'top of the pack' group and is
| vastly vaster.
|
| If someone were only interested in the smallest possible
| minified size, the appropriate solution would be to use all
| of these minifiers every time and choose the smallest result.
| mschuetz wrote:
| No, I vastly prefer 10x faster build times and merely 2% file
| sizes over anything that's on order of magnitude slower. It's
| not even a competition.
| cj wrote:
| Of course developers prefer faster build times. But what do
| the end-users who you write code for prefer? (Especially in
| a typical CI/CD environment where developers often don't
| need to monitor and wait for builds to finish)
|
| 2% sounds small. And it is, if your traffic is small. It's
| not small when you have millions of users.
| jahewson wrote:
| End users prefer that we ship the features and squash the
| bugs they care about, which can be done faster with
| shorter build cycles. Our webpack prod build, which we
| have to run as sometimes minifying breaks things, takes 6
| minutes. It's the longest build step we have.
| mschuetz wrote:
| It's tiny, and usually negligible in context with all the
| other data that needs to be transferred, even with
| millions of users. Millions of users might be the
| situation where I'd start thinking of integrating slower
| builds as an alternative, provided they can seamlessly
| live side-by-side with the fast build tools.
| jakear wrote:
| Why would end users don't care if there are a million
| other people getting a bit larger download size..?
| Accounts payable might care, but they aren't end users.
| cj wrote:
| 2% file size reduction is probably an over optimization
| for a new startup searching for their first users.
|
| But for an established product with substantial traffic,
| swapping out a js minifier for one that achieves even
| single digit % compression improvement seems worthwhile
| to me - if the only downside is adding a few extra
| seconds to build time.
| [deleted]
| Griffinsauce wrote:
| > how long time it takes doesn't really matter
|
| It might be a bit of a red herring but build (and thus
| deploy) times absolutely do matter.
|
| Going from a 30 second deploy to a 2 minute deploy to a 30
| minute deploy has severe impact on your workflow, how atomic
| your changes can be and how immediate your feedback loop is.
|
| I think (without data but from my own experience) it's one of
| the most massive underlooked productivity-sinks especially in
| web.
| FriedrichN wrote:
| I don't know about you but I don't minify my code when I'm
| working on it, only when I'm deploying it for final testing
| and production.
|
| I don't see a reason, but maybe there is one.
| yoz-y wrote:
| I definitely started to also run tests on minified code
| and found bugs in compilers that I had to work around.
| goeiedaggoeie wrote:
| You would also develop and deploy against closure using
| simple for your dev workflow and only run advanced more
| infrequently. Advanced also gives deeper type schecking. I
| have not worked with closure compiler in years, but it is a
| different and incredibly powerful beast. Easily extendible
| with your own compile passes as well
| capableweb wrote:
| True and I agree with you, fast deploys are one of the most
| massively underlooked productivity-sinks. Minification
| tends to be the slowest step in a frontend pipeline (at
| least in my experience) but it's closer to a two minute
| step with Google Closure Compiler on a small-size codebase
| (+20K LoC) than 30 minutes, and the size difference is more
| important (for us) than the difference between seconds when
| deploying.
| noahtallen wrote:
| I disagree only because a large e2e test suite can be
| very long. I often see 20-30 minute e2e suites for large
| applications. Applications which compile in a few
| minutes.
|
| Totally agree re: deploy being very important to
| optimize.
| jontro wrote:
| Why would you minify it at all if so? The fastest would be
| no minification
| dwohnitmok wrote:
| The point is that the two are competing priorities. You
| still care about minimizing end user download size, but
| you also care about your own developer experience (and
| concomitant velocity).
|
| Different people may weight those things differently, but
| it is unlikely that someone would assign a weight of zero
| to one or the other (so people are unlikely to just throw
| up their hands and say "no minification").
| franciscop wrote:
| I found esbuild a few months ago and... never gonna use a
| different one when doing things manually, the speed different is
| abyssal. It takes two orders of magnitude lower than the
| alternatives as shown in these benchmarks.
|
| On the other hand, with Node.js supporting native import/export,
| I also find myself bundling+minifying the code less and less.
| Just wish Create-React-App started using it, since I cannot be
| bothered to dig there enough to manually set it up (the goal of
| me using CRA is to avoid manual config).
| BiteCode_dev wrote:
| Not exactly apples to apples, but I'd like to plug in Vite:
| https://github.com/vitejs/vite
|
| Not that it makes fast minification (which I don't care that much
| about, I minify only on deploy, and it's a small % of the time it
| takes), but it does allow for a very fast workflow in dev mode:
| auto reload seems almost instant even with heavy transpiling.
|
| I only mention it because I assume people look at this articles
| and think about their dev process speed as well.
|
| If you haven't, give it a try: it's from the Vue author, so it's
| really clean, but works with react as well.
| iimblack wrote:
| From a first look this seems very similar to Snowpack. I'll
| have to check it out more to see how they actually compare.
| ianertson wrote:
| I also made some benchmarks, including my own bundler:
|
| https://www.github.com/sebbekarlsson/fjb/tree/master/benchma...
| capableweb wrote:
| Seems almost Google Closure (advanced) fails in half of the tests
| but otherwise wins the tests if it's successful. Seems to early
| to claim any "winner" here before someone manages to fix the
| tests.
|
| A comment reads "google-closure-compiler is no longer maintained"
| but that's completely misleading. Maybe that's why the author
| didn't bother to fix their config for Google Closure?
| randomfool wrote:
| Google Closure's advanced optimizations require annotations
| throughout your codebase- in many codebases it may require
| significant effort to get this working. When you need that
| extra optimization it's great but can be a lot of effort
| otherwise.
|
| I'm most excited about esbuild though and I'm curious how it'll
| fit into a larger codebase & ecosystem. The author is
| aggressive about keeping it simple (for good reason!!)- the
| focus on speed is awesome.
| capableweb wrote:
| > it may require significant effort to get this working
|
| You're right, the author probably didn't provide externs
| and/or exports, so the tests fails. It's not really that much
| of an effort, especially if you're supposed to be testing the
| tool itself. Considering that the author is already testing
| libraries that have externs/exports written for them already,
| just shows the lack of care of the tests.
| newlisper wrote:
| Google Closure is the best at minification but it's also
| the worst less pragmatic option for 99% of projects.
| yladiz wrote:
| Off topic for this, but I've always wondered, why do these tools
| call this process "minification", not "minimization"?
| austincheney wrote:
| Because it comes from the word _minify_ , which I believe was
| created by Douglas Crockford. To my knowledge he created the
| first minify tool, JSMin, in 2001. He described using that tool
| as _to minify_.
| lhorie wrote:
| Because "minimize code" already has another meaning
| capableweb wrote:
| That's the first time I hear that. I always understood
| minification and minimization as synonyms. What would
| minimizing code mean for you?
| lmkg wrote:
| My parse of "minimizing code" is that it's an approach to
| _writing_ code, with the goal of writing less code. I would
| expect it to include things like terse idioms, DRY,
| preferring data over code, preferring configuration over
| code, preferring libraries over rolling your own, managing
| scope, etc. All things about writing _different code_ ,
| which solves the problem but is not always semantically
| equivalent.
|
| By contrast, minification is mechanical semantic-preserving
| syntax transformations done to a completed program after it
| written.
| evmar wrote:
| This whole page is weirdly similar to a project I did, for the
| same purpose:
|
| https://evmar.github.io/js-min-bench/
|
| What I discovered there is that the best minification is one
| where you just produce an empty file -- it's 0 bytes of output
| and extremely fast.
|
| And if you say "wait, I have have the additional requirement that
| you didn't break the code in the original file, obviously!", you
| then must define what exactly "break" means in that requirement--
| for example, it could be that some user requires that
| someFunction().toString().charAt(10) == 'a', in which case even
| removing whitespace counts as breakage.
|
| You might think the above is just being overly pedantic or
| pathological, but it demonstrates a principle that actually ends
| up mattering, which is that you can't evaluate a minifier unless
| you define what a successful minification even means.
| Particularly in the case of more advanced transformation.
|
| I went into it more in this post:
|
| http://neugierig.org/software/blog/2019/04/js-minifiers.html
| jiofih wrote:
| Sorry but what do you mean by "weirdly similar"? It's a
| benchmark of minifiers against popular libraries, what's the
| creative part?
| yoz-y wrote:
| I guess a reasonable requirement for a momifier would be that
| the test suite passes 100% of tests after minification.
| deanclatworthy wrote:
| If you've not yet used esbuild for a simple react or typescript
| project give it a try. It's far far simpler than webpack and
| ridiculously quicker.
| jacobp100 wrote:
| I just tried esbuild on a project that was using webpack. Had one
| bundle go up from 107kb to 111kb, then if I run it through
| terser, it'll go back down to 109kb. The speed was phenomenal -
| even when running through the separate terser step, it's so much
| faster.
___________________________________________________________________
(page generated 2021-02-06 23:01 UTC)