介绍 webpack-bundle-analyzer 这个插件来分析SPA应用。
使用
npm install --save-dev webpack-bundle-analyzer
在webpack的plugins中配置： new BundleAnalyzerPlugin()
在package.json 中增加： "analyz": "NODE_ENV=production npm_config_report=true npm run build"
npm run analyz 后会自动打开 http://127.0.0.1:8888/ ，视图如下：
vendor包属于工程基础包，里面包含了node_modules下的依赖模块，因为这些依赖是比较稳定的，所以可以配合ETag做http层的缓存。
use-repeat包属于业务基础包，里面包含业务场景常用到依赖和工具，打入此包的前提：在应用中重复使用大于等于3次。
为什么需要分出 工程基础包 和 业务基础包？
工程基础包是整个工程常用的node_modules的依赖，这里的内容不会经常变动，所以单独抽出来并且搭配ETag来实现缓存是常用的spa 优化方案。
业务基础包大部分不是node_modules的模块，例如我们在common中存放的一些基础组件，其次是一些三方的组件库（这些是在node_modules中的，但是因为经常变动所以不适宜放在vendor中）。如果业务基础包不进行提取会导致单chunk包重复打包相同模块，也增加了单chunk包的体积。
对应的webpack配置如下：
// 工程基础包
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
minChunks: function (module, count) {
return (module.resource && /\.js$/.test(module.resource) && module.resource.indexOf(path.join(__dirname, '../node_modules')) === 0)
}
})
// 业务基础包
new webpack
.optimize
.CommonsChunkPlugin({
async: 'use-repeat',
minChunks: (module, count) => (count >=3)
})
到此还不算结束，因为如果要配合ETag做缓存，需要保证打出来包hash不能改变，下面是常见的output 配置：
output: {
path: path.join(__dirname, '../dist'),
filename: '[name]-[chunkhash].js',
chunkFilename: '[name]-[chunkhash].chunk.js'
}
hash 是 build-specific ，即每次编译都不同——适用于开发阶段
chunkhash 是 chunk-specific，是根据每个 chunk 的内容计算出的 hash——适用于生产
使用chunkhash就保险了吗？
这里涉及到三个问题：1.webpack运行文件 2.module id 3.chunk id ， 解决方案如下：
// 将webpack运行文件抽离出来，不然每次打包运营文件的hash都会改变
new webpack.optimize.CommonsChunkPlugin({
name: 'runtime'
})
// 固定module id
new webpack.HashedModuleIdsPlugin({
hashFunction: 'md5',
hashDigest: 'hex',
hashDigestLength: 8
})
// 固定chunk id
new webpack.NamedChunksPlugin((chunk) => {
// 解决异步模块打包的问题
if (chunk.name) {
return chunk.name;
}
return chunk.modules.map(m => path.relative(m.context, m.request)).join("_");
})
相关文章：https://zhuanlan.zhihu.com/p/34110535
最后不得不吐槽下 简书 的编辑功能真的好难用，不是不想多写一些思考，是真的难用。现在基本每天的思考和总结都会放到语雀上，简书是想起来回来更新一下。
