摘要：所以，關(guān)于優(yōu)化實戰(zhàn)我們主要分為兩部分加載渲染鏈路優(yōu)化和編程代碼優(yōu)化。加載渲染鏈路優(yōu)化從訪問到頁面呈現(xiàn)，整個鏈路可以做優(yōu)化的思路。資源緩存這一節(jié)我們多帶帶介紹緩存，是的，利用好緩存可以解決很多問題，包括頁面加載和渲染的問題都能得到很好的優(yōu)化。

本文屬于思否課堂VirtualDOM到AST玩轉(zhuǎn)前端性能原理解析與代碼實戰(zhàn)課程
官方博客：fed123.com

我們已經(jīng)全面分析總結(jié)了評估頁面性能和用戶體驗的各個指標參數(shù)。那么怎么來優(yōu)化呢？open signal官方提供了2018年2月份統(tǒng)計的全世界4G網(wǎng)絡(luò)覆蓋率和通信速率的統(tǒng)計分布圖如下，在目前移動互聯(lián)網(wǎng)的浪潮下，我們要利用好用戶終端設(shè)備的每個字節(jié)的流量。

當(dāng)然頁面性能和體驗優(yōu)化并不是一蹴而就的，需要不斷的研究、跟蹤，發(fā)現(xiàn)問題，解決問題。但是我們可以在一開始編寫業(yè)務(wù)代碼的時候就做的更好，做到極致。所以，關(guān)于優(yōu)化實戰(zhàn)我們主要分為兩部分：加載渲染鏈路優(yōu)化 和 編程代碼優(yōu)化。

從訪問url到頁面呈現(xiàn)，整個鏈路可以做優(yōu)化的思路。

幸運的是，W3C推薦的Navigation Timing標準中所定義的核心的頁面性能數(shù)據(jù)，它包含了從上個頁面銷毀到跳轉(zhuǎn)到當(dāng)前頁面加載完成每個階段所消耗的時間。在canIuse上查到的兼容性也很好：

利用這個接口可以很方便的幫助我們排查鏈路問題。在Navigation Timing標準中介紹到這個API主要包含兩個接口：PerformanceTiming和PerformanceNavigation，這兩個接口由瀏覽器進行實現(xiàn)和維護，當(dāng)瀏覽器創(chuàng)建頁面的時候就會把接口定義的相關(guān)數(shù)據(jù)掛載到window.performance.timing和window.performance.navigation這兩個屬性上。我們可以打開一個網(wǎng)頁看一下：


我們把這兩個圖對比一下，就可以很容易的排查出頁面的加載鏈路問題。

打開頁面的第一步是請求頁面的html，這里面涉及TTFB這個綜合指標。同時如果有必要我們也可以統(tǒng)計DNS時間和TCP時間。

DNS時間：主要是根據(jù)請求域名查詢到對應(yīng)主機IP的時間。這個和DNS服務(wù)器有關(guān)系，也可能和本地緩存有關(guān)，如果這個很慢，可以找服務(wù)商排查下問題。

TCP時間：tcp是承接http協(xié)議的下層協(xié)議。主要是路由到主機ip，并建立tcp鏈接的時間。這個時間反應(yīng)了服務(wù)器到用戶客戶端之間鏈路是否通暢，網(wǎng)絡(luò)是否通暢。

請求完HTML之后，就開始解析html代碼，按照從上至下、自然順序解析，解析內(nèi)聯(lián)CSS代碼或者加載外鏈CSS腳本，解析內(nèi)聯(lián)Javascript腳本，或者加載外鏈Javascript腳本。由于瀏覽器是單線程的，這些CSS和Javascript腳本很可能就會造成頁面卡頓。參考 瀏覽器線程理解與microtask與macrotask。

CDN是內(nèi)容分發(fā)網(wǎng)絡(luò)，主要用于緩存靜態(tài)資源。CDN服務(wù)商一般會在全國各地部署服務(wù)，而且?guī)捄艽螅@樣訪問CDN的資源時就可以有較短的路由路徑，而且?guī)捯脖容^大，訪問比較快。

建議最好把html, CSS、JS、font、img這些資源放在CDN上，沒有CDN也可以放在OSS存儲服務(wù)上，總之比自己的服務(wù)器硬盤快多了，至少服務(wù)商會在不同區(qū)域做分布式部署

如果沒有錢買CDN服務(wù)，那么就盡可能少的加載外聯(lián)CSS和JS代碼，注意html頭部可以增加dns-prefetch，減少DNS解析時間

