說到H5測試，對于做WEB測試的同學(xué)來說再熟悉不過了，它包括頁H5功能測試，前端性能測試，瀏覽器兼容性能測試，以及服務(wù)端性能測試。那本文談到的則是H5前端性能測試，并希望通過閱讀本文后，能夠知道：H5前端性能測試什么？如何發(fā)現(xiàn)問題以及相應(yīng)的優(yōu)化規(guī)則。
一、瀏覽器渲染引擎
瀏覽器是Html解析和頁面最終展示的工具，所以測試H5前理解瀏覽器的工作原理是必不可少的，具體可參考《瀏覽器工作原理》。
瀏覽器的主要功能
瀏覽器的主要功能是將用戶選擇的web資源呈現(xiàn)出來，它需要從服務(wù)器請求資源，并將其顯示在瀏覽器窗口中，資源的格式通常是HTML，也包括PDF、image及其他格式。在瀏覽器組成部分中，渲染引擎是用戶直接相關(guān)，呈現(xiàn)用戶所需頁面的部分。所以從渲染引擎入手，了解HTML解析與頁面展示。
渲染引擎工作流

dom樹構(gòu)建：從html標(biāo)簽的解析開始，將各種標(biāo)簽解析為dom樹中的各個(gè)節(jié)點(diǎn)，標(biāo)簽和dom樹的中的節(jié)點(diǎn)是一一對應(yīng)關(guān)系。
渲染樹構(gòu)建：將CSS和style標(biāo)簽中的樣式信息解析為渲染樹，渲染樹由一些包含有顏色和大小等屬性的矩形組成，它們將被按照正確的順序顯示到屏幕上。
渲染樹布局和繪制：渲染樹確定各個(gè)dom節(jié)點(diǎn)在屏幕中單確切位置，根據(jù)渲染樹中的顏色等信息繪制出網(wǎng)頁。

值得注意的是，這個(gè)過程是逐步完成的，為了更好的用戶體驗(yàn)，渲染引擎將會(huì)盡可能早的將內(nèi)容呈現(xiàn)到屏幕上，并不會(huì)等到所有的html都解析完成之后再去構(gòu)建和布局渲染樹。它是解析完一部分內(nèi)容就顯示一部分內(nèi)容，同時(shí)，可能還在通過網(wǎng)絡(luò)下載其余內(nèi)容。
二、測試關(guān)注指標(biāo)
Http相關(guān)：
1、Http請求個(gè)數(shù)
有統(tǒng)計(jì)證明：一個(gè)網(wǎng)頁最終到達(dá)終端用戶有80%的時(shí)間都是在js，CSS，圖片，mp3，flash等資源的http請求。另一方面，http請求的數(shù)量也是有限制的，瀏覽器對同一個(gè)域名有連接數(shù)限制，不同瀏覽器內(nèi)核、不同版本的請求數(shù)不盡相同，大部分的并發(fā)請求數(shù)是6個(gè)。

看來通過夠控制http請求的數(shù)量，減少http請求時(shí)間，達(dá)到減少網(wǎng)頁加載和呈現(xiàn)的時(shí)間，能帶來更好的用戶體驗(yàn)。
　　優(yōu)化方案：

雪碧圖：即CSS Sprite，也稱CSS精靈，是一種CSS圖像合并技術(shù)，該方法是將小圖標(biāo)和背景圖像合并到一張圖片上，然后利用CSS的背景定位來顯示需要顯示的圖片部分。
如圖有16個(gè)icon，每一次取圖片都需要一個(gè)http請求，如果通過CSS雪碧圖將16個(gè)資源合并，再通過background-image和backgorund-position定位出雪碧圖中的小區(qū)域，那么只需要一個(gè)http請求就可以獲得全部圖片。
圖片地圖：是一種小圖合并大圖的方式，和雪碧圖相似，區(qū)別僅在實(shí)現(xiàn)原理上有不同，雪碧圖是通過CSS的方式來呈現(xiàn)圖片的某個(gè)局部，而圖片地圖是從html代碼的方式來控制顯示區(qū)域。
js CSS 合并：將多個(gè)小的js、CSS合并成一個(gè)大的js、CSS文件，間接達(dá)到減少http請求的目的。
2、組件是否壓縮

