前端構建效率優化之路

項目背景

我們的系統（一個 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。

image

生產階段構建耗時

而對於 npm run build，也就是實際線上生產環境的構建，看看總體的耗時：

image

因此，對於構建效率的優化可謂是勢在必行。首先，我們需要明確，優化分為兩個方向：

  1. 基於開發階段 npm run serve 的優化

在開發階段，我們的核心目標是在保有項目所有功能的前提下，儘可能提高構建速度，保證開發時的效率，所以對於 Live 才需要的一些功能，譬如程式碼混淆壓縮、圖片壓縮等功能是可以不開啟的，並且在開發階段，我們需要熱更新。

  1. 基於生產階段 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）的執行效率是沒法優化的，只能在其他幾個點做文章。

因此在最早期，我們所做的都是一些比較常規的優化手段，這裡簡單介紹最為核心的幾個：

  1. 快取
  2. 多進程
  3. 定址優化

快取優化

其實對於 vue-cli 4 而言，已經內置了一些快取操作，譬如上圖可見到 loader 的過程中，有使用 cache-loader，所以我們並不需要再次添加到項目之中。

  • cache-loader: 在一些性能開銷較大的 loader 之前添加 cache-loader，以便將結果快取到磁碟里

那還有沒有一些其他的快取操作呢用上的呢？我們使用了一個 HardSourceWebpackPlugin 。

HardSourceWebpackPlugin

  • HardSourceWebpackPlugin: HardSourceWebpackPlugin 為模組提供中間快取，快取默認存放的路徑是 node_modules/.cache/hard-source，配置了 HardSourceWebpackPlugin 之後，首次構建時間並沒有太大的變化，但是第二次開始，構建時間將會大大的加快。

首先安裝依賴：

npm install hard-source-webpack-plugin -D

修改 vue.config.js 配置文件：

const HardSourceWebpackPlugin = require('hard-source-webpack-plugin');
module.exports = {
  ...
  configureWebpack: (config) => {
    // ...
    config.plugins.push(new HardSourceWebpackPlugin());
  },
  ...
}

配置了 HardSourceWebpackPlugin 的首次構建時間，和預期的一樣，並沒有太大的變化，但是第二次構建從平均 4min 左右降到了平均 20s 左右，提升的幅度非常的誇張，當然，這個也因項目而異，但是整體而言，在不同項目中實測發現它都能比較大的提升開發時二次編譯的效率。

設置 babel-loader 的 cacheDirectory 以及 DLL

另外，在快取方面我們的嘗試有：

  1. 設置 babel-loader 的 cacheDirectory
  2. DLL

但是整體收效都不太大，可以簡單講講。

打開 babel-loader 的 cacheDirectory 的配置，當有設置時，指定的目錄將用來快取 loader 的執行結果。之後的 webpack 構建，將會嘗試讀取快取，來避免在每次執行時，可能產生的、高性能消耗的 Babel 重新編譯過程。實際的操作步驟，你可以看看 Webpack – babel-loader。

那麼 DLL 又是什麼呢？

DLL 文件為動態鏈接庫，在一個動態鏈接庫中可以包含給其他模組調用的函數和數據。

為什麼要用 DLL？

原因在於包含大量復用模組的動態鏈接庫只需要編譯一次，在之後的構建過程中被動態鏈接庫包含的模組將不會在重新編譯，而是直接使用動態鏈接庫中的程式碼。

由於動態鏈接庫中大多數包含的是常用的第三方模組，例如 Vue、React、React-dom，只要不升級這些模組的版本，動態鏈接庫就不用重新編譯。

DLL 的配置非常繁瑣，並且最終收效甚微，我們在過程中藉助了 autodll-webpack-plugin，感興趣的可以自行嘗試。值得一提的是，Vue-cli 已經剔除了這個功能。

多進程

基於 NodeJS 單執行緒的特性，當有多個任務同時存在，它們也只能排隊串列執行。

而如今大多數 CPU 都是多核的，因此我們可以藉助一些工具，充分釋放 CPU 在多核並發方面的優勢，利用多核優勢，多進程同時處理任務。

