webpack-cover

时间:2019.3

Webpack 稳定版本为4, 正在 5 的 roadmap 中

记录一下当前时间对前端项目构建打包优化的策略

当前项目问题

我们的前端项目基本都是使用的是 create-react-app 的配置,冗余项太多,升级难。

在这个前提下,有个“极限项目”每次代码改动之后的 hot reload 都需要 30s,实在坐不住了,就动手做了打包升级。

before

这次是从代码依赖相对简单,后续测试回滚负担小的后台管理系统下手的。

总结下当前的痛点为:

  1. 项目启动慢
  2. Hot reload 慢
  3. Build 慢(上线前在后端项目里 build 时尤其明显)
  4. 没分包,文件体积太大

解决手段

首先把 Webpack 版本从 3 升到 4,起码先享受上工具本身升级后带来的优越性

1.分离配置文件(与性能无关,与开发维护体验有关)

分成 base、dev、prod 三个 config 文件

把通用配置放到 base 中,dev 与 prod 中只放与这两种模式强相关的配置

2.HappyPack

HappyPack

治疗各种编译慢

本地启动 server 编译时间: 30s => 10s

3.splitChunks 分包

splitChunks

这一功能在之前版本中是通过 CommonsChunkPlugin 来进行的。

初步分成三个包,减小 main 包体积。

根据业务特点,其实可以做懒加载,但是注意不能分太多,增加 http 请求数得不偿失。后台管理项目体积目前不大,各模块也没什么业务上的明显区分,就没啥做懒加载的必要。

结果:包体积:6M => 3M

4.将第三方巨型包打入 externals

经过以上分包后,用 BundleAnalyzerPlugin 看了下结果

发现有个非常显眼的巨型包 echarts

把它的 min.js 扔到公司 cdn 上,在 html 中直接引入:

1
2
3
externals: {
echarts: 'echarts'
}

效果也很明显,当时没截图,就不贴对比图了

5.gzip

after

通过引入 CompressionWebpackPlugin 插件,打出来 .js.gz 资源,在服务器已支持 gzip 的情况下,所加载资源体积(直接到了 1.3M)和时间提升非常明显

6.常规操作

还有很多升到 webpack@4 之后的常规操作:

MiniCssExtractPlugin

TerserPlugin

OptimizeCSSAssetsPlugin

等等

随便搜搜,或者按图索骥去最新版的 create-react-app 源码里看看用了啥就行