壓縮方法：在http請求中設(shè)置所接受到壓縮方式，在Server端對Response資源進(jìn)行壓縮再傳給瀏覽器。一般使用GZIP設(shè)置content-Encoding字段。 壓縮對象：從http請求返回資源中的html，js，CSS，xml等都可以設(shè)置壓縮，值得注意的是我們不需要對圖片音樂等資源設(shè)置壓縮，因?yàn)檫@些資源本身已經(jīng)壓縮過了，再次壓縮收益并不高，而且增加CPU負(fù)擔(dān)。Js，CSS我們通常通過去掉空格和回車來壓縮，再經(jīng)過GZIP壓縮，能達(dá)到良好的壓縮效果。
通常來說，組件壓縮是一種增加CPU壓縮解壓縮時(shí)間來減少網(wǎng)絡(luò)傳輸消耗的辦法，并且通常網(wǎng)絡(luò)資源較cpu資源更緊張，所以對合適的對象設(shè)置壓縮能個(gè)取得良好的收益。
3、圖片格式和大小是否合適
圖片格式：顯示效果較好的圖片格式中，有webp、jpg和png24/32這幾種常見的圖片格式。一般來說，webp的圖片最小，但在iOS或者android4.0以下的系統(tǒng)中可能會(huì)有兼容性問題需要解決。
圖片尺寸：這獲取圖片尺寸時(shí)候應(yīng)該考慮圖片具體的展示場景，如當(dāng)前移動(dòng)設(shè)備中常用個(gè)尺寸規(guī)格為480×800、600×1024、720×1280，800×1280等，從原圖來保證圖片能夠被呈現(xiàn)，而不是通過代碼對圖片放大或縮小。
圖片壓縮：對于jpg，png格式圖片來說本身就已經(jīng)經(jīng)過了壓縮，這對于稀缺的帶寬資源是不夠的，我們還需要更加優(yōu)化的壓縮算法，通過一系列的圖片壓縮工具如TinyPNG， Smush.it可以得到更好的壓縮且圖片質(zhì)量不變。

4.CSS放在頂部
在瀏覽器渲染過程中談到，dom樹構(gòu)建完成后。CSS要放到html代碼的開頭的head標(biāo)簽結(jié)束前。如果網(wǎng)頁是動(dòng)態(tài)生成的，那么在head代碼完成后可以頁面輸出，這樣瀏覽器就會(huì)更快地解析出來head中的內(nèi)容，開始下載CSS文件資源。而CSS放在底部則會(huì)引起重新繪制，用戶側(cè)感受到“閃屏”的不好體驗(yàn)。
5、JS放在底部
JS在下載的時(shí)候會(huì)引起兩個(gè)問題：阻止網(wǎng)頁內(nèi)容的展示并阻止其他資源下載。在“減少http數(shù)量”部分中，我們談到各種資源的下載是并行的，根據(jù)不同域名不同瀏覽器內(nèi)核并行數(shù)量有所不同，所以下載js時(shí)候，并行下載機(jī)制失效。并且在js中可能包括document.write等改變頁面布局的操作，所以渲染引擎會(huì)等待js下載完成再開始渲染。所以用戶側(cè)頁面加載時(shí)間會(huì)因?yàn)榈却兊酶L。
6、JS &CSS壓縮
首先舉一個(gè)例子，相信大家在使用jquery時(shí)注意到有兩個(gè)文件jquery-1.4.2.js和 jquery-1.4.2.min.js，這里的min.js就是js方式的壓縮結(jié)果。具體壓縮方法如下：

第一步：“精簡”，去掉js文件中的而空格和換行符和注釋等信息，使得js代碼變得緊湊而不失其語義。如：

第二步：”混淆”，將方法名和變量名用更簡短的方式來表達(dá)，如變量可以用一個(gè)字符來表示。如：

優(yōu)點(diǎn)：從js&CSS文件的源頭進(jìn)行壓縮，縮小了http傳輸過程數(shù)據(jù)大小。
缺點(diǎn)：通過兩步壓縮后，再來閱讀js&CSS源碼是非常苦難的。并且經(jīng)過壓縮的代碼可能和另一個(gè)壓縮的代碼因變量被共用而引起語法錯(cuò)誤。
最后，經(jīng)過壓縮過的腳本文件使用務(wù)器端設(shè)置GZIP壓縮算來壓縮，能夠壓使文件縮得更加的淋漓盡致。
7、是否添加緩存