從上圖中可以看到，Vue CLi4 中，其實已經內置了 thread-loader。

  • thread-loader: 把 thread-loader 放置在其它 loader 之前，那麼放置在這個 loader 之後的 loader 就會在一個單獨的 worker 池中運行。這樣做的好處是把原本需要串列執行的任務並行執行。

那麼，除了 thread-loader，還有哪些可以考慮的方案呢？

HappyPack

HappyPack 與 thread-loader 類似。

HappyPack 可利用多進程對文件進行打包, 將任務分解給多個子進程去並行執行，子進程處理完後，再把結果發送給主進程，達到並行打包的效果、HappyPack 並不是所有的 loader 都支援, 比如 vue-loader 就不支援。

可以通過 Loader Compatibility List 來查看支援的 loaders。需要注意的是，創建子進程和主進程之間的通訊是有開銷的，當你的 loader 很慢的時候，可以加上 happypack。否則，可能會編譯的更慢。

當然，由於 HappyPack 作者對 JavaScript 的興趣逐步丟失，維護變少，webpack4 及之後都更推薦使用 thread-loader。因此，這裡沒有實際結論給出。

上一次 HappyPack 更新已經是 3 年前

定址優化

對於定址優化，總體而言提升並不是很大。

它的核心即在於，合理設置 loader 的 exclude 和 include 屬性。

  • 通過配置 loader 的 exclude 選項，告訴對應的 loader 可以忽略某個目錄
  • 通過配置 loader 的 include 選項，告訴 loader 只需要處理指定的目錄，loader 處理的文件越少，執行速度就會更快

這肯定是有用的優化手段，只是對於一些大型項目而言，這類優化對整體構建時間的優化不會特別明顯。

分模組構建

在上述的一些常規優化完成後。整體效果仍舊不是特別明顯，因此，我們開始思考一些其它方向。

我們再來看看 Webpack 構建的整體流程：

上圖是大致的 webpack 構建流程，簡單介紹一下：

  1. entry-option：讀取 webpack 配置，調用 new Compile(config) 函數準備編譯
  2. run：開始編譯
  3. make：從入口開始分析依賴，對依賴模組進行 build
  4. before-resolve：對位置模組進行解析
  5. build-module：開始構建模組
  6. normal-module-loader：生成 AST 樹
  7. program：遍歷 AST 樹，遇到 require 語句收集依賴
  8. seal：build 完成開始優化
  9. emit：輸出 dist 目錄

隨著項目體量地不斷增大，耗時大頭消耗在第 7 步，遞歸遍歷 AST，解析 require，如此反覆直到遍歷完整個項目。

而有意思的是，對於單次單個開發而言，極大概率只是基於這整個大項目的某一小個模組進行開發即可。

所以，如果我們可以在收集依賴的時候，跳過我們本次不需要的模組，或者可以自行選擇，只構建必要的模組，那麼整體的構建時間就可以大大減少。

這也就是我們要做的 — 分模組構建。

什麼意思呢？舉個栗子，假設我們的項目一共有 6 個大的路由模組 A、B、C、D、E、F，當新需求只需要在 A 模組範圍內進行優化新增，那麼我們在開發階段啟動整個項目的時候，可以跳過 B、C、D、E、F 這 5 個模組，只構建 A 模組即可：

假設原本每個模組的構建平均耗時 3s，原本 18s 的整體冷啟動構建耗時就能下降到 3s。

分模組構建打包的原理

Webpack 是靜態編譯打包的，Webpack 在收集依賴時會去分析程式碼中的 require（import 會被 bebel 編譯成 require） 語句，然後遞歸的去收集依賴進行打包構建。

我們要做的，就是通過增加一些配置，簡單改造下我們的現有程式碼，使得 Webpack 在初始化遍歷整個路由模組收集依賴的時候，可以跳過我們不需要的模組。

再說得詳細點，假設我們的路由大致程式碼如下：

import Vue from 'vue';
import VueRouter, { Route } from 'vue-router';

// 1. 定義路由組件.
// 這裡簡化下模型，實際項目中肯定是一個一個的大路由模組，從其他文件導入
const moduleA = { template: '<div>AAAA</div>' }
const moduleB = { template: '<div>BBBB</div>' }
const moduleC = { template: '<div>CCCC</div>' }
const moduleD = { template: '<div>DDDD</div>' }
const moduleE = { template: '<div>EEEE</div>' }
const moduleF = { template: '<div>FFFF</div>' }

