webpack效能優化不完全指北

秋秋秋丷發表於2018-09-09

前語--最近公司新開了一個專案，對webpack的效能上產生了不小需求，在一通學習了webpack之後特意寫一篇來總結一下。

本文涉及的內容

體積優化

依賴按需載入
剔除不必要的依賴

體積的大小直接關係到我們專案的載入速度，而SPA的首屏載入速度又決定了使用者的留存。對於體積優化，我們可以從倆個方面來下手。But 在那之前我們要先對自己的專案依賴構成進行分析，確定了優化的目標才能著手思考優化方案，進而實施優化方案。

對於專案bundle的分析，我們可以藉助 webpack-bundle-analyzer

食用方法：

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin

module.exports = {
    plugins: [
       new BundleAnalyzerPlugin()
    ]
}複製程式碼

我們只需要在每次打包的時候使用它，可以通過判斷NODE_ENV === 'production' 來選擇是否要開啟該外掛。同型別的外掛還有 webpack-analyse 和 webpack-chart，更炫酷（霧）一些不過額外要配置下。執行下面的命令生成分析工具需要的json檔案。

webpack --profile --json > stats.json

// 如果，執行指定的 weboack 檔案，可用此命令
webpack --config build/webpack.prod.conf.js  --profile --json > stats.json
複製程式碼

擒賊先擒王

有了依賴分析圖，我們就知道哪些模組是導致我們效能存在瓶頸的罪魁禍首，必不可缺的依賴我們可以考慮是否有按需載入的可能，沒有必要或者功能重複的依賴我們就可以將它剝離。

① 按需載入

一是將所使用的庫按需載入，比如一個UI庫小至100K，大至上MB。我們通常不會使用她所有的元件而是隻使用其中一部分，這時就可以將所使用的元件提取出來，而不打包沒有使用到的多餘元件。

在我們匯入元件庫的時候不使用--

這種引入方式會導致將整個元件庫都匯入進來，得不償失。

正確的食用方法--

在引入需要的元件時都只將該元件引入進來，而不使用解構。

but 這樣是不是特別麻煩，每次引入檔案都需要去對應的檔案下面匯入檔案。特別是通常元件庫都是我們通過npm下載下來的，都放在node_modules下面。非常不利於我們準確的找到需要的元件。so 我們可以使用 babel-plugin-import 來幫我們自動完成。這樣使用第一種引入方式也不會將所有的元件都匯入進來。

二是將程式碼分塊（chunk），實現程式碼層面上的按需載入--

使用webpack的Code splitting來實現，具體展開來講篇幅過長。直接 webpack的 Code splitting 實現按需載入。But 這是一種過時的方法-- 我們在webpack匯入對應的模組可以使用ES6+的import()。將程式碼動態拆分。 webpack動態匯入

Tips： Scope Hoisting

這個是webpack自帶的一個外掛，只需在配置檔案中新增一個新的外掛，就可以讓 Webpack 打包出來的程式碼檔案更小、執行的更快。但是經過我測試效果微乎其微，選裝。

webpack Scope Hoisting介紹

食用方法--

構建速度

首次編譯構建速度
熱過載構建速度（rebuild）

專案工程的構建速度決定我們能不能 happy coding，長足的構建速度也能加快我們的開發進度。在構建速度上主要分為倆個優化方面--

① 首次編譯構建速度

HappyPack加速構建

總所周知，JS是單執行緒的，而node在不展開cluster的情況下也是預設單執行緒的。單執行緒的優勢這裡不詳談，happypack可以讓 Webpack 能同一時間處理多個任務，發揮多核 CPU 電腦的威力，它把任務分解給多個子程式去併發的執行，子程式處理完後再把結果傳送給主程式。大大提升了編譯的速度.

食用方法--