摘要：例如允許我們?cè)诖虬鼤r(shí)將腳本分塊利用瀏覽器緩存我們能夠有的放矢的加載資源。文章的內(nèi)容大體分為兩個(gè)方面，一方面在思路制定模塊分離的策略，另一方面從技術(shù)上對(duì)方案進(jìn)行落地。我之前提到測(cè)試之下是什么樣具體的場(chǎng)景并不重要。

隨著前端代碼需要處理的業(yè)務(wù)越來(lái)越繁重，我們不得不面臨的一個(gè)問(wèn)題是前端的代碼體積也變得越來(lái)越龐大。這造成無(wú)論是在調(diào)式還是在上線(xiàn)時(shí)都需要花長(zhǎng)時(shí)間等待編譯完成，并且用戶(hù)也不得不花額外的時(shí)間和帶寬下載更大體積的腳本文件。

然而仔細(xì)想想這完全是可以避免的：在開(kāi)發(fā)時(shí)難道一行代碼的修改也要重新打包整個(gè)腳本？用戶(hù)只是粗略瀏覽頁(yè)面也需要將整個(gè)站點(diǎn)的腳本全部下載下來(lái)？所以趨勢(shì)必然是按需的、有策略性的將代碼拆分和提供給用戶(hù)。最近流行的微前端某種意義上來(lái)說(shuō)也是遵循了這樣的原則（但也并不是完全基于這樣的原因）

幸運(yùn)的是，我們目前已有的工具已經(jīng)完全賦予我們實(shí)現(xiàn)以上需求的能力。例如 Webpack 允許我們?cè)诖虬鼤r(shí)將腳本分塊；利用瀏覽器緩存我們能夠有的放矢的加載資源。

在探尋最佳實(shí)踐的過(guò)程中，最讓我疑惑的不是我們能不能做，而是我們應(yīng)該如何做：我們因該采取什么樣的特征拆分腳本？我們應(yīng)該使用什么樣的緩存策略？使用懶加載和分塊是否有異曲同工之妙？拆分之后究竟能帶來(lái)多大的性能提升？最重要的是，在面多諸多的方案和工具以及不確定的因素時(shí)，我們應(yīng)該如何開(kāi)始？這篇文章就是對(duì)以上問(wèn)題的梳理和回答。文章的內(nèi)容大體分為兩個(gè)方面，一方面在思路制定模塊分離的策略，另一方面從技術(shù)上對(duì)方案進(jìn)行落地。

本文的主要內(nèi)容翻譯自 The 100% correct way to split your chunks with Webpack。 這篇文章循序漸進(jìn)的引導(dǎo)開(kāi)發(fā)者步步為營(yíng)的對(duì)代碼進(jìn)行拆分優(yōu)化，所以它是作為本文的線(xiàn)索存在。同時(shí)在它的基礎(chǔ)上，我會(huì)對(duì) Webpack 及其他的知識(shí)點(diǎn)做縱向擴(kuò)展，對(duì)方案進(jìn)行落地。

以下開(kāi)始正文

現(xiàn)在讓我們把目光轉(zhuǎn)向 Alice 一遍又一遍下載的 main.js 文件

我之前提到過(guò)我們的站點(diǎn)里又兩個(gè)完全不同的部分：一個(gè)產(chǎn)品列表頁(yè)面和一個(gè)詳情頁(yè)面。每個(gè)頁(yè)面獨(dú)立的代碼提及大概是 25KB（共享 150KB 的代碼）

我們的“產(chǎn)品詳情”頁(yè)面目前不會(huì)進(jìn)行更改，因?yàn)樗浅５耐昝?。所以如果我們把它劃分為?dú)立文件，大部分時(shí)候它都能夠從緩存中進(jìn)行加載

你知道我們還有一個(gè)用于渲染 icon 用的 25KB 的幾乎不發(fā)生修改的 SVG 文件嗎？我們應(yīng)該對(duì)它做些什么

我們手動(dòng)的增加一些 entry 入口，告訴 Webpack 給它們都創(chuàng)建獨(dú)立的文件：

