共计 1669 个字符，预计需要花费 5 分钟才能阅读完成。
前言
最近在帮同组的兄弟项目做需求，这几天差不多业务代码写完了。
本着搞事情的原则，简单分析之后，决定搞一波优化。
先简单看一下优化成果。
先睹为快
优化前：
优化后：
???????? 30%⬆️ ????????
前：
后：
效果还是有一点的，下面就看看具体的步骤。
都做了啥
step1 – 分析瓶颈
第一步当然是先找影影响最大的因素，这次主要是处理打包和加载的一些问题，所以还是先整体分析一些项目的构成，具体的渲染问题不在此篇范围。
首先，祭出一个包分析工具：webpack-bundle-analyzer.
具体的使用方法：
// webpack.config.js
const BundleAnalyzerPlugin = require(‘webpack-bundle-analyzer’).BundleAnalyzerPlugin;
// …plugins
new BundleAnalyzerPlugin({
analyzerMode: ‘server’,
generateStatsFile: true,
statsOptions: {source: false}
})
安装，然后重启一下 server，然后就可以在 http://127.0.0.1:8888/ 看到这个分析了。
简单分析一下之后发现几个问题：
node-modules 都打在了一个包里，体积达到了 4.52M.
有的包使用姿势不对，没有被 tree-shaking, 比如那一大坨 lodash 和 vue-awesome.
有个炒鸡大的 css 文件
了解上述信息后，就可以开始逐个击破了。
step2: 对症下药
1. Bundle Split
修改之前：
optimization: {
splitChunks: {
cacheGroups: {
commons: {
test: /[\\/]node_modules[\\/]/,
name: ‘vendors’,
chunks: ‘all’
}
}
}
},
修改之后：
optimization: {
runtimeChunk: ‘single’,
splitChunks: {
chunks: ‘all’,
maxInitialRequests: Infinity,
minSize: 0,
minChunks: 1,
cacheGroups: {
commons: {
test: /[\\/]node_modules[\\/]/,
name(module) {
const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1];
return `modules.${packageName.replace(‘@’, ”)}`;
}
}
}
}
},
https://webpack.js.org/plugin…
2: 按需加载
vue-awesome:
lodash:
eg:
3: 公共资源放 CDN
回头去看那个 css 文件，原来是个主题包，其他项目也在用，这就好办了，拿出来放 CDN 上，直接饮用就好了，没必要打在包里。
模块按需加载
react 有 Loadable 这样的工具，原理其实都是一样的。
https://github.com/jamiebuild…
可以在适当的节点异步加载所需的模块，避免一股脑的打在一起。
比如你可以单独加载某个页面，比如：
const Hello = () => import(‘./components/Hello.vue’);
Vue.component(‘xxx’, Hello);
这样每一个模块就会被单独打包:
与此同时，你还需要另一个工具去合并这些小包产生的 HTTP 请求：
https://webpack.js.org/plugin…
大概就是这些，当然可能处理的细节还有很多，这里就不赘述了.
结语
优化是个一步一步逐步深入的过程，有时候也可能需要妥协，但是每做一步优化，心情都会是愉悦的，也是能带来成就感的，或许还能拯救你的 KPI，哈哈。
希望上面的一些文字能给你带来一些些启发。
才疏学浅，难免会有疏漏，还请指正，谢谢。
推荐阅读：https://segmentfault.com/a/11…
