Webpack添加优化配置后Chrome Coverage显示体积缩小但实际包体积增大的原因

原因1：统计维度差异 #

Chrome Coverage工具和实际bundle体积的统计口径完全不同：

• Coverage的“体积”列统计的是浏览器加载后完成解码、gzip/brotli解压后的代码字节数，你看到的体积下降本质是运行时需要执行的代码逻辑减少，和打包后输出的原始bundle磁盘体积、部署用的压缩后体积没有直接对应关系。

原因2：Tree Shaking带来额外runtime代码注入 #

你开启的usedExports、sideEffects等tree shaking相关配置，会让Webpack注入额外的标记逻辑、模块导出校验的runtime代码：

• 移除未使用代码后，Webpack需要新增辅助逻辑处理模块的导出关联、副作用标记校验，当这部分新增的runtime代码体积超过你移除的冗余代码体积时，就会出现最终bundle整体小幅上涨的情况，2kb的涨幅在中小项目中非常常见。

原因3：Minify压缩策略变化 #

开启tree shaking相关配置后，Terser等压缩工具的压缩逻辑会受到限制：

• 为了保留tree shaking的标记、避免误删有效代码，压缩工具可能会放弃部分原本可以生效的变量合并、代码折叠优化；同时Webpack为了保留模块导出信息，不会把多个小模块的代码合并成连续的高可压缩性片段，降低了整体压缩率，最终导致体积上升。

原因4：模块拆分规则隐性变化 #

开启providedExports、usedExports后，Webpack的模块依赖分析逻辑会调整，原本被合并到同一个chunk中的模块可能被拆分到不同的chunk，如果你只统计了单个入口bundle的体积，没有统计其他拆分出来的chunk的体积变化，也会出现单个bundle体积上涨的错觉。

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