不是在首屏展示的資源，不要立即加載，可以在頁面onload之后加載，或者首屏渲染完成再加載

壓縮CSS、JS、font、img，盡量減少體積，服務(wù)端開啟gzip

考慮資源combo請求，減少http請求量，瀏覽器一般都有并發(fā)限制, 比如chrome一次6個并發(fā)http請求，不同瀏覽器內(nèi)核可能不一樣。

為了讓瀏覽器更快的解析渲染，我們需要考慮這幾點：

CSS嵌套層級不要太深，不超過3級，避免在最內(nèi)層使用通配選擇器。參考關(guān)于 CSS 選擇器性能

JS腳本不要太復(fù)雜，考慮輕量化架構(gòu)，降低JS復(fù)雜性，減少解析時間，盡量不要引用復(fù)雜的第三方腳本。

按需加載模塊，按需打包，首頁僅僅加載和執(zhí)行和首屏相關(guān)的腳本。其他腳本延遲加載執(zhí)行。

考慮依賴的第三方模塊是不是必須，需不需要精簡。

打包優(yōu)化，code split 和 tree shaken。常用webpack和rollup的優(yōu)化。

用戶交互相關(guān)事件綁定（比如頁面scroll，用戶左右滑動等），添加參數(shù){passive:true}，減少瀏覽器事件等待。因為這些事件屬于可阻止事件，瀏覽器不知道用戶會不會阻止，所以需要等待js執(zhí)行，然后再做響應(yīng)。添加passive參數(shù)，就告訴瀏覽器不用等待了。

IOS8以后的ios支持wkwebview，但是很多app之前用的還是uiwebview，建議轉(zhuǎn)換成wkwebview，獲得性能的提升（UIwebview在執(zhí)行JS時會阻塞UI渲染進程，WKwebview不會）。

介紹一下code split的方案： react-loadable

// 未處理
import OtherComponent from "./OtherComponent";
const MyComponent = () => (
  
);
// 使用react-loadable按需加載
import Loadable from "react-loadable";
const LoadableOtherComponent = Loadable({
  loader: () => import("./OtherComponent"),
  loading: () => 
Loading...
,
});
const MyComponent = () => (
  
);

這個也可以在打包工具統(tǒng)一配置，不用每個模塊都自己寫。

只有瀏覽器盡快渲染出來，用戶才能盡快的可以交互。

上面我們梳理了加載到解析渲染過程應(yīng)該做的事情，那么如果你這些都做好了，發(fā)現(xiàn)網(wǎng)頁表現(xiàn)依然不盡人意，那么你就要考慮做一下數(shù)據(jù)埋點。其實數(shù)據(jù)埋點在企業(yè)項目中也是必不可少的，和性能體驗優(yōu)化構(gòu)成閉環(huán)。通過數(shù)據(jù)來發(fā)現(xiàn)頁面性能和體驗的問題，更有針對的進行解決。

事實上數(shù)據(jù)埋點分為三類：

業(yè)務(wù)埋點，統(tǒng)計諸如pv、uv、點擊率、流失率、轉(zhuǎn)化率等

大數(shù)據(jù)埋點，統(tǒng)計與用戶行為相關(guān)信息，比如那個用戶點擊了那個商品，上報用戶id和商品id，方便后臺分析用戶和商品的關(guān)系，可以用做大數(shù)據(jù)分析，推薦算法來為用戶推薦商品。

工程埋點，統(tǒng)計工程上的數(shù)據(jù)信息，比如頁面秒開率，dns時間等，也就是我們上節(jié)課總結(jié)的性能和體驗數(shù)據(jù)指標。

這一節(jié)我們多帶帶介紹緩存，是的，利用好緩存可以解決很多問題，包括頁面加載和渲染的問題都能得到很好的優(yōu)化。

常見的h5緩存方案有很多種，

通常，與頁面加載性能相關(guān)的，有下面幾種緩存，

（1）MemoryCache

MemoryCache，資源存放在內(nèi)存中，一般資源響應(yīng)回來就會放進去，頁面關(guān)閉就會釋放。內(nèi)存存取性能可達磁盤緩存性能的100倍，但這還不是MemoryCache的最大優(yōu)勢，MemoryCache最大的優(yōu)勢是離排版渲染引擎非常近，可以直接被讀取，甚至無需經(jīng)過線程轉(zhuǎn)換。在真實的頁面訪問過程中，獲取資源的時間，磁盤IO僅僅是其中的一部分，更多的時間往往消耗在各種線程拋轉(zhuǎn)。

