记一次失败的webpack优化探索之旅

前言

基于vue-admin-element框架，开发web后台项目，一直都很快活，因为只用关注项目业务代码，不用关注底层搭建。

但是最近，不那么快活了，因为，有个项目，在经历多次迭代后，项目启动和打包的时间越来越长、越来越长...截个图，大家感受一下。

启动时间：

打包时间：

（安装speed-measure-webpack-plugin插件并配置后，即可在启动或打包的时候，出现上述时间分析）

实在是有点忍无可忍了，于是决定，优化一下。

然后，就有一个前端小菜鸟，踏上了死磕webpack的不归路。

草率开始

本着不懂就要问的精神，上网搜索一番，很快就找到了优化攻略，然后不管三七二十一，就在自己的项目中实践起来...

• 缓存：cache-loader
• 多线程：thread-loader
• 压缩：terser-webpack-plugin
• ...

然而，实践的结果令人难过，启动和打包的速度并没有明显提升。

这是为嘛？

回归项目

一番反思过后，意识到自己的方法不对。项目内置了哪些webpack配置都未弄清楚，就随便加配置，这怎么行？于是，便开始老老实实地看起了项目代码。

项目的vue-admin-element框架是基于vue-cli4（内置webpack 4）的，vue-cli4 采用了无配置方式，在项目文件夹下直接看不到webpack的相关配置，所以需要用以下方式查看。

• 在终端项目跟目录下输入指令 npx vue-cli-service inspect --mode development >> webpack.conf.dev.js 会在项目根目录下生成一个 webpack.conf.dev.js文件，里面就会有当前的默认配置，但这种方法只能看到一部份配置，webpack-dev-server的端口等配置仍然看不到。
• 直接在依赖目录中查看，具体路径为 node_modules/@vue/cli-service/lib/commands/serve.js及node_modules/@vue/cli-service/lib/config/base.js

采用了第二种方式查看，发现vue-cli4除了进行了项目运行的webpack 基础配置，还做完了针对大部分应用的 webpack 优化配置。

缓存方面：

• 一些性能开销较大的 loader (如vue-loader)添加 了cache-loader，等 vue-loader 处理完再由它开启基于文件系统的模板编译缓存，以便于将结果缓存在磁盘中以减少编译时间
• 配置 webpack 内置的HashedModuleIdsPlugin，使得打包时只改变 修改/新增模块的哈希值，即未改动的文件名中的 hash (id)不变，从而维持未修改文件的缓存，以实现访问速度的提高。

多线程方面：

• parallel属性规定了是否为 Babel 或 TypeScript 使用 thread-loader,默认require('os').cpus().length > 1时开启。

压缩方面：

• 用 terser-webpack-plugin 插件对JS进行了压缩和 treeshaking，我们基本可以不用考虑代码混淆的事，也不必额外安装和配置 uglifyjs-webpack-plugin了。
• 在生产环境，经过 postcss-loader、css-loader 等处理之后，用 mini-css-extract-plugin把 css 提取成一个个单独的 css 文件。 再用optimize-cssnano-plugin对 css 进行压缩

拆包方面：

• 非测试环境下，通过optimization.splitChunks自定义代码分割逻辑，先把初始依赖的node_modules包提取到chunk-vendors.js文件，再把被不同入口的公共模块提取到chunk-common文件。

其他：

• 在测试环境关闭optimization.minimize压缩优化，以提高构建的速度

• 生产环境下，关闭资源地图(sourceMap)以提高构建速度和避免资源被定位到原始资源。不用再手动设置productionSourceMap: false

• ...

审思优化

vue-cli4已经做的这么好了，我们还能做什么？ 这个问题，# vue-cli4 (Vue 2.x) 项目打包优化方案里已经有比较详细的说明，简单总结如下：

• 拆包优化
• 把部分第三方库用CDN外链的方式引入
• 静态图片压缩处理
• 开启gzip构建压缩

关于拆包优化

我们的项目既有配置中已经做了如下优化：

所以，在我尝试加了echarts的分包而效果提升不明显后，就没有继续分包了...估计既有的拆包策略已经比较优秀了。

关于引入CDN外链

总觉得用第三方的CDN有点靠不住，比如大家都知道以前google还在国内提供服务的时候，很多网站使用了google的CDN服务，而后面我国因为政策及法规的关系关闭了国内网络对这些资源的访问，造成了这些资源不可访问，于是直接造成我们打开使用了这些资源的网站速度极慢。

所以，就没往自己的项目中加了...

关于静态图片压缩处理

我的项目中，大的图片已经手动压缩过了，所以，这个插件对项目优化暂时提升不大...

关于开启gzip构建压缩

这个也不知道效果咋样，试过的小伙伴们可以在下面留言，我好拿着大家的实践效果，跟我们的后端去商量，让他们在服务器里配置一下。

经验教训

在经历本次的webpack优化探索后，在用npx vue-cli-service build --report（vue cli4中已内置webpack-bundle-analyzer包分析插件） 命令生成report.html包分析文件后， 我终于意识到，我的项目中，存在着诸多问题。

1. 直接拿既有项目删减后作为新项目的框架，没有将用不到的图片、文件、依赖删除干净，也承继了既有项目的问题，比如Sass和less混用，xlsx-style、js-xlsx混用等
2. Echart、富文本（tinymce）、moment等没有按需引入

项目积重难返，如果改造优化，时间成本、改造风险摆在那，且这个项目不是我一个人的项目，所以，与其后期费劲优化，不如前期做好每一步工作...