// 2. 定義一些路由
// 每個路由都需要映射到一個組件。
// 我們後面再討論嵌套路由。
const routesConfig = [
  { path: '/A', component: moduleA },
  { path: '/B', component: moduleB },
  { path: '/C', component: moduleC },
  { path: '/D', component: moduleD },
  { path: '/E', component: moduleE },
  { path: '/F', component: moduleF }
]

const router = new VueRouter({
  mode: 'history',
  routes: routesConfig,
});

// 讓路由生效 ...
const app = Vue.createApp({})
app.use(router)

我們要做的，就是每次啟動項目時，可以通過一個前置命令行腳本，收集本次需要啟動的模組，按需生成需要的 routesConfig 即可。

我們嘗試了：

  1. IgnorePlugin 插件
  2. webpack-virtual-modules 配合 require.context
  3. NormalModuleReplacementPlugin 插件進行文件替換

最終選擇了使用 NormalModuleReplacementPlugin 插件進行文件替換的方式，原因在於它對整個項目的侵入性非常小，只需要添加前置腳本及修改 Webpack 配置，無需改變任何路由文件程式碼。總結而言，該方案的兩點優勢在於：

  1. 無需改動上層程式碼
  2. 通過生成臨時路由文件的方式，替換原路由文件，對項目無任何影響

使用 NormalModuleReplacementPlugin 生成新的路由配置文件

利用 NormalModuleReplacementPlugin 插件，可以不修改原來的路由配置文件，在編譯階段根據配置生成一個新的路由配置文件然後去使用它，這樣做的好處在於對整個源碼沒有侵入性。

NormalModuleReplacementPlugin 插件的作用在於，將目標源文件的內容替換為我們自己的內容。

我們簡單修改 Webpack 配置，如果當前是開發環境，利用該插件，將原本的 config.ts 文件，替換為另外一份，程式碼如下：

// vue.config.js
if (process.env.NODE_ENV === 'development') {
  config.plugins.push(new webpack.NormalModuleReplacementPlugin(
      /src\/router\/config.ts/,
      '../../dev.routerConfig.ts'
    )
  )
}

上面的程式碼功能是將實際使用的 config.ts 替換為自定義配置的 dev.routerConfig.ts 文件，那麼 dev.routerConfig.ts 文件的內容又是如何產生的呢，其實就是藉助了 inquirer 與 EJS 模板引擎，通過一個互動式的命令行問答，選取需要的模組，基於選擇的內容，動態的生成新的 dev.routerConfig.ts 程式碼，這裡直接上程式碼。

改造一下我們的啟動腳本，在執行 vue-cli-service serve 前，先跑一段我們的前置腳本：

{
  // ...
  "scripts": {
    - "dev": "vue-cli-service serve",
    + "dev": "node ./script/dev-server.js && vue-cli-service serve",
  },
  // ...
}

而 dev-server.js 所需要做的事，就是通過 inquirer 實現一個互動式命令，用戶選擇本次需要啟動的模組列表，通過 ejs 生成一份新的 dev.routerConfig.ts 文件。

// dev-server.js
const ejs = require('ejs');
const fs = require('fs');
const child_process = require('child_process');
const inquirer = require('inquirer');
const path = require('path');

const moduleConfig = [
    'moduleA',
    'moduleB',
    'moduleC',
    // 實際業務中的所有模組
]

//選中的模組
const chooseModules = [
  'home'
]

function deelRouteName(name) {
  const index = name.search(/[A-Z]/g);
  const preRoute = '' + path.resolve(__dirname, '../src/router/modules/') + '/';
  if (![0, -1].includes(index)) {
    return preRoute + (name.slice(0, index) + '-' + name.slice(index)).toLowerCase();
  }
  return preRoute + name.toLowerCase();;
}

function init() {
  let entryDir = process.argv.slice(2);
  entryDir = [...new Set(entryDir)];
  if (entryDir && entryDir.length > 0) {
    for(const item of entryDir){
      if(moduleConfig.includes(item)){
        chooseModules.push(item);
      }
    }
    console.log('output: ', chooseModules);
    runDEV();
  } else {
    promptModule();
  }
}

