資訊專欄INFORMATION COLUMN
摘要：使用要給項目構建接入動態鏈接庫的思想，需要完成以下事情把網頁依賴的基礎模塊抽離出來，打包到一個個多帶帶的動態鏈接庫中去。接入已經內置了對動態鏈接庫的支持，需要通過個內置的插件接入，它們分別是插件用于打包出一個個多帶帶的動態鏈接庫文件。
webpack優化
查看所有文檔頁面：全棧開發，獲取更多信息。優化開發體驗原文鏈接：webpack優化，原文廣告模態框遮擋，閱讀體驗不好，所以整理成本文，方便查找。
優化構建速度。在項目龐大時構建耗時可能會變的很長，每次等待構建的耗時加起來也會是個大數目。
縮小文件搜索范圍
使用 DllPlugin
使用 HappyPack
使用 ParallelUglifyPlugin
優化使用體驗。通過自動化手段完成一些重復的工作，讓我們專注于解決問題本身。
使用自動刷新
開啟模塊熱替換
優化輸出質量優化輸出質量的目的是為了給用戶呈現體驗更好的網頁，例如減少首屏加載時間、提升性能流暢度等。 這至關重要，因為在互聯網行業競爭日益激烈的今天，這可能關系到你的產品的生死。
優化輸出質量本質是優化構建輸出的要發布到線上的代碼，分為以下幾點：
減少用戶能感知到的加載時間，也就是首屏加載時間。
區分環境
壓縮代碼
CDN 加速
使用 Tree Shaking
提取公共代碼
按需加載
提升流暢度，也就是提升代碼性能。
使用 Prepack
開啟 Scope Hoisting
縮小文件搜索范圍Webpack 啟動后會從配置的 Entry 出發，解析出文件中的導入語句，再遞歸的解析。 在遇到導入語句時 Webpack 會做兩件事情：
根據導入語句去尋找對應的要導入的文件。例如 require("react") 導入語句對應的文件是 ./node_modules/react/react.js，require("./util") 對應的文件是 ./util.js。
根據找到的要導入文件的后綴，使用配置中的 Loader 去處理文件。例如使用 ES6 開發的 JavaScript 文件需要使用 babel-loader 去處理。
優化 loader 配置由于 Loader 對文件的轉換操作很耗時，需要讓盡可能少的文件被 Loader 處理。
在 Module 中介紹過在使用 Loader 時可以通過 test 、 include 、 exclude 三個配置項來命中 Loader 要應用規則的文件。 為了盡可能少的讓文件被 Loader 處理，可以通過 include 去命中只有哪些文件需要被處理。
以采用 ES6 的項目為例，在配置 babel-loader 時，可以這樣：
module.exports = {
module: {
rules: [
{
// 如果項目源碼中只有 js 文件就不要寫成 /.jsx?$/，提升正則表達式性能
test: /.js$/,
// babel-loader 支持緩存轉換出的結果，通過 cacheDirectory 選項開啟
use: ["babel-loader?cacheDirectory"],
// 只對項目根目錄下的 src 目錄中的文件采用 babel-loader
include: path.resolve(__dirname, "src"),
},
]
},
};
你可以適當的調整項目的目錄結構，以方便在配置 Loader 時通過 include 去縮小命中范圍。優化 resolve.modules 配置
在 Resolve 中介紹過 resolve.modules 用于配置 Webpack 去哪些目錄下尋找第三方模塊。
resolve.modules 的默認值是 ["node_modules"]，含義是先去當前目錄下的 ./node_modules 目錄下去找想找的模塊，如果沒找到就去上一級目錄 ../node_modules 中找，再沒有就去 ../../node_modules 中找，以此類推，這和 Node.js 的模塊尋找機制很相似。
當安裝的第三方模塊都放在項目根目錄下的 ./node_modules 目錄下時，沒有必要按照默認的方式去一層層的尋找，可以指明存放第三方模塊的絕對路徑，以減少尋找，配置如下：
module.exports = {
resolve: {
// 使用絕對路徑指明第三方模塊存放的位置，以減少搜索步驟
// 其中 __dirname 表示當前工作目錄，也就是項目根目錄
modules: [path.resolve(__dirname, "node_modules")]
},
};
優化 resolve.mainFields 配置
在 Resolve 中介紹過 resolve.mainFields 用于配置第三方模塊使用哪個入口文件。
安裝的第三方模塊中都會有一個 package.json 文件用于描述這個模塊的屬性，其中有些字段用于描述入口文件在哪里，resolve.mainFields 用于配置采用哪個字段作為入口文件的描述。
可以存在多個字段描述入口文件的原因是因為有些模塊可以同時用在多個環境中，準對不同的運行環境需要使用不同的代碼。 以 isomorphic-fetch 為例，它是 fetch API 的一個實現，但可同時用于瀏覽器和 Node.js 環境。 它的 package.json 中就有2個入口文件描述字段：
{
"browser": "fetch-npm-browserify.js",
"main": "fetch-npm-node.js"
}
isomorphic-fetch 在不同的運行環境下使用不同的代碼是因為 fetch API 的實現機制不一樣，在瀏覽器中通過原生的 fetch 或者 XMLHttpRequest 實現，在 Node.js 中通過 http 模塊實現。
resolve.mainFields 的默認值和當前的 target 配置有關系，對應關系如下：
當 target 為 web 或者 webworker 時，值是 ["browser", "module", "main"]
當 target 為其它情況時，值是 ["module", "main"]
以 target 等于 web 為例，Webpack 會先采用第三方模塊中的 browser 字段去尋找模塊的入口文件，如果不存在就采用 module 字段，以此類推。
為了減少搜索步驟，在你明確第三方模塊的入口文件描述字段時，你可以把它設置的盡量少。 由于大多數第三方模塊都采用 main 字段去描述入口文件的位置，可以這樣配置 Webpack：
module.exports = {
resolve: {
// 只采用 main 字段作為入口文件描述字段，以減少搜索步驟
mainFields: ["main"],
},
};
使用本方法優化時，你需要考慮到所有運行時依賴的第三方模塊的入口文件描述字段，就算有一個模塊搞錯了都可能會造成構建出的代碼無法正常運行。優化 resolve.alias 配置
resolve.alias 配置項通過別名來把原導入路徑映射成一個新的導入路徑。
在實戰項目中經常會依賴一些龐大的第三方模塊，以 React 庫為例，安裝到 node_modules 目錄下的 React 庫的目錄結構如下：
├── dist │ ├── react.js │ └── react.min.js ├── lib │ ... 還有幾十個文件被忽略 │ ├── LinkedStateMixin.js │ ├── createClass.js │ └── React.js ├── package.json └── react.js
可以看到發布出去的 React 庫中包含兩套代碼：
一套是采用 CommonJS 規范的模塊化代碼，這些文件都放在 lib 目錄下，以 package.json 中指定的入口文件 react.js 為模塊的入口。
一套是把 React 所有相關的代碼打包好的完整代碼放到一個多帶帶的文件中，這些代碼沒有采用模塊化可以直接執行。其中 dist/react.js 是用于開發環境，里面包含檢查和警告的代碼。dist/react.min.js 是用于線上環境，被最小化了。
默認情況下 Webpack 會從入口文件 ./node_modules/react/react.js 開始遞歸的解析和處理依賴的幾十個文件，這會時一個耗時的操作。 通過配置 resolve.alias 可以讓 Webpack 在處理 React 庫時，直接使用多帶帶完整的 react.min.js 文件，從而跳過耗時的遞歸解析操作。
相關 Webpack 配置如下：
module.exports = {
resolve: {
// 使用 alias 把導入 react 的語句換成直接使用多帶帶完整的 react.min.js 文件，
// 減少耗時的遞歸解析操作
alias: {
"react": path.resolve(__dirname, "./node_modules/react/dist/react.min.js"),
}
},
};
優化 resolve.extensions 配置除了 React 庫外，大多數庫發布到 Npm 倉庫中時都會包含打包好的完整文件，對于這些庫你也可以對它們配置 alias。
但是對于有些庫使用本優化方法后會影響到后面要講的使用 Tree-Shaking 去除無效代碼的優化，因為打包好的完整文件中有部分代碼你的項目可能永遠用不上。 一般對整體性比較強的庫采用本方法優化，因為完整文件中的代碼是一個整體，每一行都是不可或缺的。 但是對于一些工具類的庫，例如 lodash，你的項目可能只用到了其中幾個工具函數，你就不能使用本方法去優化，因為這會導致你的輸出代碼中包含很多永遠不會執行的代碼。
在導入語句沒帶文件后綴時，Webpack 會自動帶上后綴后去嘗試詢問文件是否存在。resolve.extensions 用于配置在嘗試過程中用到的后綴列表，默認是：
extensions: [".js", ".json"]
也就是說當遇到 require("./data") 這樣的導入語句時，Webpack 會先去尋找 ./data.js 文件，如果該文件不存在就去尋找 ./data.json 文件，如果還是找不到就報錯。
如果這個列表越長，或者正確的后綴在越后面，就會造成嘗試的次數越多，所以 resolve.extensions 的配置也會影響到構建的性能。 在配置 resolve.extensions 時你需要遵守以下幾點，以做到盡可能的優化構建性能：
后綴嘗試列表要盡可能的小，不要把項目中不可能存在的情況寫到后綴嘗試列表中。
頻率出現最高的文件后綴要優先放在最前面，以做到盡快的退出尋找過程。
在源碼中寫導入語句時，要盡可能的帶上后綴，從而可以避免尋找過程。例如在你確定的情況下把 require("./data") 寫成 require("./data.json")。
相關 Webpack 配置如下：
module.exports = {
resolve: {
// 盡可能的減少后綴嘗試的可能性
extensions: ["js"],
},
};
優化 module.noParse 配置
module.noParse 配置項可以讓 Webpack 忽略對部分沒采用模塊化的文件的遞歸解析處理，這樣做的好處是能提高構建性能。 原因是一些庫，例如 jQuery 、ChartJS， 它們龐大又沒有采用模塊化標準，讓 Webpack 去解析這些文件耗時又沒有意義。
在上面的 優化 resolve.alias 配置 中講到多帶帶完整的 react.min.js 文件就沒有采用模塊化，讓我們來通過配置 module.noParse 忽略對 react.min.js 文件的遞歸解析處理， 相關 Webpack 配置如下：
const path = require("path");
module.exports = {
module: {
// 獨完整的 `react.min.js` 文件就沒有采用模塊化，忽略對 `react.min.js` 文件的遞歸解析處理
noParse: [/react.min.js$/],
},
};
注意被忽略掉的文件里不應該包含 import 、 require 、 define 等模塊化語句，不然會導致構建出的代碼中包含無法在瀏覽器環境下執行的模塊化語句。
以上就是所有和縮小文件搜索范圍相關的構建性能優化了，在根據自己項目的需要去按照以上方法改造后，你的構建速度一定會有所提升。
使用 DllPlugin要給 Web 項目構建接入動態鏈接庫的思想，需要完成以下事情：
把網頁依賴的基礎模塊抽離出來，打包到一個個多帶帶的動態鏈接庫中去。一個動態鏈接庫中可以包含多個模塊。
當需要導入的模塊存在于某個動態鏈接庫中時，這個模塊不能被再次被打包，而是去動態鏈接庫中獲取。
當需要導入的模塊存在于某個動態鏈接庫中時，這個模塊不能被再次被打包，而是去動態鏈接庫中獲取。
為什么給 Web 項目構建接入動態鏈接庫的思想后，會大大提升構建速度呢？ 原因在于包含大量復用模塊的動態鏈接庫只需要編譯一次，在之后的構建過程中被動態鏈接庫包含的模塊將不會在重新編譯，而是直接使用動態鏈接庫中的代碼。 由于動態鏈接庫中大多數包含的是常用的第三方模塊，例如 react、react-dom，只要不升級這些模塊的版本，動態鏈接庫就不用重新編譯。
接入 WebpackWebpack 已經內置了對動態鏈接庫的支持，需要通過2個內置的插件接入，它們分別是：
DllPlugin 插件：用于打包出一個個多帶帶的動態鏈接庫文件。
DllReferencePlugin 插件：用于在主要配置文件中去引入 DllPlugin 插件打包好的動態鏈接庫文件。
下面以基本的 React 項目為例，為其接入 DllPlugin，在開始前先來看下最終構建出的目錄結構：
├── main.js ├── polyfill.dll.js ├── polyfill.manifest.json ├── react.dll.js └── react.manifest.json
其中包含兩個動態鏈接庫文件，分別是：
polyfill.dll.js 里面包含項目所有依賴的 polyfill，例如 Promise、fetch 等 API。
react.dll.js 里面包含 React 的基礎運行環境，也就是 react 和 react-dom 模塊。
以 react.dll.js 文件為例，其文件內容大致如下：
var _dll_react = (function(modules) {
// ... 此處省略 webpackBootstrap 函數代碼
}([
function(module, exports, __webpack_require__) {
// 模塊 ID 為 0 的模塊對應的代碼
},
function(module, exports, __webpack_require__) {
// 模塊 ID 為 1 的模塊對應的代碼
},
// ... 此處省略剩下的模塊對應的代碼
]));
可見一個動態鏈接庫文件中包含了大量模塊的代碼，這些模塊存放在一個數組里，用數組的索引號作為 ID。 并且還通過 _dll_react 變量把自己暴露在了全局中，也就是可以通過 window._dll_react 可以訪問到它里面包含的模塊。
其中 polyfill.manifest.json 和 react.manifest.json 文件也是由 DllPlugin 生成出，用于描述動態鏈接庫文件中包含哪些模塊， 以 react.manifest.json 文件為例，其文件內容大致如下：
See the Pen react.manifest.json by whjin (@whjin) on CodePen.