如何高效使用UglifyJS？Webpack Bundle压缩相关技术咨询

我来逐个解答你的疑问：

• 能否将该文件压缩至gzipped size的大小？
  这是做不到的哦。gzipped size是文件经过gzip算法压缩后的传输尺寸，这个过程一般是由服务器（比如Nginx、Apache）在向浏览器发送文件时自动完成的，或者你可以提前预先生成.gz后缀的压缩文件让服务器托管。UglifyJS做的是代码层面的压缩优化——比如删除空格换行、混淆变量/函数名、剔除无用代码等，压缩后的代码再经过gzip处理会更接近你看到的gzipped size，但本地的bundle文件本身没法直接变成gzipped对应的大小，毕竟gzip是一种传输层的压缩格式，不是代码本身的形态。

• 是否仅执行uglifyjs --compress filename命令即可实现此目标？
  远远不够。单独的--compress参数只是完成了代码的压缩（比如删除死代码、合并表达式），但要达到理想的压缩效果，你还需要搭配--mangle来混淆变量名和函数名、--output指定输出文件，甚至可以加上--drop-console这类参数删除调试用的console语句。
  另外，如果你是在Webpack项目中，更推荐用Webpack的压缩插件来集成这个流程——比如现在主流的terser-webpack-plugin（它是UglifyJS的继任者，对ES6+语法支持更好），直接在Webpack配置文件中配置插件，让Webpack在打包时自动完成压缩，比单独用命令行更高效，也能更好地配合Bundle Analyzer的分析结果来优化。

• 为何parsed size大于stat size？
  这两个数值的含义完全不同：

  • stat size：指的是模块文件在磁盘上的原始大小，也就是你写的源文件本身的大小（包括注释、空格、换行等）。
  • parsed size：是Webpack对该模块进行解析、处理（比如转译ES6到ES5、添加模块包装代码、合并依赖等）后，最终在bundle中所占的实际大小。
    出现parsed size大于stat size的情况，通常是因为Webpack转译代码时增加了一些额外代码（比如Babel转译ES6类、箭头函数到ES5时会添加兼容代码），或者给模块加上了CommonJS/ES Module的包装代码，导致最终解析后的代码体积比源文件稍大。

• 这样做对Bundle大小或性能能否产生丝毫影响？
  当然有影响，而且是非常正面的！
  首先，经过UglifyJS（或Terser）压缩后的bundle体积会显著减小，这会直接减少浏览器需要下载的文件大小，尤其是在网络条件较差的环境下，能明显提升页面的加载速度。
  其次，更小的bundle意味着浏览器解析和执行代码的时间更短，页面的交互就绪时间（TTI）会提前，用户能更快地和页面进行交互。
  再配合服务器的gzip压缩，最终传输给浏览器的文件会更小，进一步优化整体的加载性能。

内容的提问来源于stack exchange，提问作者The Walrus