上面是各大網(wǎng)站在V8引擎上面的腳本執(zhí)行時間圖，解析和編譯階段占了總時間的大約10%~30%，在Chrome 66中，V8可以在后臺線程編譯代碼，可以將編譯時間減低到大約20%左右，但是也很少見到能夠在50ms之內(nèi)編譯完的JavaScript代碼。

另一個要注意的事情就是，JavaScript的大小并不完全意味著它的時間消耗，一個200KB的圖片和一個200KB的JavaScript所占用的時間是完全不同的。

兩者的下載時間應(yīng)該是差不多并且和大小強(qiáng)相關(guān)的，但是圖片需要解碼，柵格化以及繪制到屏幕上，而JavaScript代碼包需要解析，編譯以及執(zhí)行。JavaScript的時間消耗基本是要大于圖片的，這個差距也取決于設(shè)備的CPU性能。

根據(jù)上述內(nèi)容，在進(jìn)行性能測試的時候，盡量讓環(huán)境惡劣起來，不要使用高速的網(wǎng)絡(luò)環(huán)境以及高性能設(shè)備來進(jìn)行測試。因?yàn)橛脩粼O(shè)備和環(huán)境的均值可能是你想象不到的。

可變性會殺死用戶體驗(yàn)，高性能設(shè)備可能會變慢，高速網(wǎng)絡(luò)也可能會變慢，可變性最終會讓所有事情都變慢。

可變性需要讓開發(fā)人員降低開發(fā)時的基準(zhǔn)線，來保證每一個用戶的體驗(yàn)。如果你的團(tuán)隊(duì)能夠通過一些策略來獲知所有訪問你的站點(diǎn)的用戶環(huán)境，那么可以很方便地對于站點(diǎn)的性能兼容性進(jìn)行測試。在測試的時候，采用用戶中具有代表性的網(wǎng)絡(luò)和設(shè)備環(huán)境來進(jìn)行測試。

It"s important to know your audience.

對于網(wǎng)絡(luò)，低端網(wǎng)絡(luò)環(huán)境需要更小的JavaScript bundle。這就要求減少代碼的冗余、縮小代碼體積、并且進(jìn)行壓縮；

對于設(shè)備，做好對于重復(fù)訪問數(shù)據(jù)的緩存工作，解析時間對于低端設(shè)備來說是最重要的。

當(dāng)我們的站點(diǎn)越來越依賴于JavaScript的時候，我們有時候就會為了不容易看見的發(fā)送到客戶端的代碼付出代價。

這一點(diǎn)的關(guān)鍵在于如何發(fā)送最少限度的JavaScript到客戶端，并且能夠保證用戶的正常體驗(yàn)。Code-splitting是其中的重點(diǎn)。

目前來說，Code-splitting常用的方法就是在bundle代碼的時候，僅僅返回當(dāng)前路由對應(yīng)的相關(guān)代碼，而不返回整個龐大的代碼包。對于路由的切分以及庫的引入來說，這一個原則至關(guān)重要。無論什么理由，都盡量不要將其他路由的代碼注入到當(dāng)前訪問的路由當(dāng)中。路由的懶加載是decrease你的JavaScript加載速度的重點(diǎn)。

import Loadable from "react-loadable";
const LoadableOtherComponent = Loadable({
    loader: () => import("./OtherComponent"),
    loading: () => 
Loading...
});
const MyComponent = () => {
    
};

在React中添加code-splitting可以通過React Loadable進(jìn)行，這個庫是一個HOC，可以動態(tài)加載需要的React組件，而不會在首次渲染的時候就將所有的頁面組件都加載進(jìn)來，即使它暫時不會被使用。

現(xiàn)在也有很多庫可以幫助你來定位自己的代碼包，來幫助你從代碼層面減少JavaScript代碼的長度。比如webpack bundle analyzer，source map explorer，bundle buddy。這些工具會審視你的代碼，并且找到其中的冗余，大型庫以及一些未使用的依賴。

打包審查可以著重于一些大型依賴，或者是給你一個較輕的低位替代。

