前言

隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，用戶對(duì)產(chǎn)品的使用體驗(yàn)要求越來越高。H5作為業(yè)務(wù)的重要載體，在移動(dòng)端的應(yīng)用非常廣泛，因此H5頁面性能是一個(gè)非常核心的用戶體驗(yàn)指標(biāo)。

本文結(jié)合【餓了么首屏優(yōu)化實(shí)踐】為大家介紹頁面性能優(yōu)化的思路。

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

首屏性能指標(biāo)

性能優(yōu)化的首要基礎(chǔ)是數(shù)據(jù)和指標(biāo)。沒有正確的數(shù)據(jù)和指標(biāo)指引，優(yōu)化思路和方向可能是偏差的。

UC在首屏性能指標(biāo)的統(tǒng)計(jì)上，支持內(nèi)核指標(biāo)和標(biāo)準(zhǔn)的W3C標(biāo)準(zhǔn)指標(biāo)。

內(nèi)核指標(biāo)

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

start：blink內(nèi)核開始創(chuàng)建請(qǐng)求的時(shí)間點(diǎn), 可以理解為 “0”點(diǎn)
T0：blink收到http head的時(shí)間
T1：首屏有內(nèi)容顯示的時(shí)間
T2：首屏全部顯示出來的時(shí)間

性能W3C指標(biāo)

首屏?xí)r間是指頁面第一屏所有資源完整展示的時(shí)間。這是一個(gè)對(duì)用戶來說非常直接的體驗(yàn)指標(biāo)，但是對(duì)于前端卻是一個(gè)非常難以統(tǒng)計(jì)衡量的指標(biāo)。

通常的做法是，domContentLoadedEventEnd - fetchStart，甚至使用 loadEventStart-fetchStart ，此時(shí)頁面DOM樹已經(jīng)解析完成并且顯示內(nèi)容。以下給出統(tǒng)計(jì)頁面性能指標(biāo)的方法。

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

性能監(jiān)控

線上監(jiān)控對(duì)于數(shù)據(jù)摸底和發(fā)現(xiàn)問題意義重大，一般在測(cè)試階段我們只能做到基本的分析，很難獲得在不同環(huán)境下真實(shí)準(zhǔn)確的數(shù)據(jù)，那怎么知道上線后性能是否有問題，或者怎么在出現(xiàn)問題苗頭的時(shí)候，盡快的掐滅呢？實(shí)時(shí)線上監(jiān)控是最優(yōu)的選擇。

岳鷹全景監(jiān)控平臺(tái)，可以將SDK采集上報(bào)的數(shù)據(jù)進(jìn)行實(shí)時(shí)分析，可以很直觀很方便的查看應(yīng)用的性能指標(biāo)。并且還能通過設(shè)置告警規(guī)則，當(dāng)性能指標(biāo)達(dá)到閾值的時(shí)候，及時(shí)通知，第一時(shí)間發(fā)現(xiàn)問題，及時(shí)處理。

實(shí)時(shí)大盤

通過實(shí)時(shí)大盤，初步了解性能波動(dòng)情況。

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

查看性能趨勢(shì)

查看頁面性能情況，通過核心指標(biāo)，如首字節(jié)、DOM Ready、頁面完全加載等分析首屏性能、頁面加載性能。（如果對(duì)接了UC內(nèi)核，可直觀的通過T2了解首屏性能）

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

分析定位到具體頁面

進(jìn)一步分析，了解TOP訪問頁面的性能情況

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

通過多維度聚合分析，更進(jìn)一步定位到問題范圍

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

詳情分析

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

性能優(yōu)化思路

通過線上數(shù)據(jù)進(jìn)行摸底分析之后，可以繼續(xù)進(jìn)行深入分析和優(yōu)化。

1 優(yōu)化方向

前端：前端圍繞著優(yōu)化首屏，收斂域名，js資源治理，js耗時(shí)治理，圖片治理，接口治理等方向展開。

客戶端：客戶端圍繞著提升容器啟動(dòng)速度，優(yōu)化攔截邏輯，為前端提供預(yù)加載等各種能力，提供類原生體驗(yàn)等方向展開。

【干貨預(yù)警】下面是我們?cè)陴I了么端H5優(yōu)化專項(xiàng)中，整體的優(yōu)化思路。

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

H5資源和數(shù)據(jù)都依賴于網(wǎng)絡(luò)，所以優(yōu)化中的一大策略就是預(yù)加載。我們先來了解一下H5場(chǎng)景中，有哪些常見的緩存。