為一種減少http請求的方式，如下有兩種方式設(shè)置緩存，測試時(shí)注意常用資源是否請求資源時(shí)否設(shè)置緩存：
Cache-Control
“no-cache”指示請求或響應(yīng)消息不能緩存（HTTP/1.0用Pragma的no-cache替換）
“no-store”用于防止重要的信息被無意的發(fā)布。在請求消息中發(fā)送將使得請求和響應(yīng)消息都不使用緩存。根據(jù)緩存超時(shí)
Expires 表示存在時(shí)間，允許客戶端在這個(gè)時(shí)間之前不去檢查（發(fā)請求），等同max-age的效果。但是如果同時(shí)存在，則被Cache-Control的max-age覆蓋。
設(shè)置方式：通過HTTP的META設(shè)置expires和cache-control
8、避免非200返回值

每一個(gè)http請求都有一個(gè)相對于的返回狀態(tài)標(biāo)志當(dāng)次請求是否如期完成，如：
1xx：請求收到，這些狀態(tài)代碼表示臨時(shí)的響應(yīng)。
2xx：操作成功，這類狀態(tài)代碼表明服務(wù)器成功地接受了客戶端請求。
3xx：重定向，客戶端瀏覽器必須采取更多操作來實(shí)現(xiàn)請求。
4xx：客戶端錯(cuò)誤，發(fā)生錯(cuò)誤，客戶端似乎有問題。
5xx：服務(wù)器錯(cuò)誤，服務(wù)器由于遇到錯(cuò)誤而不能完成該請求。
所以，如果有http請求返回為非200的狀態(tài)碼，我們認(rèn)為這一次請求時(shí)無意義的，占用了稀缺的網(wǎng)絡(luò)資源，所應(yīng)該避免非200的返回狀態(tài)碼。
9、使用CDN

CDN內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network）將源站內(nèi)容發(fā)布到最接近用戶的“邊緣”節(jié)點(diǎn)，使用戶可就近取得所需內(nèi)容，提高用戶訪問的響應(yīng)速度和成功率。解決因分布、帶寬、服務(wù)器能力帶來的訪問延遲高問題，提供一系列加速解決方案。所以，如果H5的用戶分散在全國各地，建議盡可能的將資源放到CDN，如騰訊云CDN。
時(shí)間相關(guān)：

白屏?xí)r間：用戶首次看到網(wǎng)頁有內(nèi)容的時(shí)間，即第一次渲染流程完成時(shí)間。
首屏?xí)r間：是指用戶看到第一屏，即整個(gè)網(wǎng)頁頂部大小為當(dāng)前窗口的區(qū)域，顯示完整的時(shí)間。
首資源下載時(shí)間：從開始下載到第一個(gè)資源均下載完成的時(shí)間，不包括頁面繪制時(shí)間。
總資源下載時(shí)間：從開始下載到所有資源均下載完成的時(shí)間，不包括頁面繪制時(shí)間。
用戶可操作時(shí)間：從頁面開始加載到用戶操作可響應(yīng)的時(shí)間。
上述各種時(shí)間指標(biāo)應(yīng)根據(jù)當(dāng)前H5的具體情況，選擇合適的測試指標(biāo)。
WebView相關(guān)：
在android和IOS上測試H5性能，測試員還應(yīng)該關(guān)注因加載H5而引起的app常規(guī)性能指標(biāo)。
內(nèi)存：加載頁面前后內(nèi)存變化，可間接反映H5中資源數(shù)量和大小，如dom數(shù)量，圖片大小。
CPU：當(dāng)頁面中資源樣式復(fù)雜，強(qiáng)調(diào)視覺效果時(shí)，測試員可觀察CPU占用率來反映H5繪制質(zhì)量。如果CPU長期處于高占用率，可考慮降低高計(jì)算量的視覺效果等手段。
FPS：幀率尤其在有視頻和動(dòng)畫效果的H5中，測試員應(yīng)該重點(diǎn)關(guān)注，防止嚴(yán)重的卡頓流出。
　　三、常用工具
工欲善其事，必先利其器，在做H5前端性能測試之前，選擇合適的工具能讓我們的測試工作事半功倍。本文要提到的工具有兩類：
一類是抓包工具，如Fiddler、Charles等。這類工具不僅可以抓包，還可以對包進(jìn)行修改，動(dòng)態(tài)展示瀑布流，對web進(jìn)行調(diào)試。在我們做H5前端性能測試的時(shí)候，個(gè)人覺得只要不修改包，不對H5調(diào)試，就可以放棄使用這類工具，不是工具不好，而是大材小用。
還有一類，這里重點(diǎn)提到的是如Page Speed、PCAP Web Performance Analyzer、WebPagetest這類平臺(tái)型工具。我們可以快捷的測試出H5前端性能中數(shù)據(jù)，視圖，并給出一定程度的優(yōu)化建議。

