NUXT项目打包优化策略

用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大神，也是摸爬滚打整出来的，大家如果能有什么更好的优化建议或者指教，请多多交流，不对之处我会改正！

参考： 

Nuxt 项目性能优化调研

NUXT项目的性能优化

SplitChunks & Lodash & Vuetify tree shaking