const getContenTemplate = async () => {
  const html = await ejs.renderFile(path.resolve(__dirname, 'router.config.template.ejs'), { chooseModules, deelRouteName }, {async: true});
  fs.writeFileSync(path.resolve(__dirname, '../dev.routerConfig.ts'), html);
};

function promptModule() {
  inquirer.prompt({
    type: 'checkbox',
    name: 'modules',
    message: '請選擇啟動的模組, 點擊上下鍵選擇, 按空格鍵確認(可以多選), 回車運行。注意: 直接敲擊回車會全量編譯, 速度較慢。',
    pageSize: 15,
    choices: moduleConfig.map((item) => {
      return {
        name: item,
        value: item,
      }
    })
  }).then((answers) => {
    if(answers.modules.length===0){
      chooseModules.push(...moduleConfig)
    }else{
      chooseModules.push(...answers.modules)
    }
    runDEV();
  });
}

init();

模板程式碼的簡單示意：

// 模板程式碼示意，router.config.template.ejs
import { RouteConfig } from 'vue-router';

<% chooseModules.forEach(function(item){%>
import <%=item %> from '<%=deelRouteName(item) %>';
<% }) %>
let routesConfig: Array<RouteConfig> = [];
/* eslint-disable */
  routesConfig = [
    <% chooseModules.forEach(function(item){%>
      <%=item %>,
    <% }) %>
  ]

export default routesConfig;

dev-server.js 的核心在於啟動一個 inquirer 交互命令行服務，讓用戶選擇需要構建的模組，類似於這樣：

模板程式碼示意 router.config.template.ejs 是 EJS 模板文件，chooseModules 是我們在終端輸入時，獲取到的用戶選擇的模組集合數組，根據這個列表，我們去生成新的 routesConfig 文件。

這樣，我們就實現了分模組構建，按需進行依賴收集。以我們的項目為例，我們的整個項目大概有 20 個不同的模組，幾十萬行程式碼：

構建模組數 耗時
冷啟動全量構建 20 個模組 4.5MIN
冷啟動只構建 1 個模組 18s
有快取狀態下二次構建 1 個模組 4.5s

實際效果大致如下，無需啟動所有模組，只啟動我們選中的模組進行對應的開發即可：

這樣，如果單次開發只涉及固定的模組，單次項目冷啟動的時間，可以從原本的 4min+ 下降到 18s 左右，而有快取狀態下二次構建 1 個模組，僅僅需要 4.5s，屬於一個比較大的提升。

受限於 Webpack 所使用的語言的性能瓶頸，要追求更快的構建性能，我們不可避免的需要把目光放在其他構建工具上。這裡，我們的目光聚焦在了 Vite 與 esbuild 上。

使用 Vite 優化開發時構建

Vite，一個基於瀏覽器原生 ES 模組的開發伺服器。利用瀏覽器去解析 imports，在伺服器端按需編譯返回，完全跳過了打包這個概念，伺服器隨起隨用。同時不僅有 Vue 文件支援，還搞定了熱更新，而且熱更新的速度不會隨著模組增多而變慢。

當然，由於 Vite 本身特性的限制，目前只適用於在開發階段替代 Webpack。

我們都知道 Vite 非常快，它主要快在什麼地方？

  1. 項目冷啟動更快
  2. 熱更新更快

那麼是什麼讓它這麼快？

Webpack 與 Vite 冷啟動的區別

我們先來看看 Webpack 與 Vite 的在構建上的區別。下圖是 Webpack 的遍歷遞歸收集依賴的過程：

上文我們也講了，Webpack 啟動時，從入口文件出發，調用所有配置的 Loader 對模組進行編譯，再找出該模組依賴的模組，再遞歸本步驟直到所有入口依賴的文件都經過了本步驟的處理。

這一過程是非常非常耗時的，再看看 Vite：