如果你不確定自己的工程代碼是否存在這些問題，通過LightHouse可以審查你的站點(diǎn)。

cnpm install -g lighthouse
lighthouse http://yoursites.com

快速生成一份站點(diǎn)的性能審查報告。

云音樂主站的審查報告大概是這樣的，我們的移動端主站大概需要3秒左右的時間能夠得到交互響應(yīng)。

Code Coverage是一個用來發(fā)現(xiàn)你的頁面中的未使用JavaScript以及CSS的DevTools。使用這個工具可以看到頁面中有多少代碼影響了加載性能，并且這些代碼讓你付出多少時間的代價。

這是主站測試環(huán)境下的代碼覆蓋率，可以發(fā)現(xiàn)libs文件基本上有一半都未在使用。而CSS更加夸張，95%的代碼都沒有使用過。

PRPL(Push、Render、Precache、Lazy-Load)模式適用于盡力將每一個多帶帶路由的代碼拆開，然后利用service worker來pre-cacheJavaScript代碼，這些懶加載的代碼是與當(dāng)前路由強(qiáng)相關(guān)的路由的邏輯代碼。

也就是說，我們在進(jìn)行路由加載的時候，僅僅加載一個純凈的路由頁面。當(dāng)這個路由頁面渲染完畢之后，我們通過一個路由相關(guān)的list來將其他與當(dāng)前路由有跳轉(zhuǎn)規(guī)則的路由頁面加載進(jìn)來，通過service worker來在后臺線程進(jìn)行懶加載與解析。并且根據(jù)我們當(dāng)前的環(huán)境，來進(jìn)行優(yōu)雅降級，如果設(shè)備不支持后臺線程，那么就采用主線程來進(jìn)行加載。

性能預(yù)算是保證所有開發(fā)人員在一個頻道的關(guān)鍵，性能預(yù)算定義了一個常量，來讓團(tuán)隊(duì)有著共同的性能目標(biāo)。

性能預(yù)算一般包括下面幾個部分：

Milestone timings（里程碑時間？）：這個時間一般基于加載頁面時候的用戶體驗(yàn)，比如可以開始交互的時候。這個時間一般是頁面完成加載的精確時間。

Quality-based metrics：基于純粹的值，比如JavaScript的大小，HTTP請求的數(shù)量，這個值主要關(guān)注瀏覽器體驗(yàn)。

Rule-based metrics：通過LightHouse或者其他頁面測試工具得到的評分。

由于現(xiàn)在的大型項(xiàng)目總都是由多個開發(fā)人員一起進(jìn)行開發(fā)的，這些開發(fā)人員對于頁面的性能并沒有一個統(tǒng)一的標(biāo)準(zhǔn)，通過上面三個標(biāo)準(zhǔn)，每個人在加入了自己的代碼之后就可以對于性能進(jìn)行測試，來確認(rèn)自己是否影響到了整個項(xiàng)目的性能預(yù)算。比如自己的庫導(dǎo)致了團(tuán)隊(duì)的JavaScript代碼超量。這時，團(tuán)隊(duì)的人就需要根據(jù)情況來削減自己的代碼量。

下面的有點(diǎn)可怕，就放原文了：

Here’s an action plan for performance: 
Create your performance vision. This is a one-page agreement on what business stakeholders and developers consider “good performance” 
Set your performance budgets. Extract key performance indicators (KPIs) from the vision and set realistic, measurable targets from them. e.g. “Load and get interactive in 5s”. Size budgets can fall out of this. e.g “Keep JS < 170KB minified/compressed” 
?Create regular reports on KPIs.?This can be a regular report sent out to the business highlighting progress and success.

在GIT合并的時候設(shè)置LightHouse的檢測規(guī)則，如果導(dǎo)致了LightHouse評分降低，則blocked該次合并。在對于性能極致要求的業(yè)務(wù)情況下，這個方法的確能夠有效地提升業(yè)務(wù)代碼的質(zhì)量。

性能不是一蹴而就的，許多細(xì)小的變動都可能會帶來大的收益。