module.exports = {
  entry: {
    main: path.resolve(__dirname, "src/index.js"),
    ProductList: path.resolve(__dirname, "src/ProductList/ProductList.js"),
    ProductPage: path.resolve(__dirname, "src/ProductPage/ProductPage.js"),
    Icon: path.resolve(__dirname, "src/Icon/Icon.js"),
  },
  output: {
    path: path.resolve(__dirname, "dist"),
    filename: "[name].[contenthash:8].js",
  },
  plugins: [
    new webpack.HashedModuleIdsPlugin(), // so that file hashes don"t change unexpectedly
  ],
  optimization: {
    runtimeChunk: "single",
    splitChunks: {
      chunks: "all",
      maxInitialRequests: Infinity,
      minSize: 0,
      cacheGroups: {
        vendor: {
          test: /[/]node_modules[/]/,
          name(module) {
            // get the name. E.g. node_modules/packageName/not/this/part.js
            // or node_modules/packageName
            const packageName = module.context.match(/[/]node_modules[/](.*");)[1];

            // npm package names are URL-safe, but some servers don"t like @ symbols
            return `npm.${packageName.replace("@", "")}`;
          },
        },
      },
    },
  },
};

并且 Webpack 自動(dòng)為它們之間的共享代碼也創(chuàng)建了獨(dú)立的文件，也就是說(shuō)ProductList和ProductPage不會(huì)擁有重復(fù)的代碼

這回 Alice 在大多數(shù)周里都會(huì)節(jié)省下 50KB 的下載量

只有 1.815MB 了

我們已經(jīng)為 Alice 節(jié)省了 56% 的下載量，并且會(huì)持續(xù)下去（在我們的理論場(chǎng)景中）

所有這些都是通過(guò)修改 Webapck 配置實(shí)現(xiàn)的——我們還沒(méi)有修改任何一行應(yīng)用程序的代碼。

我之前提到測(cè)試之下是什么樣具體的場(chǎng)景并不重要。因?yàn)闊o(wú)論你遇見(jiàn)的是什么場(chǎng)景，結(jié)論始終是一致的：把你的代碼劃分為更多更有意義的小文件，用戶(hù)需要下載的代碼也就越少

很快我們就將談到“代碼分離”——另一種分割文件的方式——但是首先我想首先解決你現(xiàn)在正在考慮的問(wèn)題

答案非常明確是否定的

在 HTTP/1.1 的情況下確實(shí)會(huì)如此，但是在 HTTP/2 中不會(huì)

盡管如此，這篇來(lái)自 2016 年的文章和來(lái)自于Khan Academy 2015 年的文章都得出結(jié)論說(shuō)即使有 HTTP/2 下載太多文件的話(huà)仍然會(huì)導(dǎo)致變慢。但是在這兩篇文章里“太多”意味著上百個(gè)文件。所以只要記住如果你有上百個(gè)文件，你或許達(dá)到了并行的上限

如果你在好奇如何在 Windows 10 的 IE11 上支持 HTTP/2。我對(duì)那些還在使用古董機(jī)器的人做了調(diào)查，他們出奇一致的讓我放心他們根本不關(guān)心網(wǎng)站的加載速度

有的

但什么是“模板代碼”？

想象一下如果整個(gè)項(xiàng)目只有文件app.js，那么最終的輸出的打包文件也只是app.js的文件內(nèi)容而已。

但是如果app.js文件內(nèi)容是空的話(huà)（一行代碼都沒(méi)有），那么最終的打包文件也是空的嗎？

不是，Webpack 為了實(shí)現(xiàn)編譯之后的模塊化，它會(huì)將你的代碼進(jìn)行一次封裝，這些用于封裝的代碼會(huì)占用一部分體積，是每個(gè)模塊都必須存在的，所以成為模板代碼

是的

事實(shí)確實(shí)是：

多文件 = 多 Webpack 模板代碼

多文件 = 壓縮減小

讓我們把其中的損耗的都明確下來(lái)

我剛剛做了一個(gè)測(cè)試，一個(gè) 190 KB 的站點(diǎn)文件被劃分為了19個(gè)文件，發(fā)送給瀏覽器的字節(jié)數(shù)大概多了 2%

所以……首次訪(fǎng)問(wèn)的文件提及增加了 2% 但是直到世界末日其他的每次訪(fǎng)問(wèn)文件體積都減小了 60%

所以損耗的正確數(shù)字是：一點(diǎn)都不。

當(dāng)我在測(cè)試 1 個(gè)文件對(duì)比 19 個(gè)文件情況時(shí)，我想我應(yīng)該賦予測(cè)試一些不同的網(wǎng)絡(luò)環(huán)境，包括 HTTP/1.1

下面這張表格給予了“文件越多越好”的有力支持

在 3G 和 4G 的情況下當(dāng)有19個(gè)文件時(shí)加載時(shí)間減少了 30%

但真的是這樣嗎？

這份數(shù)據(jù)看上去“噪點(diǎn)”很多，舉個(gè)例子，在 4G 場(chǎng)景下第二次運(yùn)行時(shí)，網(wǎng)站加載花費(fèi)了 646ms，但是之后的第二輪運(yùn)行則花費(fèi)了 1116ms——時(shí)間增加了73% 。所以宣稱(chēng) HTTP/2 快了 30% 有一些心虛

我創(chuàng)建這張表格是為了試圖量化 HTTP/2 究竟能帶來(lái)多大的差異，但是我唯一能說(shuō)的是“并沒(méi)有太大的區(qū)別”

真正令人驚喜的是最后兩行，舊版本的 Windows 和 HTTP/1.1 我本以為會(huì)慢非常多。我猜我需要更慢的網(wǎng)絡(luò)環(huán)境用于進(jìn)行驗(yàn)證

故事時(shí)間！我從微軟網(wǎng)站下載了一個(gè) Windows 7 的虛擬機(jī)來(lái)測(cè)試這些東西

我想把默認(rèn)的 IE8 升級(jí)至 IE9

所以我前往微軟下載 IE9 的頁(yè)面然后發(fā)現(xiàn)：

最后提一句 HTTP/2，你知道它已經(jīng)集成進(jìn) Node 中了嗎？如果你想嘗試，我用100行寫(xiě)了一段 HTTP/2 服務(wù)，能夠?yàn)槟愕臏y(cè)試帶來(lái)緩存上的幫助