Vite 通過在一開始將應用中的模組區分為 依賴 和 源碼 兩類，改進了開發伺服器啟動時間。它快的核心在於兩點：

  1. 使用 Go 語言的依賴預構建：Vite 將會使用 esbuild 進行預構建依賴。esbuild 使用 Go 編寫，並且比以 JavaScript 編寫的打包器預構建依賴快 10-100 倍。依賴預構建主要做了什麼呢？

    • 開發階段中，Vite 的開發伺服器將所有程式碼視為原生 ES 模組。因此，Vite 必須先將作為 CommonJS 或 UMD 發布的依賴項轉換為 ESM
    • Vite 將有許多內部模組的 ESM 依賴關係轉換為單個模組，以提高後續頁面載入性能。如果不編譯，每個依賴包裡面都可能含有多個其他的依賴，每個引入的依賴都會又一個請求，請求多了耗時就多

  2. 按需編譯返回：Vite 以 原生 ESM 方式提供源碼。這實際上是讓瀏覽器接管了打包程式的部分工作：Vite 只需要在瀏覽器請求源碼時進行轉換並按需提供源碼。根據情景動態導入程式碼，即只在當前螢幕上實際使用時才會被處理。

Webpack 與 Vite 熱更新的區別

使用 Vite 的另外一個大的好處在於，它的熱更新也是非常迅速的。

我們首先來看看 Webpack 的熱更新機制：

一些名詞解釋：

  • Webpack-complier：Webpack 的編譯器，將 Javascript 編譯成 bundle（就是最終的輸出文件）
  • HMR Server：將熱更新的文件輸出給 HMR Runtime
  • Bunble Server：提供文件在瀏覽器的訪問，也就是我們平時能夠正常通過 localhost 訪問我們本地網站的原因
  • HMR Runtime：開啟了熱更新的話，在打包階段會被注入到瀏覽器中的 bundle.js，這樣 bundle.js 就可以跟伺服器建立連接，通常是使用 Websocket ，當收到伺服器的更新指令的時候，就去更新文件的變化
  • bundle.js：構建輸出的文件

Webpack 熱更新的大致原理是，文件經過 Webpack-complier 編譯好後傳輸給 HMR Server，HMR Server 知道哪個資源 (模組) 發生了改變，並通知 HMR Runtime 有哪些變化，HMR Runtime 就會更新我們的程式碼，這樣瀏覽器就會更新並且不需要刷新。

而 Webpack 熱更新機制主要耗時點在於，Webpack 的熱更新會以當前修改的文件為入口重新 build 打包，所有涉及到的依賴也都會被重新載入一次。

而 Vite 號稱 熱更新的速度不會隨著模組增多而變慢。它的主要優化點在哪呢？

Vite 實現熱更新的方式與 Webpack 大同小異，也通過創建 WebSocket 建立瀏覽器與伺服器建立通訊，通過監聽文件的改變向客戶端發出消息，客戶端對應不同的文件進行不同的操作的更新。

Vite 通過 chokidar 來監聽文件系統的變更，只用對發生變更的模組重新載入，只需要精確的使相關模組與其臨近的 HMR 邊界連接失效即可，這樣 HMR 更新速度就不會因為應用體積的增加而變慢而 Webpack 還要經歷一次打包構建。所以 HMR 場景下，Vite 表現也要好於 Webpack。

通過不同的消息觸發一些事件。做到瀏覽器端的即時熱模組更換（熱更新）。通過不同事件，觸發更細粒度的更新（目前只有 Vue 和 JS，Vue 文件又包含了 template、script、style 的改動），做到只更新必須的文件，而不是全量進行更新。在些事件分別是：

  • connected: WebSocket 連接成功
  • vue-reload: Vue 組件重新載入（當修改了 script 里的內容時）
  • vue-rerender: Vue 組件重新渲染（當修改了 template 里的內容時）
  • style-update: 樣式更新
  • style-remove: 樣式移除
  • js-update: js 文件更新
  • full-reload: fallback 機制，網頁重刷新

本文不會在 Vite 原理上做太多深入，感興趣的可以通過官方文檔了解更多 — Vite 官方文檔 — 為什麼選 Vite

基於 Vite 的改造，相當於在開發階段替換掉 Webpack，下文主要講講我們在替換過程中遇到的一些問題。

