H5 頁面發(fā)版靈活，輕量，又具有跨平臺的特性，在業(yè)務(wù)上有很多應(yīng)用場景。但是同時對比 App，H5 的性能表現(xiàn)總是要遜色一籌，比如頁面打開往往會出現(xiàn)白屏，滑動列表等交互場景下也不如 Native 頁面流暢。針對這些白屏、卡慢之類的問題，我們測試該從哪些方面去展開測試分析和數(shù)據(jù)對比呢？接下來筆者分享一些 H5 前端測試實踐的經(jīng)驗，拋磚引玉，希望大家一起談?wù)?，一起挖掘更多有價值的課題。

一、開篇：H5 頁面加載過程淺析

如下圖所示，是精選平臺打開 H5 頁面的幾個過程截圖。

圖一到圖四可以簡單分類，圖一是 App 負責(zé)做的事情，主要是初始化 Webview 上下文；后面三張圖則是一個H5頁面加載的過程。其中，App 這個階段的耗時，主要是 Native 代碼的耗時，這里先不展開討論，我們重點放在后面幾個階段。第四個圖是用戶直觀看到的***屏頁面，我們通常稱為首屏。

1）加載網(wǎng)絡(luò)請求

這個過程主要是 Webview 拿到 H5 頁面 url 之后，調(diào)用 loadUrl 方法，開始去網(wǎng)絡(luò)上請求***個資源文件。這個階段主要包含 dns 解析、建立網(wǎng)絡(luò)鏈接、數(shù)據(jù)傳輸?shù)暮臅r。

2）html 解析

Webview 拿到 html 返回后，需要從上至下解析 html 中的標簽和內(nèi)容，識別外鏈資源、計算頁面框架的布局，并渲染繪制出來。在這個過程中會構(gòu)建出負責(zé)頁面結(jié)構(gòu)的 DOM Tree 和負責(zé)頁面布局展示的 Render Tree，如下圖所示：

3）外鏈資源加載

這部分主要是從網(wǎng)絡(luò)上加載外鏈的 css、圖片和 js 等，再重新填充到 html 中。之后重新進行一次 layout 布局計算和頁面渲染繪制，此時看到的才是有完整內(nèi)容的頁面。如下圖所示，頁面需要等圖片和 css 加載出來后才能展示，js 也是外鏈資源，不過一般來說，只要放在 html 底部加載，就不會阻塞頁面的渲染和展示。

二、實例分析：白屏問題

前面我們已經(jīng)了解了 H5 頁面加載過程，接下來如果遇到白屏，我們自然會問，怎么才能知道頁面當前處在哪個階段，每個階段耗時多長，以及整體首屏加載的耗時呢？

首先看下通過 PC Chrome 模擬 H5 頁面的情況。Chrome Devtool 提供的 Performance 工具，可以錄制頁面從***個請求到加載完成的所有事件，通過這種方式可以很詳細的看到各階段做的事情和具體的耗時。

其中兩個最關(guān)鍵的首屏耗時指標：domContentLoaded（首屏頁面可見）和onLoad（首屏加載完成）的耗時，除了圖示的方法，還可以通過在 console 里打印全局變量window.performance.timing，拿到時間戳并計算得到。

但實際我們要的是移動設(shè)備的真機數(shù)據(jù)，這個才能真實反應(yīng)頁面性能和用戶體驗。想要獲取 H5 真機耗時，一種方式是 js 代碼進行上報；另一種是對于 Android 設(shè)備，可以用 remote-debug 的方式遠程調(diào)試真機頁面。只需要保證 webview 調(diào)試開關(guān)打開 & 與 PC USB 連接且開啟 USB 調(diào)試，就可以在 PC Chrome 訪問 chrome://inspect 來獲取調(diào)試對象。之后參考 PC Chrome 模擬 H5 的方法即可拿到數(shù)據(jù)。

對于傳統(tǒng)頁面而言，實際分析發(fā)現(xiàn)大部分耗時還是在移動網(wǎng)絡(luò)請求這部分，所以最直接有效的方式就是對頁面進行直出改造，也就是改變先加載 html、再加載 css 等數(shù)據(jù)的情況，先在后端（比如 nodejs）并行加載首屏依賴的所有 css、js 和后臺接口數(shù)據(jù)，拼裝好一個完成的最終要呈現(xiàn)的 html 再回給前端，達到秒開的效果。

三、實例分析：卡慢問題

有時候用戶在頁面交互的過程中會遇到卡慢，比如上下滑動列表、左右切換或者輪播等。這個過程無非也是執(zhí)行 js、請求資源、計算新的頁面布局并渲染繪制這幾件事。通過 Performance 分析就會發(fā)現(xiàn)，卡慢其實并不全是很多人認為的“移送設(shè)備性能就是差”，有時候其實是假性卡頓。

比如下面這個就是熱區(qū)過小的問題：

真卡的情況，往往腳本報錯占了很大比重，直觀表現(xiàn)就是頁面是卡死，而不是變慢。其他的諸如內(nèi)存問題，通常表現(xiàn)是頁面越來越卡，因為使用時間越長，資源消耗越大。比如頁面使用了比較復(fù)雜的 canvas 動畫、比較耗性能的 iframe 元素，或者直播流媒體，這種情況下容易出現(xiàn)內(nèi)存泄漏。

下面這個就是 dom 節(jié)點引發(fā)的內(nèi)存泄漏,不使用的 commentList 列表沒有釋放，越積越多到長度幾萬個的時候開始卡頓。

四、總結(jié)：H5 前端性能測試方案

當然，前端性能不僅僅表現(xiàn)在白屏、卡頓問題，也有可能是手機過度發(fā)熱等等。從用戶核心體驗出發(fā)，我們認為，H5 前端性能最重要的參考標準就是：要以最輕量的方式，給用戶***的體驗。從這個方向出發(fā)，我們積累了一些測試經(jīng)驗，其中最重要的必過項是首屏速度（不僅提升用戶體驗，還可以提升業(yè)務(wù)的轉(zhuǎn)化率），其次流暢度、流量和 CPU 等，某些場景下也是需要重點考量的點。