性能提高80%！詳解餓了麼H5性能優化祕訣

前言

隨着移動互聯網的發展，用戶對產品的使用體驗要求愈來愈高。H5做爲業務的重要載體，在移動端的應用很是普遍，所以H5頁面性能是一個很是核心的用戶體驗指標。

本文結合【餓了麼首屏優化實踐】爲你們介紹頁面性能優化的思路。

首屏性能指標

性能優化的首要基礎是數據和指標。沒有正確的數據和指標指引，優化思路和方向多是誤差的。

UC在首屏性能指標的統計上，支持內核指標和標準的W3C標準指標。

內核指標

• start：blink內核開始建立請求的時間點, 能夠理解爲 「0」點
• T0：blink收到http head的時間
• T1：首屏有內容顯示的時間
• T2：首屏所有顯示出來的時間

性能W3C指標

首屏時間是指頁面第一屏全部資源完整展現的時間。這是一個對用戶來講很是直接的體驗指標，可是對於前端倒是一個很是難以統計衡量的指標。

一般的作法是，domContentLoadedEventEnd - fetchStart，甚至使用 loadEventStart-fetchStart ，此時頁面DOM樹已經解析完成而且顯示內容。如下給出統計頁面性能指標的方法。

性能監控

線上監控對於數據摸底和發現問題意義重大，通常在測試階段咱們只能作到基本的分析，很難得到在不一樣環境下真實準確的數據，那怎麼知道上線後性能是否有問題，或者怎麼在出現問題苗頭的時候，儘快的掐滅呢？實時線上監控是最優的選擇。

嶽鷹全景監控平臺，能夠將SDK採集上報的數據進行實時分析，能夠很直觀很方便的查看應用的性能指標。而且還能經過設置告警規則，當性能指標達到閾值的時候，及時通知，第一時間發現問題，及時處理。

實時大盤

經過實時大盤，初步瞭解性能波動狀況。

查看性能趨勢

查看頁面性能狀況，經過核心指標，如首字節、DOM Ready、頁面徹底加載等分析首屏性能、頁面加載性能。（若是對接了UC內核，可直觀的經過T2瞭解首屏性能）

分析定位到具體頁面

進一步分析，瞭解TOP訪問頁面的性能狀況

經過多維度聚合分析，更進一步定位到問題範圍

詳情分析

性能優化思路

經過線上數據進行摸底分析以後，能夠繼續進行深刻分析和優化。

1 優化方向

前端：前端圍繞着優化首屏，收斂域名，js資源治理，js耗時治理，圖片治理，接口治理等方向展開。

客戶端：客戶端圍繞着提高容器啓動速度，優化攔截邏輯，爲前端提供預加載等各類能力，提供類原生體驗等方向展開。

【乾貨預警】下面是咱們在餓了麼端H5優化專項中，總體的優化思路。

H5資源和數據都依賴於網絡，因此優化中的一大策略就是預加載。咱們先來了解一下H5場景中，有哪些常見的緩存。

• HttpCache：經過必定規則讓網絡回來的資源緩存在本地，下次使用的時候能夠直接從本地讀取。stale-while-revalidate能夠容許資源在過時以後，在一段時間內能夠繼續使用，同時發起一個異步請求，能夠容許資源先使用，再驗證。
• LocalStorage：前端可使用LocalStorage將資源存儲在本地，相似的還有IndexedDB。LocalStorage也有一些限制，好比一個域名只能存儲5M數據，不能跨域讀取。
• MemoryCache：內存緩存， Chrome中的MemoryCache主要由GC管理，資源進入MemoryCache的時候會關聯一個弱引用，在主文檔關閉的時候會被清除。
• 離線包（ZCache）：用戶訪問頁面時，內核會經過shouldInterceptRequest詢問外殼是否有可用資源，若是有可用資源，外殼會返回資源，不用再去網絡請求資源。【ZCache會走到外殼攔截邏輯，效率比HttpCache低一些，通常資源到Blink內核須要100ms，主文檔須要300ms】
• NetCache：DNS解析結果，長鏈接複用。
• V8 Bytecode Cache：V8字節碼緩存。【JS執行過一次，第二次執行能明顯減小時間】。
• Image Decode Cache：圖片解碼緩存。
• PageCache：頁面級緩存，在UC上角WebViewCache，在UC瀏覽器上點擊前進後退按鈕，就會產生WebViewCache。

針對這些緩存，咱們經常使用的預加載手段。

• 提早加載整屏文檔：主要用在信息流，提早加載前幾個Item的文檔，用戶點擊的時候能夠秒開訪問。
• 提早加載首屏圖片：主要用在信息流，點擊訪問文檔時，圖片的請求同時發出去，在文檔解析須要用到圖片時，首屏圖片已經提早加載到本地了。
• Link preload：在資源響應頭或者主文檔頭部標記出須要預加載的資源，內核會根據必定規則和優先級去提早加載這些資源，
• Module preload：相似於Link preload，但它是模塊級的預加載，除了能夠預加載模塊的依賴資源，還能夠提早編譯和解析模塊JS。
• Link prefetch：域名提早尋址。
• 提早加載接口數據：導航預加載&算法閒時預加載。

