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

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

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

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

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

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

It"s important to know your audience.

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

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

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

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

目前來說，Code-splitting常用的方法就是在bundle代碼的時(shí)候，僅僅返回當(dāng)前路由對(duì)應(yīng)的相關(guān)代碼，而不返回整個(gè)龐大的代碼包。對(duì)于路由的切分以及庫的引入來說，這一個(gè)原則至關(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)行，這個(gè)庫是一個(gè)HOC，可以動(dòng)態(tài)加載需要的React組件，而不會(huì)在首次渲染的時(shí)候就將所有的頁面組件都加載進(jìn)來，即使它暫時(shí)不會(huì)被使用。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rule-based metrics：通過LightHouse或者其他頁面測(cè)試工具得到的評(píng)分。

由于現(xiàn)在的大型項(xiàng)目總都是由多個(gè)開發(fā)人員一起進(jìn)行開發(fā)的，這些開發(fā)人員對(duì)于頁面的性能并沒有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)，通過上面三個(gè)標(biāo)準(zhǔn)，每個(gè)人在加入了自己的代碼之后就可以對(duì)于性能進(jìn)行測(cè)試，來確認(rèn)自己是否影響到了整個(gè)項(xiàng)目的性能預(yù)算。比如自己的庫導(dǎo)致了團(tuán)隊(duì)的JavaScript代碼超量。這時(shí)，團(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í)候設(shè)置LightHouse的檢測(cè)規(guī)則，如果導(dǎo)致了LightHouse評(píng)分降低，則blocked該次合并。在對(duì)于性能極致要求的業(yè)務(wù)情況下，這個(gè)方法的確能夠有效地提升業(yè)務(wù)代碼的質(zhì)量。

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