ESbuild lags behind (non-trivially) in producing gzip friendly output for large pacakges
See original GitHub issueThanks for publishing these benchmarks. I’m the author of bundlephobia (a tool developers use to find out minified and minzipped sizes of npm packages) and was contemplating on replacing Terser with ESBuild’s minifier to shave a few seconds from build.
Seeing this benchmark, I got the picture that ESBuild and Terser and neck to neck. However, this doesn’t seem to be the case for large packages. While the minified size might still be comparable in some cases, the gzipped size difference between esbuild and terser can vary between 5%-9% — which one might consider non-trivial difference for minification.
Benchmarks after replacing Terser with ESBuild in Bundlephobia’s webpack config, and after manually extracting out license-style comments —
Package | Minified Terser | Minified ESBuild | Minzip Terser | Minzip ESBuild |
---|---|---|---|---|
webpack | 2.48 MB | 2.52 MB (+2%) | 650KB | 683 KB (+5%) |
echarts | 957 KB | 975 KB (+2%) | 304KB | 316 KB (+4%) |
antd | 1.16 MB | 1.27MB (+9%) | 345 KB | 370 KB (+7%) |
victory (charts) | 518 KB | 532 KB (+3%) | 130KB | 140 KB (+8%) |
The results remain the same whether running esbuild minify through esbuild-loader
or the ESBuild CLI on the webpack built bundle.
Is there anyway to capture this on the current page?
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (6 by maintainers)
https://unpkg.com/victory@35.4.13/dist/victory.js is rather odd. Every bundled module is an
eval
’ed string block of webpack requires:Perhaps it was produced with webpack’s debug or development mode. While it can be (poorly) minified, I don’t think it is representative of how typical production libraries or applications are bundled and probably should not be included in the benchmark.
Closed via https://github.com/privatenumber/minification-benchmarks/commit/5aac6e5b313ae594cb5d3b2b248f7a7b3bedab3a