基於 Vue-cli 4 的 Vue2 項目改造，大致只需要：

  1. 安裝 Vite
  2. 配置 index.html（Vite 解析 <script type="module" src="..."> 標籤指向源碼）
  3. 配置 vite.config.js
  4. package.json 的 scripts 模組下增加啟動命令 "vite": "vite"

當以命令行方式運行 npm run vite時，Vite 會自動解析項目根目錄下名為 vite.config.js 的文件，讀取相應配置。而對於 vite.config.js 的配置，整體而言比較簡單：

  1. Vite 提供了對 .scss, .sass, .less, 和 .stylus 文件的內置支援
  2. 天然的對 TS 的支援，開箱即用
  3. 基於 Vue2 的項目支援，可能不同的項目會遇到不同的問題，根據報錯逐步調試即可，譬如通過一些官方插件兼容 .tsx、.jsx

當然，對於項目的源碼，可能需要一定的改造，下面是我們遇到的一些小問題：

  1. tsx 中使用裝飾器導致的編譯問題，我們通過魔改了 @vitejs/plugin-vue-jsx，使其支援 Vue2 下的 jsx
  2. 由於 Vite 僅支援 ESM 語法，需要將程式碼中的模組引入方式由 require 改為 import
  3. Sass 預處理器無法正確解析樣式中的 /deep/，可使用 ::v-deep 替換
  4. 其他一些小問題，譬如 Webpack 環境變數的兼容，SVG iCON 的兼容

對於需要修改到源碼的地方，我們的做法是既保證能讓 Vite 進行適配，同時讓該改動不會影響到原本 Webpack 的構建，以便在關鍵時刻或者後續迭代能切回 Webpack

解決完上述的一些問題後，我們成功地將開發時基於 Webpack 的構建打包遷移到了 Vite，效果也非常驚人，全模組構建耗時只有 2.6s：

至此，開發階段的構建耗時從原本的 4.5min 優化到了 2.6s:

構建模組數 耗時
Webpack 冷啟動全量構建 20 個模組 4.5MIN
Webpack 冷啟動只構建 1 個模組 18s
Webpack 有快取狀態下二次構建 1 個模組 4.5s
Vite 冷啟動 2.6s

優化生產構建

好，上述我們基本已經完成了整個開發階段的構建優化。下一步是優化生產構建。

我們的生產發布是基於 GitLab 及 Jenkins 的完整 CI/CD 流。

在優化之前，看看我們的整個項目線上發布的耗時：

可以看到，生產環境構建時間較長， build 平均耗時約 9 分鐘，整體發布構建時長在 15 分鐘左右，整體構建環節耗時過長， 效率低下，嚴重影響測試以及回滾 。

好，那我們看看，整個構建流程，都需要做什麼事情：

其中， Build base 和 Build Region 階段存在較大優化空間。

Build base 階段的優化，涉及到環境準備，鏡像拉取，依賴的安裝。前端能發揮的空間不大，這一塊主要和 SRE 團隊溝通，共同進行優化，可以做的有增加快取處理、外掛文件系統、將依賴寫進容器等方式。

我們的優化，主要關注 Build Region 階段，也就是核心關注如何減少 npm run build 的時間。

文章開頭有貼過 npm run build 的耗時分析，簡單再貼下：

image

一般而言， 程式碼編譯時間和程式碼規模正相關。

根據以往優化經驗，程式碼靜態檢查可能會佔據比較多時間，目光鎖定在 eslint-loader 上。

在生產構建階段，eslint 提示資訊價值不大，考慮在 build 階段去除，步驟前置。

同時，我們了解到，可以通過 esbuild-loader 插件去替代非常耗時的 babel-loader、ts-loader 等 loader。

因此，我們的整體優化方向就是：

  1. 改寫打包腳本，引入 esbuild 插件
  2. 優化構架邏輯，減少 build 階段不必要的檢查

優化前後流程對比：

優化構架邏輯，減少 build 階段不必要的檢查

這個上面說了，還是比較好理解的，在生產構建階段，eslint 提示資訊價值不大，考慮在 build 階段去除，步驟前置。

比如在 git commit 的時候利用 lint-staged 及 git hook 做檢查， 或者利用 CI 在 git merge 的時候加一條流水線任務，專門做靜態檢查。

