用nuxt开发完项目之后，开开心心打包扔上服务器准备收工，却没多久，测试童鞋遗憾的告诉我，压测50并发未通过。what？好吧。咱们再接下来老老实实的研究怎么压缩打包优化性能。
性能优化，无外乎那几个方案：文件压缩，文件缓存，CDN，DNS 预解析。。。
这里我们首先看一下不加任何优化的项目，打包后的分布：
未优化
这里能看到element-ui占了绝大部分的打包空间，是因为全局引入了element-ui，所以即使我们只使用了一部分的elemnt组件，但仍然把整个element给打包进来了。
所以这里有一个可以优化的点：只引入element使用的组件，这样在打包的时候只需要打包使用的组件，体积就会减小很多。
只引入使用的组件
我们再来看看这么处理之后，我们打包出来的效果：
引入部分elemnet组件后的打包分布
可以看出，我们减少了将近400kb的体积，效果十分显著。
好了，我又自信满满的把包丢到服务器上，准备金盆洗手。😎
然鹅没过多久，运维童鞋发过来一张图把我打回原点。
vendor.app.js阻塞了
我看了一下vendor.app.js，足有501kb，难怪会阻塞🤷♀️好吧，这里应该使用上文件压缩这杆大枪了。
nuxt本身就是基于webpack的，正好安装compression-webpack-plugin来对文件进行压缩。
首先安装npm install compression-webpack-plugin
然后在nuxt.config.js中：
const CompressionPlugin = require('compression-webpack-plugin');
module.exports={
build: {
plugins: [
new CompressionPlugin({
test: /\.js$|\.html$|\.css/, // 匹配文件名
threshold: 10240, // 对超过10kb的数据进行压缩
deleteOriginalAssets: false // 是否删除原文件
})
],
}
}
这样打包出来的大小虽然没变，但是点击.nuxt-dist-client中你会发现
有gz后缀的文件
观察发现gz打包后，较原来的文件减少了3/4的体积。有了这些gz后缀的文件，再配合nginx打开gzip服务。我想这回应该可以冲过50并发了吧，说不定200并发都没问题🤩🤩🤩
好了，我这回真的自信满满的把包丢到服务器上，通知测试童鞋再次压测，果不其然，测试童鞋过了一会回复：50并发跑5次无异常。😎😎我大气说，上100！我翘着得意的二郎腿，等着好消息再次到来。过了一会，果不其然！测试童鞋告诉我，100并发阻塞。原因同上，出在了vendor.app.js上😭
这里我说一下vendor.app.js打包之后的体积是144kb。然鹅在高并发下，表现还是不理想，于是乎我只能上网去到处搜索解决方案，毕竟po主的webpack知识也就那么一勺水的深度🤷♀️🤷♀️
这里还真让我找到了一个台湾的网站，可见参考链接第三条。
splitChunks: 設定 Chunks 的最大和最小 size。
在nuxt.config.js中加入：
module.exports={
build: {
optimization: {
splitChunks: {
minSize: 10000,
maxSize: 250000
}
},
}
}
打包，观察打包结果：
splitChunks之后的打包分析
可以看到虽然包体积虽然没变，但是像vendor.app.js这种单个体积大的被拆分成n个体积小的文件了。
这回终于是可以突破100并发5次无异常，达成并发要求了🎉🎊🎉🎊
总结一下，其实po主也不是什么webpack大神，也是摸爬滚打整出来的，大家如果能有什么更好的优化建议或者指教，请多多交流，不对之处我会改正！
参考：
网友评论