前端构建效率优化之路

🚀 优质资源分享 🚀

学习路线指引（点击解锁）	知识定位	人群定位
🧡 Python实战微信订餐小程序 🧡	进阶级	本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。
💛Python量化交易实战💛	入门级	手把手带你打造一个易扩展、更安全、效率更高的量化交易系统

项目背景

我们的系统（一个 ToB 的 Web 单页应用）前端单页应用经过多年的迭代，目前已经累积有大几十万行的业务代码，30+ 路由模块，整体的代码量和复杂度还是比较高的。

项目整体是基于 Vue + TypeScirpt，而构建工具，由于最早项目是经由 vue-cli 初始化而来，所以自然而然使用的是 Webpack。

我们知道，随着项目体量越来越大，我们在开发阶段将项目跑起来，也就是通过 npm run serve 的单次冷启动时间，以及在项目发布时候的 npm run build 的耗时都会越来越久。

因此，打包构建优化也是伴随项目的成长需要持续不断去做的事情。在早期，项目体量比较小的时，构建优化的效果可能还不太明显，而随着项目体量的增大，构建耗时逐渐增加，如何尽可能的降低构建时间，则显得越来越重要：

1. 大项目通常是团队内多人协同开发，单次开发时的冷启动时间的降低，乘上人数及天数，经年累月节省下来的时间非常可观，能较大程度的提升开发效率、提升开发体验
2. 大项目的发布构建的效率提升，能更好的保证项目发布、回滚等一系列操作的准确性、及时性

本文，就将详细介绍整个 WMS FE 项目，在随着项目体量不断增大的过程中，对整体的打包构建效率的优化之路。

瓶颈分析

再更具体一点，我们的项目最初是基于 vue-cli 4，当时其基于的是 webpack4 版本。如无特殊说明，下文的一些配置会基于 webpack4 展开。

工欲善其事必先利其器，解决问题前需要分析问题，要优化构建速度，首先得分析出 Webpack 构建编译我们的项目过程中，耗时所在，侧重点分布。

这里，我们使用的是 SMP 插件，统计各模块耗时数据。

speed-measure-webpack-plugin 是一款统计 webpack 打包时间的插件，不仅可以分析总的打包时间，还能分析各阶段loader 的耗时，并且可以输出一个文件用于永久化存储数据。

// 安装
npm install --save-dev speed-measure-webpack-plugin

// 使用方式
const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");
const smp = new SpeedMeasurePlugin();
config.plugins.push(smp());

开发阶段构建耗时

对于 npm run serve，也就是开发阶段而言，在没有任何缓存的前提下，单次冷启动整个项目的时间达到了惊人的 4 min。

生产阶段构建耗时

而对于 npm run build，也就是实际线上生产环境的构建，看看总体的耗时：

因此，对于构建效率的优化可谓是势在必行。首先，我们需要明确，优化分为两个方向：

1. 基于开发阶段 npm run serve 的优化

在开发阶段，我们的核心目标是在保有项目所有功能的前提下，尽可能提高构建速度，保证开发时的效率，所以对于 Live 才需要的一些功能，譬如代码混淆压缩、图片压缩等功能是可以不开启的，并且在开发阶段，我们需要热更新。

2. 基于生产阶段 npm run build 的优化

而在生产打包阶段，尽管构建速度也非常重要，但是一些在开发时可有可无的功能必须加上，譬如代码压缩、图片压缩。因此，生产构建的目标是在于保证最终项目打包体积尽可能小，所需要的相关功能尽可能完善的前提下，同时保有较快的构建速度。

两者的目的不尽相同，因此一些构建优化手段可能仅在其中一个环节有效。

基于上述的一些分析，本文将从如下几个方面探讨对构建效率优化的探索：

1. 基于 Webpack 的一些常见传统优化方式
2. 分模块构建
3. 基于 Vite 的构建工具切换
4. 基于 Es-build 插件的构建效率优化

为什么这么慢？

那么，为什么随着项目的增大，构建的效率变得越来越慢了呢？

从上面两张截图不难看出，对于我们这样一个单页应用，构建过程中的大部分时间都消耗在编译 JavaScript 文件及 CSS 文件的各类 Loader 上。

本文不会详细描述 Webpack 的构建原理，我们只需要大致知道，Webpack 的构建流程，主要时间花费在递归遍历各个入口文件，并基于入口文件不断寻找依赖逐个编译再递归处理的过程，每次递归都需要经历 String->AST->String 的流程，然后通过不同的 loader 处理一些字符串或者执行一些 JavaScript 脚本，由于 NodeJS 单线程的特性以及语言本身的效率限制，Webpack 构建慢一直成为它饱受诟病的原因。

因此，基于上述 Webpack 构建的流程及提到的一些问题，整体的优化方向就变成了：

1. 缓存
2. 多进程
3. 寻路优化
4. 抽离拆分
5. 构建工具替换

基于 Webpack 的传统优化方式

上面也说了，构建过程中的大部分时间都消耗在递归地去编译 JavaScript 及 CSS 的各类 Loader 上，并且会受限于 NodeJS 单线程的特性以及语言本身的效率限制。

如果不替换掉 Webpack 本身，语言本身（NodeJS）的执行效率是没法优化的࿰