我們兩種方式都有做，簡單給出接入 Gitlab CI 的程式碼：

// .gitlab-ci.yml
stages:
  - eslint

eslint-job:
  image: node:14.13.0
  stage: eslint
  script:
    - npm run lint 
    - echo 'eslint success'
  retry: 1
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "test"'

通過 .gitlab-ci.yml 配置文件，指定固定的時機進行 lint 指令，前置步驟。

改寫打包腳本，引入 esbuild 插件

這裡，我們主要藉助了 esbuild-loader。

上面其實我們也有提到 esbuild，Vite 使用 esbuild 進行預構建依賴。這裡我們藉助的是 esbuild-loader，它把 esbuild 的能力包裝成 Webpack 的 loader 來實現 Javascript、TypeScript、CSS 等資源的編譯。以及提供更快的資源壓縮方案。

接入起來也非常簡單。我們的項目是基於 Vue CLi 的，主要修改 vue.config.js，改造如下：

// vue.config.js
const { ESBuildMinifyPlugin } = require('esbuild-loader');

module.exports = {
  // ...

  chainWebpack: (config) => {
    // 使用 esbuild 編譯 js 文件
    const rule = config.module.rule('js');

    // 清理自帶的 babel-loader
    rule.uses.clear();

    // 添加 esbuild-loader
    rule
      .use('esbuild-loader')
      .loader('esbuild-loader')
      .options({
        loader: 'ts', // 如果使用了 ts, 或者 vue 的 class 裝飾器，則需要加上這個 option 配置， 否則會報錯： ERROR: Unexpected "@"
        target: 'es2015',
        tsconfigRaw: require('./tsconfig.json')
      })

    // 刪除底層 terser, 換用 esbuild-minimize-plugin
    config.optimization.minimizers.delete('terser');

    // 使用 esbuild 優化 css 壓縮
    config.optimization
      .minimizer('esbuild')
      .use(ESBuildMinifyPlugin, [{ minify: true, css: true }]);
  }
}

移除 ESLint，以及接入 esbuild-loader 這一番組合拳打完，本地單次構建可以優化到 90 秒。

階段 耗時
優化前 200s
移除 ESLint、接入 esbuild-loader 90s

再看看線上的 Jenkins 構建耗時，也有了一個非常明顯的提升：

前端工程化的演進及後續規劃

整體而言，上述優化完成後，對整個項目的打包構建效率是有著一個比較大的提升的，但是這並非已經做到了最好。

看看我們旁邊兄弟組的 Live 構建耗時：

在項目體量差不多的情況下，他們的生產構建耗時（npm run build）在 2 分鐘出頭，細究其原因在於：

  1. 他們的項目是 React + TSX，我這次優化的項目是 Vue，在文件的處理上就需要多過一層 vue-loader；
  2. 他們的項目採用了微前端，對項目對了拆分，主項目只需要載入基座相關的程式碼，子應用各自構建。需要構建的主應用程式碼量大大減少，這是主要原因；

是的，後續我們還有許多可以嘗試的方向，譬如我們正在做的一些嘗試有：

  1. 對項目進行微前端拆分，將相對獨立的模組拆解出來，做到獨立部署
  2. 基於 Jenkinks 構建時，在 Build Base 階段優化的提升，譬如將構建流程前置，結合 CDN 做快速回滾，以及將依賴預置進 Docker 容器中，減少在容器中每次 npm install 時間的消耗等

同時，我們也必須看到，前端技術日新月異，各種構建工具目不暇給。前端從最早期的刀耕火種，到逐步向工程化邁進，到如今的泛前端工程化囊括的各式各樣的標準、規範、各種提效的工具。構建效率優化可能會處於一種一直在路上的狀態。當然，這裡不一定有最佳實踐，只有最適合我們項目的實踐，需要我們不斷地去摸索嘗試。

最後

本文到此結束，希望對你有幫助 😃

如果還有什麼疑問或者建議，可以多多交流，原創文章，文筆有限，才疏學淺，文中若有不正之處，萬望告知。

Tags:

VirMach 便宜 VPS

QNews

QNews