以手機(jī)管家端午節(jié)運(yùn)營活動(dòng)H5為例，附上上述工具測試結(jié)果頁，當(dāng)然這里僅僅是結(jié)果的羅列。具體的分析還是需要測試人員來做，衡量是否符合當(dāng)前運(yùn)營需求。
　　WebPagetest:

　　Page Speed：

　　PCAP Web Performance Analyzer：

　　Chrome DevTools：

常見問題舉例：
同樣以手機(jī)管家端午節(jié)運(yùn)營活動(dòng)H5為例：（完成整個(gè)加載性能測試耗時(shí)只需20分鐘左右）
1、HTTP請求過多

圖為PCAP Web Performance Analyzer解析pcap包的結(jié)果，圖中我們可以看出，21個(gè)http請求中，有7個(gè)是統(tǒng)計(jì)點(diǎn)發(fā)出的請求。這里可以考慮統(tǒng)計(jì)點(diǎn)合并上報(bào)和首屏?xí)r減少上報(bào)統(tǒng)計(jì)點(diǎn)。
2、圖片空白部分太多
這里需要用到的圖片僅僅是作為右上角分享，但是在我們請求的圖片確實(shí)整張完整的圖。
可以考慮請求小的切圖，通過CSS控制圖片顯示位置。

3、圖片尺寸
下面一張背景圖，我們可以看到尺寸是1080X1919，然后當(dāng)前市面上Android主流機(jī)型主要為 480x800， 480x854， 540x960， 720x1280， 800x1280 。所以，為每一個(gè)移動(dòng)設(shè)備都提供一張1080X1919的圖片實(shí)在沒有必要。

4、沒有使用的資源
下面這一幅圖，在chrome DevTools中看到請求響應(yīng)并下載成功，但是在實(shí)際的H5活動(dòng)中并沒有使用過。

5、返回碼非200

非200的返回碼意味著本次請求沒有實(shí)質(zhì)性的收獲，如上圖所示的兩次非200請求返回值：
404：上圖請求圖片時(shí)出現(xiàn)404：一方面，可能圖片本身在H5中就不展示，所以這里直接去掉多余的連接就好了。另一方面，可能H5中需要該圖片，而恰好訪問結(jié)果為404，那此時(shí)就定位了一個(gè)bug 的存在。
302：請求音樂時(shí)出現(xiàn)302重定向：從圖中可以明顯看出兩次請求后才獲取到背景音樂，從用戶側(cè)可能會(huì)感知是音樂加載速度慢。
6、未使用CDN，未設(shè)置cache

如果該運(yùn)營活動(dòng)是全國性的，且用戶量很大，那么非常有可能網(wǎng)絡(luò)“邊緣”的用戶沒有辦法正常訪問該H5活動(dòng)。
7、資源未壓縮

這里詳細(xì)列出了各個(gè)沒有壓縮的圖片資源。這里要建議的圖片的壓縮，如上圖測試結(jié)果，壓縮后可以減少16K的圖片資源大小。還可以考慮是否采用圖片地圖來減少http請求。

本文轉(zhuǎn)自（）

【年末回饋?zhàn)詈笠徊ǎ珗隽燮穑蓝Y升級，還送公開課入場券，趕緊搶！】

活動(dòng)時(shí)間：12月1日-12月31日