（2）ClientCache

ClientCache，客戶端緩存，比如，手淘里的ZCache（離線壓縮包緩存），本質(zhì)上屬于磁盤緩存。這類Cache的優(yōu)點是能以相對可控的方式讓資源提前緩存在磁盤，但它也有一系列的成本。比如，它需要一套服務(wù)器與客戶端協(xié)同的下發(fā)更新邏輯，服務(wù)器端需要管理下發(fā)，客戶端需要提前解壓縮。我們可能覺得提前解壓并不是什么弱點，但如果有一千個離線包，這個問題就比較嚴重了，如果不提前解壓，就無法保證首次訪問性能，如果提前解壓會讓IO非常繁忙，可能會造成客戶端打開時嚴重卡頓。

（3）HttpCache


HttpCache，是歷史比較悠久的緩存，它利用標準的 Cache-Control 與服務(wù)器端進行協(xié)商，根據(jù)標準的規(guī)則去緩存或更新資源。它應(yīng)用非常廣泛，是非常有效果的一種磁盤緩存。它的缺點是完全由瀏覽器按標準規(guī)則控制，其它端的控制力度非常弱。比如，某些被HttpCache緩存的靜態(tài)資源出問題了，通常只能是改頁面，不再使用出問題的資源，而無法主動清除出問題的資源。參考http請求緩存頭，HTTP協(xié)商緩存VS強緩存原理

（4）NetCache

網(wǎng)絡(luò)相關(guān)的Cache，一般是指DNS解析結(jié)果的緩存，或預(yù)連接的緩存。DNS預(yù)解析和預(yù)連接是非常重要的，創(chuàng)建一個Https連接的成本非常大，通常需要600ms以上，也就是說，頁面如果有關(guān)鍵資源需要全新建連接，秒開基本是不可能了。

（5）CDN

CDN一般是通過負載均衡設(shè)備根據(jù)用戶IP地址，以及用戶請求的URL，選擇一臺離用戶比較近，緩存了用戶所需的資源，有較好的服務(wù)能力的服務(wù)器，讓用戶從該服務(wù)器去請求內(nèi)容。它能讓各個用戶的緩存共享，縮短用戶獲取資源的路徑，來提升整體的性能。

當(dāng)然，還有其它非常多類型的Cache，比如，

JS相關(guān)，V8 Bytecode Cache，字節(jié)碼緩存，能極大的減少JS解析耗時，甚至可以提升3-6倍的性能。參考：前端優(yōu)化系列 – JS解析性能分析
渲染相關(guān)，圖片解碼數(shù)據(jù)緩存，是一塊非常大的內(nèi)存緩存，約100M，能保證頁面滾動過程可以實時獲取到圖片解碼數(shù)據(jù)，讓滾動非常流暢。
頁面相關(guān)，頁面緩存，Safari的PageCache，F(xiàn)irefox的Back-Forward Cache，UC瀏覽器的WebViewCache，都是一樣性質(zhì)的緩存，將整個執(zhí)行過的頁面保存在內(nèi)存。標準的頁面緩存，進入的條件非常苛刻，大部分情況都無法進入，而且在前進后退的場景才允許使用。

前面介紹了很多理論層面的內(nèi)容，我們接下來介紹一些實踐優(yōu)化案例。

（1）預(yù)置資源進MemoryCache

在頁面的onPageFinished的回調(diào)里面去檢查是否有資源可以預(yù)置，如果有，就通過相關(guān)接口把資源設(shè)置進內(nèi)核的MemoryCache。我們并不知道用戶即將會訪問什么頁面，如果把大量的資源都預(yù)置進內(nèi)存，而用戶卻沒有使用，那就會造成浪費。另外，資源在內(nèi)核內(nèi)存，僅僅是加快了資源的加載速度，頁面的首屏包含非常多非常復(fù)雜的流程，某個流程的加速并不一定能帶來整體性能的提升，比如，非關(guān)鍵的JS放在內(nèi)存，可能就會先于一些關(guān)鍵JS被提前執(zhí)行，反而讓首屏更慢。所以，選擇放那些資源進內(nèi)存也是非常有講究的，能預(yù)置的資源一般是 非常關(guān)鍵的更新頻率較低的少量公共基礎(chǔ)資源。

對于一般公司來說，沒有能力自己定制webview渲染的內(nèi)核，可以看下系統(tǒng)默認webview內(nèi)核有沒有這樣的接口來實現(xiàn)操作MemoryCache預(yù)置數(shù)據(jù)的能力。