以上就是我想說(shuō)的關(guān)于打包分離的一切。我想這個(gè)實(shí)踐唯一的壞處是需要說(shuō)服人們加載如此多的小文件是沒(méi)有問(wèn)題的

這個(gè)特殊的實(shí)踐只對(duì)某些站點(diǎn)有效

我樂(lè)意重申一下我發(fā)明的 20/20 理論：如果站點(diǎn)的某些部分只有 20% 用戶(hù)會(huì)訪(fǎng)問(wèn)，并且這部分的腳本量大于你整個(gè)站點(diǎn)的 20% 的話(huà)，你就應(yīng)該考慮按需加載代碼了

你可以對(duì)數(shù)值進(jìn)行調(diào)整來(lái)適配更復(fù)雜的場(chǎng)景。重點(diǎn)是保持平衡，需要決策將對(duì)站點(diǎn)無(wú)意義的代碼分離出來(lái)

假設(shè)你有擁有一個(gè)購(gòu)物網(wǎng)站，你在糾結(jié)是否應(yīng)該把“結(jié)賬”功能的代碼分離出來(lái)，因?yàn)橹挥?30% 的用戶(hù)會(huì)走到那一步

首先是要讓賣(mài)的更好

其次計(jì)算出“結(jié)賬”功能的獨(dú)立代碼有多少。因?yàn)樵谧觥按a分離”之前你常常做“打包文件分離”，你或許已經(jīng)知道了這部分代碼量有多少

（它可能比你想象的還要小，所以計(jì)算之后你可能獲得驚喜。如果你有一個(gè) React 站點(diǎn)，你的 store，reducer，routing，actions 可能會(huì)被整個(gè)網(wǎng)站共享，獨(dú)立的部分可能大部分是組件和幫助類(lèi)庫(kù)）

假設(shè)你注意到結(jié)算頁(yè)面獨(dú)立代碼一共只有 7KB，其他部分的代碼 300KB?？吹竭@種情況我會(huì)建議不把這些代碼分開(kāi)，有以下幾個(gè)原因

它并不會(huì)讓加載變得更慢。記得你之前并行的加載這些文件，你可以試著記錄加載 300KB 和 307KB 的文件是否有變化

如果你延遲加載這部分代碼，用戶(hù)在點(diǎn)擊“付款”之后仍然需要等待文件的加載——你并不希望在這關(guān)鍵時(shí)刻給用戶(hù)帶來(lái)任何的阻力

代碼分離會(huì)導(dǎo)致程序代碼的更改，這需要將之前同步邏輯的地方改為異步邏輯。這并不復(fù)雜，但是對(duì)于改善用戶(hù)體驗(yàn)這件事的性?xún)r(jià)比來(lái)說(shuō)還是過(guò)于復(fù)雜了

這些就是我說(shuō)的“這項(xiàng)令人振奮的技術(shù)或許不適合你”

讓我們看看兩個(gè)代碼分離的例子

我們從這個(gè)例子開(kāi)始是因?yàn)樗m用于大多數(shù)站點(diǎn)，并且是一個(gè)非常好的入門(mén)

我給我的站點(diǎn)使用了一堆酷炫的功，所以我使用了一個(gè)文件導(dǎo)入了我需要的所有回滾方案。它只需要八行代碼：

require("whatwg-fetch");
require("intl");
require("url-polyfill");
require("core-js/web/dom-collections");
require("core-js/es6/map");
require("core-js/es6/string");
require("core-js/es6/array");
require("core-js/es6/object");

我在我的入口文件index.js頂部引入了這個(gè)文件