HttpCache：通過一定規(guī)則讓網(wǎng)絡(luò)回來的資源緩存在本地，下次使用的時(shí)候可以直接從本地讀取。stale-while-revalidate可以允許資源在過期之后，在一段時(shí)間內(nèi)可以繼續(xù)使用，同時(shí)發(fā)起一個(gè)異步請(qǐng)求，可以允許資源先使用，再驗(yàn)證。
LocalStorage：前端可以使用LocalStorage將資源存儲(chǔ)在本地，類似的還有IndexedDB。LocalStorage也有一些限制，比如一個(gè)域名只能存儲(chǔ)5M數(shù)據(jù)，不能跨域讀取。
MemoryCache：內(nèi)存緩存， Chrome中的MemoryCache主要由GC管理，資源進(jìn)入MemoryCache的時(shí)候會(huì)關(guān)聯(lián)一個(gè)弱引用，在主文檔關(guān)閉的時(shí)候會(huì)被清除。
離線包（ZCache）：用戶訪問頁面時(shí)，內(nèi)核會(huì)通過shouldInterceptRequest詢問外殼是否有可用資源，如果有可用資源，外殼會(huì)返回資源，不用再去網(wǎng)絡(luò)請(qǐng)求資源。【ZCache會(huì)走到外殼攔截邏輯，效率比HttpCache低一些，一般資源到Blink內(nèi)核需要100ms，主文檔需要300ms】
NetCache：DNS解析結(jié)果，長(zhǎng)連接復(fù)用。
V8 Bytecode Cache：V8字節(jié)碼緩存。【JS執(zhí)行過一次，第二次執(zhí)行能明顯減少時(shí)間】。
Image Decode Cache：圖片解碼緩存。
PageCache：頁面級(jí)緩存，在UC上角WebViewCache，在UC瀏覽器上點(diǎn)擊前進(jìn)后退按鈕，就會(huì)產(chǎn)生WebViewCache。

針對(duì)這些緩存，我們常用的預(yù)加載手段。

提前加載整屏文檔：主要用在信息流，提前加載前幾個(gè)Item的文檔，用戶點(diǎn)擊的時(shí)候可以秒開訪問。
提前加載首屏圖片：主要用在信息流，點(diǎn)擊訪問文檔時(shí)，圖片的請(qǐng)求同時(shí)發(fā)出去，在文檔解析需要用到圖片時(shí)，首屏圖片已經(jīng)提前加載到本地了。
Link preload：在資源響應(yīng)頭或者主文檔頭部標(biāo)記出需要預(yù)加載的資源，內(nèi)核會(huì)根據(jù)一定規(guī)則和優(yōu)先級(jí)去提前加載這些資源，
Module preload：類似于Link preload，但它是模塊級(jí)的預(yù)加載，除了可以預(yù)加載模塊的依賴資源，還可以提前編譯和解析模塊JS。
Link prefetch：域名提前尋址。
提前加載接口數(shù)據(jù)：導(dǎo)航預(yù)加載&算法閑時(shí)預(yù)加載。

關(guān)于接口預(yù)加載，我們是在js plugin里面做的。當(dāng)然還可以在網(wǎng)絡(luò)庫中間件中攔截處理。HTTP接口預(yù)加載的兩種實(shí)現(xiàn)方式：

shouldInterceptRequest攔截：在這里攔截是否有Response緩存，返回返回，缺點(diǎn)是不能做接口同步，
MtopWVPlugin（ANetBridge）攔截：我們重新實(shí)現(xiàn)了一個(gè)和MtopWVPlugin一樣的JS Plugin擴(kuò)展，在擴(kuò)展層做攔截。

2 性能分析工具和平臺(tái)

魯班尺：UC魯班尺是基于Lighthouse來做的，它會(huì)分析頁面在內(nèi)核中真實(shí)渲染的情況，并給出優(yōu)化建議。
海鷗實(shí)驗(yàn)室：UC海鷗實(shí)驗(yàn)室是一個(gè)性能分析平臺(tái)，它可以提供完善的首屏、內(nèi)存、啟動(dòng)、幀率分析數(shù)據(jù)。
Lighthouse：檢測(cè)頁面性能瓶頸。
Timeline：記錄頁面運(yùn)行過程的具體細(xì)節(jié)，用于分析頁面出現(xiàn)問題的具體位置。
Profile：分析頁面內(nèi)存的使用情況和JS/css執(zhí)行時(shí)間。一般可以用TImeline定位出大概位置，再用JAVAScript CPU profiler詳細(xì)分析每個(gè)JS函數(shù)的耗時(shí)。
Chrome Trace：記錄頁面在瀏覽器內(nèi)核執(zhí)行的完整過程，粒度精細(xì)到每個(gè)函數(shù)方法，可以很準(zhǔn)確的定位到具體問題。

