webpack 构建产物优化（一）
前端性能优化这个话题已经老生常谈了，网上一搜一大把，但是很多都比较虚，没有多少可行性，比如优化网络，减少页面结构等等。大话都会说，实际优化起来，却没有可以立足的点。
本文就以 webpack 构建入手，分析影响性能的关键因素，提供检测方法，给到合理、可实施的优化方案。
让性能优化不只是纸上谈兵的东西
核心思路
针对 webpack 打包过程，我们可以从 减少产物体积 和 增加文件缓存率 两个方向入手优化。
文件缓存率是指两次打开浏览器，走缓存的文件体积 / 总文件体积，每次上线更改的文件越少，缓存率越高。
本文先从减少构建体积说起
开启treeShaking（避免引入全量包）
前端经常使用的 lodash 为例
import { uniq } from 'lodash'看似我们只引入了 uniq 方法，其实是引入了整个包。类似的还有组件库引用
import { Message, Modal } from '@arco-design/web-vue';在不使用插件的情况下，将会引入全部的组件库内容
我们只要其中的一个方法，不需要全部，解决这类问题，可以使用 babel-plugin-import 修改引用路径。
{
"plugins": [
[
"import",
{
"libraryName": "lodash",
"libraryDirectory": "",
"camel2DashComponentName": false
},
"lodash"
]
]
}通过 babel-plugin-import，最终只会加载所需模块，而不会将整个 lodash 导入：
// import { uniq } from 'lodash' 被改成了一下内容
import uniq from 'lodash/uniq';这样可以显著减小打包后的体积，再来看 analyse 的体积，已经从 469k 减到了 28k
使用更小的包替换
同样是时间处理函数，dayjs 11.8kb，moment 有 572 kb。没有必要的话，推荐使用更小的dayjs
避免重复包
当多个依赖需要不同版本的同一包时，NPM 会分别安装它们
在构建打包之后，不同版本的包也会进入到我们的产物中去，一个代码用了两次。
解决这类问题可以参考：https://webfem.com/post/npm-mult-module
避免引入sourcemap
初学者在不了解 webpack 的情况下，很容易把 sourcemap 也打包到代码中。
这时可以搜一下打包产物关键词 mappings之后有 AAAA之类的代码，就说明sourcemap 打包进了产物里。更多关于 sourcemap，可以搜一下相关内容。
代码压缩
代码是否压缩可以一眼看出来，同时 webpack 自带js压缩，css 与 html 压缩讲出单独模块讲解
原文地址：https://webfem.com/post/webpack-boundle-optimization，转载请注明出处