關於接口預加載，咱們是在js plugin裏面作的。固然還能夠在網絡庫中間件中攔截處理。HTTP接口預加載的兩種實現方式：

• shouldInterceptRequest攔截：在這裏攔截是否有Response緩存，返回返回，缺點是不能作接口同步，
• MtopWVPlugin（ANetBridge）攔截：咱們從新實現了一個和MtopWVPlugin同樣的JS Plugin擴展，在擴展層作攔截。

2 性能分析工具和平臺

• 魯班尺：UC魯班尺是基於Lighthouse來作的，它會分析頁面在內核中真實渲染的狀況， 並給出優化建議。
• 海鷗實驗室：UC海鷗實驗室是一個性能分析平臺，它能夠提供完善的首屏、內存、啓動、幀率分析數據。
• Lighthouse：檢測頁面性能瓶頸。
• Timeline：記錄頁面運行過程的具體細節，用於分析頁面出現問題的具體位置。
• Profile：分析頁面內存的使用狀況和JS/CSS執行時間。通常能夠用TImeline定位出大概位置，再用JavaScript CPU profiler詳細分析每一個JS函數的耗時。
• Chrome Trace：記錄頁面在瀏覽器內核執行的完整過程，粒度精細到每一個函數方法，能夠很準確的定位到具體問題。

優化實踐

接下來咱們來看看如何去分析一個H5頁面的性能優化點。

1 拿到性能分析數據

可使用UC魯班尺平臺。它會生成一份性性能報告

魯班尺是基於Lighthouse作的，Lighthouse本地跑的時候，除了能夠生成性能報告，還能夠生成Chrome Trace文件，便於咱們分析。

固然也能夠本地去抓Timeline、Chrome Trace日誌。拿到性能報告後，咱們能夠大體看看哪些地方比較耗時，資源加載，S耗時等等。再根據Trace日誌去具體分析。

2 拿到T2日誌，分析T2時間線

若是對接了UC內核，能夠分析T2日誌，分析的時候關注幾個數據：

• frameCount：最後一次T2的frameCount，表示T2在這一幀計算完成。咱們在Trace界面搜索T2Paint_Event的時候，找到這個frameCount，按下m鍵，標記T2線。
• tStart：表明T0開始計算的時間，搜索TStart_Point能夠定位到這個點。

肯定了T2線以後，就能夠分析T2線以前的頁面渲染狀況，以及影響頁面渲染的因素。

3 分析總體性能

分析T2以前的渲染總體渲染狀況，好比JS執行較長的部分，加載時間較長的部分。

4 分析加載性能

主要是Doc、接口和各類資源的加載性能。通常說來加載耗時超過300ms就算很是慢了，主要看資源是否走了離線緩存。

5 分析排版性能

主要分析排版出現的內容是否合理，排版的時機是否合理，是否存在大量重排、刷新樣式的狀況。

6 分析JS性能

JS性能主要包含三個方面：

• JS解析編譯耗時
• JS對應的業務邏輯
• JS具體函數執行耗時

通常說來v8.compile耗時超過100ms，就是比較耗時的了。

另外還須要關注兩個v8.run之間的執行間隔，通常說來出現間隔的時候是在等待接口或者資源。這塊能夠成爲優化的點，例如接口預加載、資源離線等。

而後使用timeline分析具體函數耗時，找出耗時較多的js函數，針對性的進行優化。

7 觀察圖片解碼對T2時間的影響

通常說來影響T2計算的有兩個因素：

1. 圖片解碼與繪製。
2. 首屏內容發生變化。（滑動、圖片懶加載、動態節點）

圖片特別是小圖標會某些頁面上會顯著的影響T2時間，好比在餓了麼的選擇紅包頁，通過分析，是紅包列表上面的小圖標大大的延長了T2時間，改爲iconfont實現後。優化T2耗時1400多ms，性能提高45%以上。

因此咱們能夠把這部分小圖片用IconFont或者css代替（svg矢量圖沒法計算圖片寬高，故不歸入計算）。若是實在有些圖片須要忽略T2計算，也可使用uc-perf-stat-ignore（新版本內核支持3.22）標記。

比較UC的T2Paint_Event和W3C的loadEventStart兩個事件的時間差，來觀察圖片解碼對T2計算的影響。

搜索DecodeImage能夠觀察圖片的解碼狀況

免費試用嶽鷹全景監控平臺

本文就給你們介紹這麼多，若是想要知道應用線上的性能狀況，歡迎試用嶽鷹全景監控平臺。

嶽鷹全景監控平臺，讓用戶體驗提高更簡單 >>>戳我訪問嶽鷹全景監控平臺<<<