優(yōu)化實(shí)踐

接下來我們來看看如何去分析一個(gè)H5頁面的性能優(yōu)化點(diǎn)。

1 拿到性能分析數(shù)據(jù)

可以使用UC魯班尺平臺(tái)。它會(huì)生成一份性性能報(bào)告

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

魯班尺是基于Lighthouse做的，Lighthouse本地跑的時(shí)候，除了可以生成性能報(bào)告，還可以生成Chrome Trace文件，便于我們分析。

當(dāng)然也可以本地去抓Timeline、Chrome Trace日志。拿到性能報(bào)告后，我們可以大致看看哪些地方比較耗時(shí)，資源加載，S耗時(shí)等等。再根據(jù)Trace日志去具體分析。

2 拿到T2日志，分析T2時(shí)間線

如果對(duì)接了UC內(nèi)核，可以分析T2日志，分析的時(shí)候關(guān)注幾個(gè)數(shù)據(jù)：

frameCount：最后一次T2的frameCount，表示T2在這一幀計(jì)算完成。我們?cè)赥race界面搜索T2Paint_Event的時(shí)候，找到這個(gè)frameCount，按下m鍵，標(biāo)記T2線。
tStart：代表T0開始計(jì)算的時(shí)間，搜索TStart_Point可以定位到這個(gè)點(diǎn)。

確定了T2線之后，就可以分析T2線之前的頁面渲染情況，以及影響頁面渲染的因素。

3 分析整體性能

分析T2之前的渲染整體渲染情況，比如JS執(zhí)行較長(zhǎng)的部分，加載時(shí)間較長(zhǎng)的部分。

4 分析加載性能

主要是Doc、接口和各種資源的加載性能。一般說來加載耗時(shí)超過300ms就算非常慢了，主要看資源是否走了離線緩存。

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

5 分析排版性能

主要分析排版出現(xiàn)的內(nèi)容是否合理，排版的時(shí)機(jī)是否合理，是否存在大量重排、刷新樣式的情況。

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

6 分析JS性能

JS性能主要包含三個(gè)方面：

JS解析編譯耗時(shí)
JS對(duì)應(yīng)的業(yè)務(wù)邏輯
JS具體函數(shù)執(zhí)行耗時(shí)

一般說來v8.compile耗時(shí)超過100ms，就是比較耗時(shí)的了。

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

另外還需要關(guān)注兩個(gè)v8.run之間的執(zhí)行間隔，一般說來出現(xiàn)間隔的時(shí)候是在等待接口或者資源。這塊可以成為優(yōu)化的點(diǎn)，例如接口預(yù)加載、資源離線等。

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

然后使用timeline分析具體函數(shù)耗時(shí)，找出耗時(shí)較多的js函數(shù)，針對(duì)性的進(jìn)行優(yōu)化。

性能提升80%！詳解餓了么H5性能優(yōu)化秘訣

7 觀察圖片解碼對(duì)T2時(shí)間的影響

一般說來影響T2計(jì)算的有兩個(gè)因素：

圖片解碼與繪制。
首屏內(nèi)容發(fā)生變化。（滑動(dòng)、圖片懶加載、動(dòng)態(tài)節(jié)點(diǎn)）

圖片特別是小圖標(biāo)會(huì)某些頁面上會(huì)顯著的影響T2時(shí)間，比如在餓了么的選擇紅包頁，經(jīng)過分析，是紅包列表上面的小圖標(biāo)大大的延長(zhǎng)了T2時(shí)間，改成iconfont實(shí)現(xiàn)后。優(yōu)化T2耗時(shí)1400多ms，性能提升45%以上。

所以我們可以把這部分小圖片用IconFont或者css代替（svg矢量圖無法計(jì)算圖片寬高，故不納入計(jì)算）。如果實(shí)在有些圖片需要忽略T2計(jì)算，也可以使用uc-perf-stat-ignore（新版本內(nèi)核支持3.22）標(biāo)記。