（2）預(yù)加載資源進HttpCache

預(yù)置資源進內(nèi)存，對加載性能的提升是最明顯的，但成本也是最大的，會占用用戶手機寶貴的內(nèi)存資源。另外一種預(yù)置資源的思路是，提前通過內(nèi)核去預(yù)加載一些資源，資源加載回來之后就直接保存在標準的HttpCache。資源在HttpCache和在客戶端緩存（比如，手淘ZCache）的性能差別不大。但如果資源不能放進ZCache，通過這種方式提前放到HttpCache，也是一種優(yōu)化思路。

（3）使用WebViewCache極速切換頁面

H5頁面的加載流程是非常重的一套流程，即使同一個頁面多次重復(fù)訪問，也需要走比較完整的流程，耗時極長，這與用戶的期望是不符的，通常用戶期望訪問過的頁面就能快速展現(xiàn)出來。在一些特定的場景，H5也是可以做到極速展現(xiàn)的，比如，前進后退。其它的場景，比如頁內(nèi)幾個TAB切換，是否也可以用上這類緩存呢？也是可以的。原理上也是比較簡單的，在頁面首次訪問時，會將排版渲染好的頁面放進WebViewCache里，WebViewCache是存儲完整頁面的一塊內(nèi)存。

用戶再次訪問該頁面時，會將WebViewCache內(nèi)存中的完整頁面讀取出來，直接繪制展現(xiàn)，而無需再進行加載解析排版渲染等流程，從而達到極速打開的效果。

除了內(nèi)核提供WebViewCache基礎(chǔ)技術(shù)之外，前端也需要與內(nèi)核進行一定的交互，比如，通過JSAPI查詢當(dāng)前頁面是否在WebViewCache，如果在則返回它在WebViewCache列表的位置，然后前端就可以使用JSAPI去跳轉(zhuǎn)到相應(yīng)位置的頁面，內(nèi)核就把頁面從內(nèi)存讀取和展現(xiàn)出來。使用此類技術(shù)，頁面一般能在500ms左右完全展現(xiàn)出來，具有非常好的用戶體驗。

當(dāng)然這個也是需要瀏覽器內(nèi)核提供這種能力，如果公司有自己的內(nèi)核開發(fā)團隊，可以做到定制。

（4）前端使用LocalStorage緩存HTML文檔

當(dāng)前前端渲染非常流行，頁面大部分的邏輯都會由前端JS去執(zhí)行，JS執(zhí)行完才會生成完整的HTML文檔，而JS執(zhí)行的成本是非常大的，JS執(zhí)行時間可能占據(jù)首屏?xí)r間的50%，有些甚至能達到80%。那么，我們有沒有可能將JS執(zhí)行生成的完整HTML文檔緩存起來呢，下次訪問時直接使用已緩存的頁面，而無需重復(fù)執(zhí)行JS？這也是可以的原理上也不復(fù)雜，首次訪問頁面時，JS執(zhí)行完之后會生成完整的HTML文檔，我們將HTML文檔緩存到LocalStorage里面。

在后續(xù)的訪問中，我們優(yōu)先從LocalStorage里面讀取HTML文檔，解析排版渲染頁面，而無需JS執(zhí)行去生成頁面，讓頁面展現(xiàn)速度得到極大的提升。

這種方案的關(guān)鍵在于前端能夠?qū)崿F(xiàn)一套DOM-Diff更新的機制，在從LocalStorage讀取HTML頁面的同時，前端還會發(fā)起請求去更新HTML文檔，在新的HTML文檔回來之后，會和舊的文檔進行Diff，針對Diff來進行局部更新，這樣能保證頁面得到及時的更新。

(5) service worker

參考使用 Service Workers提升體驗，這里附帶介紹下這個方案，目前service worker 只有在android的webview中可用，ios還不支持。我們通過先注冊一個serviceworker服務(wù)，指定哪些資源和數(shù)據(jù)需要存儲，然后下次請求頁面會自動激活這個service worker，頁面請求時會先從service worker中返回緩存的數(shù)據(jù)。當(dāng)然service worker中需要自己處理版本和維護數(shù)據(jù)更新。

Code coverage，檢測哪些代碼執(zhí)行到了，哪些沒有。支持Javascript和CSS。

webpagetest：https://webpagetest.org/

Chrome Lighthouse 插件：https://chrome.google.com/web...

本文部分圖片和參考內(nèi)容來自于網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系我刪除