import "./polyfills";
import React from "react";
import ReactDOM from "react-dom";
import App from "./App/App";
import "./index.css";

const render = () => {
  ReactDOM.render(<App />, document.getElementById("root"));
}

render(); // yes I am pointless, for now

在 Webpack 配置關(guān)于打包分離的小節(jié)配置中，我的回滾代碼會(huì)自動(dòng)被分為四個(gè)不同的文件因?yàn)橛兴膫€(gè) npm 包。它們一共大小 25KB 左右，并且 90% 的瀏覽器都不需要它們，所以它們值得動(dòng)態(tài)的進(jìn)行加載。

在 Webpack 4 以及 import() 語(yǔ)法（不要和import語(yǔ)法混淆了）的支持下，有條件的加載回滾代碼變得非常簡(jiǎn)單了

import React from "react";
import ReactDOM from "react-dom";
import App from "./App/App";
import "./index.css";

const render = () => {
  ReactDOM.render(<App />, document.getElementById("root"));
}

if (
  "fetch" in window &&
  "Intl" in window &&
  "URL" in window &&
  "Map" in window &&
  "forEach" in NodeList.prototype &&
  "startsWith" in String.prototype &&
  "endsWith" in String.prototype &&
  "includes" in String.prototype &&
  "includes" in Array.prototype &&
  "assign" in Object &&
  "entries" in Object &&
  "keys" in Object
) {
  render();
} else {
  import("./polyfills").then(render);
}

現(xiàn)在是不是更有意義了？如果瀏覽器支持所有的新特性，那么渲染頁(yè)面。否則加載回滾代碼渲染頁(yè)面。當(dāng)代碼在運(yùn)行在瀏覽器中時(shí)，Webpack 的運(yùn)行時(shí)會(huì)負(fù)責(zé)這四個(gè)包的加載，并且當(dāng)它們被下載并且解析完畢時(shí)，render()函數(shù)才會(huì)被調(diào)用，并且其它工作繼續(xù)運(yùn)行

（順便說(shuō)一聲，如果需要使用import()的話(huà)，你需要 Babel 的 dynamic-import 插件 。并且如 Webpack 文檔解釋的，import()使用 Promises，所以你需要把這部分的回滾代碼獨(dú)立出來(lái)）

非常簡(jiǎn)單不是嗎？

有一些更棘手的場(chǎng)景

回到 Alice 的例子，假設(shè)網(wǎng)站現(xiàn)在多了一個(gè)“管理”頁(yè)面，產(chǎn)品的賣(mài)家可以登陸并且管理他們售賣(mài)的產(chǎn)品

這個(gè)頁(yè)面有很多有用的功能，很多的圖表，需要安裝一個(gè)來(lái)自 npm 的表單類(lèi)庫(kù)。因?yàn)槲乙呀?jīng)實(shí)現(xiàn)了打包代碼分離，目測(cè)至少已經(jīng)節(jié)省了100KB 的大小文件

現(xiàn)在我設(shè)置了一份當(dāng)用戶(hù)訪(fǎng)問(wèn)呢/admin時(shí)渲染的路由。當(dāng) Webpack 把一切都打包完畢之后，它會(huì)去查找import AdminPage from "./AdminPage.js"，并且說(shuō)“嘿，我需要把它包含到初始化的加載文件中”

但是我們不想這么做，我們希望在動(dòng)態(tài)加載中加載管理頁(yè)面，比如import("./AdminPage.js")，這樣 Webpack 就知道需要?jiǎng)討B(tài)加載它。

非?？?，不需要任何的配置

與直接引用AdminPage不同，當(dāng)用戶(hù)訪(fǎng)問(wèn)/admin時(shí)我使用另外一個(gè)組件用于實(shí)現(xiàn)如下功能：

核心思想非常簡(jiǎn)單，當(dāng)組件加載時(shí)（也就意味著用戶(hù)訪(fǎng)問(wèn)/admin時(shí)），我們動(dòng)態(tài)的加載./AdminPage.js然后在組件 state 中保存對(duì)它的引用

在渲染函數(shù)中，在等待>加載的過(guò)程中我們簡(jiǎn)單的渲染出

module.exports = {
   entry: {
      library: [
         "react",
         "redux",
         "jquery",
         "d3",
         "highcharts",
         "bootstrap",
         "angular"
      ]
   },
   output: {
      filename: "[name].dll.js",
      path: path.resolve(__dirname, "./build/library"),
      library: "[name]"
   }，
   plugins: [
    new webpack.DllPlugin({
        name: "[name]",
        path: "./build/library/[name].json"
    })
  ]
};

plugins: [
  new webpack.DllReferencePlugin({
    context: __dirname,
    manifest: require("./build/library/library.json")
  })
]