隨著 Web 的發(fā)展嘴秸，JavaScript 從以前只承擔(dān)簡單的腳本功能措嵌，到現(xiàn)在被用于構(gòu)建大型伦乔、復(fù)雜的前端應(yīng)用，經(jīng)歷了很大的發(fā)展垄提。這也讓它在當(dāng)下的前端應(yīng)用中扮演了一個非常重要的角色榔袋，因此在這一節(jié)首先來看看的我們熟悉的 JavaScript。
1. 減少不必要的請求
在進(jìn)行 JavaScript 優(yōu)化時铡俐，我們還是秉承總體思路凰兑，首先就是減少不必要的請求。
1.1. 代碼拆分（code split）與按需加載
相信熟練使用 webpack 的同學(xué)對這一特性都不陌生审丘。
雖然整體應(yīng)用的代碼非常多吏够，但是很多時候，我們在訪問一個頁面時滩报，并不需要把其他頁面的組件也全部加載過來锅知，完全可以等到訪問其他頁面時，再按需去動態(tài)加載脓钾。核心思路如下所示：
document.getElementById('btn').addEventListener('click', e => {
// 在這里加載 chat 組件相關(guān)資源 chat.js
const script = document.createElement('script');
script.src = '/static/js/chat.js';
document.getElementsByTagName('head')[0].appendChild(script);
});
在按鈕點擊的監(jiān)聽函數(shù)中售睹，我動態(tài)添加了 <script> 元素。這樣就可以實現(xiàn)在點擊按鈕時可训，才加載對應(yīng)的 JavaScript 腳本侣姆。
代碼拆分一般會配合構(gòu)建工具一起使用。以 webpack 為例沉噩，在日常使用時捺宗，最常見的方式就是通過 dynamic import[1] 來告訴 webpack 去做代碼拆分。webpack 編譯時會進(jìn)行語法分析川蒙，之后遇到 dynamic import 就會認(rèn)為這個模塊是需要動態(tài)加載的蚜厉。相應(yīng)的，其子資源也會被如此處理（除非被其他非動態(tài)模塊也引用了）畜眨。
在 webpack 中使用代碼拆分最常見的一個場景是基于路由的代碼拆分昼牛。目前很多前端應(yīng)用都在使用 SPA（單頁面應(yīng)用）形式术瓮，或者 SPA 與 MPA（多頁面應(yīng)用）的結(jié)合體，這就會涉及到前端路由贰健。而頁面間的業(yè)務(wù)差異也讓基于路由的代碼拆分成為一個最佳實踐胞四。想了解如何在 react-router v4 中實現(xiàn)路由級別的代碼拆分，可以看這篇文章[2]伶椿。
當(dāng)然辜伟，如果你不使用 webpack 之類的構(gòu)建工具，你也可以選擇一個 AMD 模塊加載器（例如 RequireJS）來實現(xiàn)前端運行時上的異步依賴加載脊另。
1.2. 代碼合并
我們在總體思路里有提到导狡，減少請求的一個方法就是合并資源。試想一個極端情況：我們現(xiàn)在不對 node_modules 中的代碼進(jìn)行打包合并偎痛，那么當(dāng)我們請求一個腳本之前將可能會并發(fā)請求數(shù)十甚至上百個依賴的腳本庫旱捧。同域名下的并發(fā)請求數(shù)過高會導(dǎo)致請求排隊，同時還可能受到 TCP/IP 慢啟動的影響踩麦。
當(dāng)然枚赡，在很多流行的構(gòu)建工具中（webpack/Rollup/Parcel），是默認(rèn)會幫你把依賴打包到一起的谓谦。不過當(dāng)你使用其他一些工具時标锄，就要注意了。例如使用 FIS3 時茁计，就需要通過配置聲明，將一些 common 庫或 npm 依賴進(jìn)行打包合并谓松。又或者使用 Gulp 這樣的工具星压，也需要注意進(jìn)行打包。
總之鬼譬，千萬不要讓你的碎文件散落一地娜膘。
2. 減少包體大小
2.1. 代碼壓縮
JavaScript 代碼壓縮比較常見的做法就是使用 UglifyJS 做源碼級別的壓縮。它會通過將變量替換為短命名优质、去掉多余的換行符等方式竣贪，在盡量不改變源碼邏輯的情況下，做到代碼體積的壓縮巩螃⊙菰酰基本已經(jīng)成為了前端開發(fā)的標(biāo)配。在 webpack 的 production 模式下是默認(rèn)開啟的避乏；而在 Gulp 這樣的任務(wù)流管理工具上也有 gulp-uglify 這樣的功能插件爷耀。
另一個代碼壓縮的常用手段是使用一些文本壓縮算法，gzip 就是常用的一種方式拍皮。
上圖中響應(yīng)頭的 Content-Encoding 表示其使用了 gzip歹叮。
深色的數(shù)字表示壓縮后的大小為 22.0KB跑杭，淺色部分表示壓縮前的大小為 91.9KB，壓縮比還是挺大的咆耿，很有效果德谅。一般服務(wù)器都會內(nèi)置相應(yīng)模塊來進(jìn)行 gzip 處理，不需要我們單獨編寫壓縮算法模塊萨螺。例如在 Nginx 中就包含了 ngx_http_gzip_module[3] 模塊窄做，通過簡單的配置就可以開啟。
gzip on;
gzip_min_length 1000;
gzip_comp_level 6;
gzip_types application/javascript application/x-javascript text/javascript;
2.2. Tree Shaking
Tree Shaking 最早進(jìn)入到前端的視線主要是因為 Rollup屑迂。后來在 webpack 中也被實現(xiàn)了浸策。其本質(zhì)是通過檢測源碼中不會被使用到的部分，將其刪除惹盼，從而減小代碼的體積庸汗。例如：
// 模塊 A
export function add(a, b) {
return a + b;
}
export function minus(a, b) {
return a - b;
}
// 模塊 B
import {add} from 'module.A.js';
console.log(add(1, 2));
可以看到，模塊 B 引用了模塊 A手报，但是只使用了 add 方法蚯舱。因此 minus 方法相當(dāng)于成為了 Dead Code，將它打包進(jìn)去沒有意義掩蛤，該方法是永遠(yuǎn)不會被使用到的枉昏。
注意，我在上面的代碼中使用了 ESM 規(guī)范的模塊語法揍鸟，而沒有使用 CommonJS兄裂。這主要是由于 Tree Shaking 算是一種靜態(tài)分析，而 ESM 本身是一種的靜態(tài)的模塊化規(guī)范阳藻，所有依賴可以在編譯期確定晰奖。如果想要更好得在 webpack 中使用，可以在查看其官網(wǎng)上的這部分內(nèi)容[4]腥泥。關(guān)于 Tree Shaking 的介紹也可以從這里了解下[5]匾南。
注意，剛才說了 Tree Shaking 非常依賴于 ESM蛔外。像是前端流行的工具庫 lodash 一般直接安裝的版本是非 ESM 的蛆楞，為了支持 Tree Shaking，我們需要去安裝它的 ESM 版本 —— lodash-es 來實現(xiàn) Tree Shaking[6]夹厌。
此外豹爹，Chrome DevTools 也可以幫助你查看加載的 JavaScript 代碼的使用覆蓋率[7]。
2.3. 優(yōu)化 polyfill 的使用
前端技術(shù)的一大特點就是需要考慮兼容性矛纹。為了讓大家能順暢地使用瀏覽器的新特性帅戒，一些程序員們開發(fā)了新特性對應(yīng)的 polyfill，用于在非兼容瀏覽器上也能使用新特性的 API。后續(xù)升級不用改動業(yè)務(wù)代碼逻住，只需要刪除相應(yīng)的 polyfill 即可钟哥。
這種舒適的開發(fā)體驗也讓 polyfill 成為了很多項目中不可或缺的一份子。然而 polyfill 也是有代價的瞎访，它增加了代碼的體積腻贰。畢竟 polyfill 也是 JavaScript 寫的，不是內(nèi)置在瀏覽器中扒秸，引入的越多播演，代碼體積也越大。所以伴奥，只加載真正所需的 polyfill 將會幫助你減小代碼體積写烤。
首先，不是每個業(yè)務(wù)的兼容性要求都一樣拾徙。因此洲炊，按你業(yè)務(wù)的場景來確定引入哪些 polyfill 是最合適的。然而尼啡，特性千千萬暂衡，手動 import 或者添加 Babel Transformer 顯然是一件成本極高的事。針對這點崖瞭，我們可以通過 browserslist 來幫忙狂巢，許多前端工具（babel-preset-env/autoprefixer/eslint-plugin-compat）都依賴于它。使用方式可以看這里书聚。
其次唧领，在 Chrome Dev Summit 2018 上還介紹了一種 Differential Serving[8] 的技術(shù)，通過瀏覽器原生模塊化 API 來盡量避免加載無用 polyfill雌续。
<script type="module" src="main.mjs"></script>
<script nomodule src="legacy.js"></script>
這樣斩个，在能夠處理 module 屬性的瀏覽器（具有很多新特性）上就只需加載 main.mjs（不包含 polyfill），而在老式瀏覽器下西雀，則會加載 legacy.js（包含 polyfill）。
最后歉摧，其實在理想上艇肴，polyfill 最優(yōu)的使用方式應(yīng)該是根據(jù)瀏覽器特性來分發(fā)坞琴，同一個項目在不同的瀏覽器瓢棒，會加載不同的 polyfill 文件。例如 Polyfill.io 就會根據(jù)請求頭中的客戶端特性與所需的 API 特性來按實際情況返回必須的 polyfill 集合乘瓤。
2.4. webpack
webpack 現(xiàn)在已經(jīng)成為很多前端應(yīng)用的構(gòu)建工具膝但，因此這里單獨將其列了出來冲九。我們可以通過 webpack-bundle-analyzer 這個工具來查看打包代碼里面各個模塊的占用大小。
很多時候，打包體積過大主要是因為引入了不合適的包莺奸，對于如何優(yōu)化依賴包的引入丑孩，這里有一些建議可以幫助你減小 bundle 的體積[9]。
3. 解析與執(zhí)行
除了 JavaScript 下載需要耗時外灭贷，腳本的解析與執(zhí)行也是會消耗時間的温学。
3.1. JavaScript 的解析耗時
很多情況下，我們會忽略 JavaScript 文件的解析甚疟。一個 JavaScript 文件仗岖，即使內(nèi)部沒有所謂的“立即執(zhí)行函數(shù)”，JavaScript 引擎也是需要對其進(jìn)行解析和編譯的览妖。
從上圖可以看出轧拄，解析與編譯消耗了好幾百毫秒。所以換一個角度來說讽膏，刪除不必要的代碼檩电，對于降低 Parse 與 Compile 的負(fù)載也是很有幫助的。
同時桅打，我們從前一節(jié)已經(jīng)知道是嗜，JavaScript 的解析、編譯和執(zhí)行會阻塞頁面解析挺尾，延遲用戶交互鹅搪。所以有時候，加載同樣字節(jié)數(shù)的 JavaScript 對性能的影響可能會高于圖片遭铺，因為圖片的處理可以放在其他線程中并行執(zhí)行丽柿。
3.2. 避免 Long Task
對于一些單頁應(yīng)用，在加載完核心的 JavaScript 資源后魂挂，可能會需要執(zhí)行大量的邏輯甫题。如果處理不好，可能會出現(xiàn) JavaScript 線程長時間執(zhí)行而阻塞主線程的情況涂召。
例如在上圖中坠非，幀率下降明顯的地方出現(xiàn)了 Long Task，伴隨著的是有一段超過 700 ms 的腳本執(zhí)行時間果正。而性能指標(biāo) FCP 與 DCL 處于其后炎码，一定程度上可以認(rèn)為，這個 Long Task 阻塞了主線程并拖慢了頁面的加載時間秋泳，嚴(yán)重影響了前端性能與體驗潦闲。
想要了解更多關(guān)于 Long Task 的內(nèi)容，可以看看 Long Task 相關(guān)的標(biāo)準(zhǔn)[10]迫皱。
3.3. 是否真的需要框架
相信如果現(xiàn)在問大家歉闰，我們是否需要 React、Vue、Angular 或其他前端框架（庫）和敬，大概率是肯定的凹炸。
但是我們可以換個角度來思考這個問題。類庫/框架幫我們解決的問題之一是快速開發(fā)與后續(xù)維護(hù)代碼概龄，很多時候还惠，類庫/框架的開發(fā)者是需要在可維護(hù)性、易用性和性能上做取舍的私杜。對于一個復(fù)雜的整站應(yīng)用蚕键，使用框架給你的既定編程范式將會在各個層面提升你工作的質(zhì)量。但是衰粹，對于某些頁面锣光，我們是否可以反其道行之呢？
例如產(chǎn)品經(jīng)理反饋铝耻，咱們的落地頁加載太慢了誊爹，用戶容易流失。這時候你會開始優(yōu)化性能瓢捉，用上這次「性能之旅」里的各種措施频丘。但你有沒有考慮過，對于像落地頁這樣的泡态、類似靜態(tài)頁的頁面搂漠，是不是可以“返璞歸真”？
也許你使用了 React 技術(shù)棧 —— 你加載了 React某弦、Redux桐汤、React-Redux、一堆 Reducers…… 好吧靶壮，整個 JavaScript 可能快 1MB 了怔毛。更重要的是，這個頁面如果是用于拉新的腾降，這也代表著訪問者并沒有緩存可以用拣度。好吧，為了一個靜態(tài)頁（或者還有一些非常簡單的表單交互）螃壤，用戶付出了高額的成本抗果，而原本這只需要 50 行不到的代碼。所以有時候考慮使用原生 JavaScript 來實現(xiàn)它也是一種策略映穗。Netflix 有一篇文章介紹了他們是如何通過這種方式大幅縮減加載與操作響應(yīng)時間的[11]窖张。
當(dāng)然幕随，還是強(qiáng)調(diào)一下蚁滋，并不是說不要使用框架/類庫，只是希望大家不要拘泥于某個思維定式。做工具的主人辕录，而不是工具的“奴隸”睦霎。
3.4. 針對代碼的優(yōu)化
<font style="color:#d65">請注意，截止目前（2019.08）以下內(nèi)容不建議在生產(chǎn)環(huán)境中使用走诞。</font>
還有一種優(yōu)化思路是把代碼變?yōu)樽顑?yōu)狀態(tài)副女。它其實算是一種編譯優(yōu)化。在一些編譯型的靜態(tài)語言上（例如 C++）蚣旱，通過編譯器進(jìn)行一些優(yōu)化非常常見碑幅。
這里要提到的就是 facebook 推出的 Prepack。例如下面一段代碼：
(function () {
function hello() {return 'hello';}
function world() {return 'world';}
global.s = hello() + ' ' + world();
})();
可以優(yōu)化為：
s = 'hello world';
不過很多時候塞绿，代碼體積和運行性能是會有矛盾的沟涨。同時 Prepack 也還不夠成熟，所以不建議在生產(chǎn)環(huán)境中使用异吻。
4. 緩存
JavaScript 部分的緩存與我們在第一部分里提到的緩存基本一致裹赴，如果你記不太清了，可以回到咱們的第一站诀浪。
4.1. 發(fā)布與部署
這里簡單提一下：大多數(shù)情況下棋返，我們對于 JavaScript 與 CSS 這樣的靜態(tài)資源，都會啟動 HTTP 緩存雷猪。當(dāng)然睛竣，可能使用強(qiáng)緩存，也可能使用協(xié)商緩存春宣。當(dāng)我們在強(qiáng)緩存機(jī)制上發(fā)布了更新的時候酵颁，如何讓瀏覽器棄用緩存，請求新的資源呢月帝？
一般會有一套配合的方式：首先在文件名中包含文件內(nèi)容的 Hash躏惋，內(nèi)容修改后，文件名就會變化嚷辅；同時簿姨，設(shè)置不對頁面進(jìn)行強(qiáng)緩存，這樣對于內(nèi)容更新的靜態(tài)資源簸搞，由于 uri 變了扁位，肯定不會再走緩存，而沒有變動的資源則仍然可以使用緩存趁俊。
上面說的主要涉及前端資源的發(fā)布和部署域仇，詳細(xì)可以看這篇內(nèi)容[12]，這里就不展開了寺擂。
4.2. 將基礎(chǔ)庫代碼打包合并
為了更好利用緩存暇务，我們一般會把不容易變化的部分單獨抽取出來泼掠。例如一個 React 技術(shù)棧的項目，可能會將 React垦细、Redux择镇、React-Router 這類基礎(chǔ)庫單獨打包出一個文件。
這樣做的優(yōu)點在于括改，由于基礎(chǔ)庫被單獨打包在一起了腻豌，即使業(yè)務(wù)代碼經(jīng)常變動，也不會導(dǎo)致整個緩存失效嘱能×呙罚基礎(chǔ)框架/庫、項目中的 common惹骂、util 仍然可以利用緩存憔涉，不會每次發(fā)布新版都會讓用戶花費不必要的帶寬重新下載基礎(chǔ)庫。
所以一種常見的策略就是將基礎(chǔ)庫這種 Cache 周期較長的內(nèi)容單獨打包在一起析苫，利用緩存減少新版本發(fā)布后用戶的訪問速度兜叨。這種方法本質(zhì)上是將緩存周期不同的內(nèi)容分離了，隔離了變化衩侥。
webpack 在 v3.x 以及之前国旷，可以通過 CommonChunkPlugin 來分離一些公共庫。而升級到 v4.x 之后有了一個新的配置項 optimization.splitChunks:
// webpack.config.js
module.exports = {
//...
optimization: {
splitChunks: {
chunks: 'all',
minChunks: 1,
cacheGroups: {
commons: {
minChunks: 1,
automaticNamePrefix: 'commons',
test: /[\\/]node_modules[\\/]react|redux|react-redux/,
chunks: 'all'
}
}
}
}
}
4.3. 減少 webpack 編譯不當(dāng)帶來的緩存失效
由于 webpack 已經(jīng)成為前端主流的構(gòu)建工具茫死，因此這里再特別提一下使用 webpack 時的一些注意點跪但，減少一些不必要的緩存失效。
我們知道峦萎，對于每個模塊 webpack 都會分配一個唯一的模塊 ID屡久，一般情況下 webpack 會使用自增 ID。這就可能導(dǎo)致一個問題：一些模塊雖然它們的代碼沒有變化爱榔，但由于增/刪了新的其他模塊被环，導(dǎo)致后續(xù)所有的模塊 ID 都變更了，文件 MD5 也就變化了详幽。另一個問題在于筛欢，webpack 的入口文件除了包含它的 runtime、業(yè)務(wù)模塊代碼唇聘，同時還有一個用于異步加載的小型 manifest版姑，任何一個模塊的變化，最后必然會傳導(dǎo)到入口文件迟郎。這些都會使得網(wǎng)站發(fā)布后剥险，沒有改動源碼的資源也會緩存失效。
規(guī)避這些問題有一些常用的方式宪肖。
4.3.1. 使用 Hash 來替代自增 ID
你可以使用 HashedModuleIdsPlugin 插件表制，它會根據(jù)模塊的相對路徑來計算 Hash 值宇姚。當(dāng)然，你也可以使用 webpack 提供的 optimization.moduleIds夫凸，將其設(shè)置為 hash，或者選擇其他合適的方式阱持。
4.3.2. 將 runtime chunk 單獨拆分出來
通過 optimization.runtimeChunk 配置可以讓 webpack 把包含 manifest 的 runtime 部分單獨分離出來夭拌，這樣就可以盡可能限制變動影響的文件范圍。
// webpack.config.js
module.exports = {
//...
optimization: {
runtimeChunk: {
name: 'runtime'
}
},
}
如果你對 webpack 模塊化 runtime 運行的原理不太了解衷咽，可以看看這篇文章[13]鸽扁。
4.3.3. 使用 records
你可以通過 recordsPath 配置來讓 webpack 產(chǎn)出一個包含模塊信息記錄的 JSON 文件，其中包含了一些模塊標(biāo)識的信息镶骗，可以用于之后的編譯桶现。這樣在后續(xù)的打包編譯時，對于被拆分出來的 Bundle鼎姊，webpack 就可以根據(jù) records 中的信息來盡量避免破壞緩存骡和。
// webpack.config.js
module.exports = {
//...
recordsPath: path.join(__dirname, 'records.json')
};
如果對上述避免或減少緩存失效的方法感興趣，也可以再讀一讀這篇文章14相寇。在 webpack v5.x 的計劃中慰于，也有針對 module 和 chunk ID 的一些工作計劃來提高長期緩存。
「性能優(yōu)化」系列內(nèi)容
-
5.1. 如何針對 JavaScript 進(jìn)行性能優(yōu)化休里？（本文）
5.2. ?? 如何針對 CSS 進(jìn)行性能優(yōu)化？
5.3. 圖片雖好赃承，但也會帶來性能問題
5.4. 字體也需要性能優(yōu)化么妙黍？
5.5. 如何針對視頻進(jìn)行性能優(yōu)化？
如何避免運行時的性能問題瞧剖？
如何通過預(yù)加載來提升性能废境？
尾聲
目前內(nèi)容已全部更新至 ? fe-performance-journey ? 倉庫中，陸續(xù)會將內(nèi)容同步到掘金上筒繁。如果希望盡快閱讀相關(guān)內(nèi)容噩凹，也可以直接去該倉庫中瀏覽。
參考資料
- Proposal Dynamic Import
- 在 react-router4 中進(jìn)行代碼拆分
- Module ngx_http_gzip_module
- Tree Shaking - webpack
- Tree Shaking 性能優(yōu)化實踐 - 原理篇
- Tree Shaking for Lodash
- CSS and JS code coverage - Chrome DevTools
- Chrome Dev Summit 2018
- Optimize your libraries with webpack
- Long Tasks API 1
- A Netflix Web Performance Case Study
- 大公司里怎樣開發(fā)和部署前端代碼毡咏？
- webpack進(jìn)階：前端運行時的模塊化設(shè)計與實現(xiàn)
- Separating a Manifest
- The cost of JavaScript in 2019
- [譯] 2019 年的 JavaScript 性能
- webpack 4: Code Splitting, chunk graph and the splitChunks optimization
- 文本壓縮算法的對比和選擇
- 簡單聊聊 GZIP 的壓縮原理與日常應(yīng)用
- Text Compression
- Better tree shaking with deep scope analysis
- How we reduced our initial JS/CSS size by 67%
