Terser vs. UglifyJS - Dramatic Improvements

[anton164]

Perhaps this belongs in the terser repo, but I thought I'd give it a go here.

We're developing a fairly large scale single page application, and we've been experiencing tedious problems with UglifyJS recently - minifying takes up to ~35 minutes, hence we're looking for a better solution.

I just tested out this plugin, and the difference is astonishing. Here are some results:

Without cache:
UglifyJsPlugin took 34 mins, 32.53 secs
UglifyJsPlugin took 32 mins, 7.82 secs
TerserPlugin took 13 mins, 38.86 secs
TerserPlugin took 12 mins, 12.99 secs
TerserPlugin took 5 mins, 33.013 secs 🚀

With cache:
UglifyJsPlugin took 3 mins, 43.85 secs
UglifyJsPlugin took 3 mins, 5.26 secs
TerserPlugin took 1 min, 32.78 secs

So Terser seems to speed it up by 3x and since it took me just about 2 minutes to switch from UglifyJS it seems almost too good to be true.

Is this to be expected? I'm basically looking for some confirmation from others. I haven't been able to find any performance tests elsewhere.

Anyhow, great work, this looks very promising! 💯

[alexander-akait]

@anton164 Thanks! Unfortunately performance are not exists. I heard about increase perf from many developers. Looks guys from terser do great job. And yes it is expected, don't worry 😄

webpack@5 will use terser plugin by default.

My recommendation is switch to terser plugin ASAP.

[alexander-akait]

Also uglify plugin right now use uglify-es (this package is abandoned and contains a lot of bugs). New version uglify plugin switch back to uglify-js (webpack-contrib/uglifyjs-webpack-plugin#352) and it is should to fix these bugs and increase perf also, but uglify-js doesn't support ES6 code.

[anton164]

Great, thanks! That gives me the confidence to proceed :)

Will add some more performance tests once I get a hold of them

[edmorley]

Hi!

After seeing this, I tried comparing terser-webpack-plugin and uglifyjs-webpack-plugin and there was no noticeable speed-up caused by switching for the project I tested it against.

Is it possible there were other differences in config/environment?

For example, the default webpack configuration using uglifyjs-webpack-plugin also sets sourcemap: true if appropriate (which would presumably take longer than if not enabled):
https://github.com/webpack/webpack/blob/3366421f1784c449f415cda5930a8e445086f688/lib/WebpackOptionsDefaulter.js#L308-L314

Also, the new webpack-sources v1.2.0 contains a significant performance improvement (webpack/webpack-sources#32), and whilst both uglifyjs-webpack-plugin and terser-webpack-plugin have a dependency on webpack-sources@^1.1.0 (whose range is satisfied by 1.2.0), I was wondering if your lockfile when trying the former might have been still on 1.1.0 rather than 1.2.0 (since installing the new package might have given the transient dependencies a refresh)?

That said, terser-webpack-plugin is definitely preferred given it's maintained and has many more correctness fixes - so even if there aren't performance improvements (yet), it's worth switching.

[anton164]

Here's my config, which does include source maps:

      new TerserPlugin({
        sourceMap: true,
        parallel: true,
        cache: './.build_cache/terser',
        exclude: /transpiledLibs/,
        terserOptions: {
          warnings: false,
          ie8: false
        }
      })

I am again experiencing issues, so you're proabably right @edmorley. I believe my issue is related to webpack-contrib/uglifyjs-webpack-plugin#272, however it doesn't happen consistently, and the issue with long builds seems to resurface in CircleCI.

It's a large bundle, so creating a minimum reproducible test case isn't straight forward.

[kzc]

This terser patch is responsible for the big speedup in some projects. Details here.