一、測試關(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)化方案：

（2）圖片地圖：是一種小圖合并大圖的范式胖腾，和雪碧圖相似烟零，區(qū)別僅在實(shí)現(xiàn)原理上有不同，雪碧圖僅僅是通過CSS的方式來呈現(xiàn)圖片的某個(gè)局部咸作，而圖片地圖是從html代碼的方式來控制顯示區(qū)域锨阿。

（3）JS&CSS合并：將多個(gè)小的js、CSS合并成一個(gè)大的js记罚、CSS文件墅诡，間接達(dá)到減少http請求的目的。

2桐智、組件是否壓縮

<b>壓縮方法：</b>在http請求中設(shè)置所接受的壓縮方式末早，在Server端對Response資源進(jìn)行壓縮再傳給瀏覽器。一般使用GZIP設(shè)置content-Encoding字段说庭。

<b>壓縮對象：</b>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、圖片格式和大小是否合適

<b>圖片格式：</b>顯示效果較好的圖片格式中僚焦，有webp锰提、jpg和png24/32這幾種常見的圖片格式。一般來說，webp的圖片最小立肘，但在iOS或者android4.0以下的系統(tǒng)中可能會(huì)有兼容性問題需要解決边坤。
<li>JPG:</li>JPG是我們最常使用的方案，大小適中谅年，解碼速度快茧痒，兼容性問題也基本不存在，是我們在H5的應(yīng)用中使用起來性價(jià)比最高的方案融蹂。
<li>png8：</li>有些png24/32圖片本身顏色較為簡單旺订，將其轉(zhuǎn)變?yōu)閜ng8得到的顯示效果很類似，但卻能極大地減少圖片的大小超燃。Png24或png32区拳，一般來說，顯示效果肯定會(huì)比jpg和png8更好意乓，但是實(shí)際上人眼很難感知出來樱调，所以在H5應(yīng)用中要避免這種格式的大圖片。當(dāng)然bmp這種未壓縮的圖片格式就不應(yīng)該考慮届良。

<b>圖片尺寸：</b>獲取圖片尺寸時(shí)候應(yīng)該考慮圖片具體的展示場景笆凌，如當(dāng)前移動(dòng)設(shè)備中常用尺寸規(guī)格為480×800、600×1024士葫、720×1280菩颖，800×1280等，從原圖來保證圖片能夠被呈現(xiàn)为障，而不是通過代碼對圖片放大或縮小晦闰。

<b>圖片壓縮：</b>對于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é)果毁涉。具體壓縮方法如下：

/*CC的示例代碼*/
function echo(stringA,stringB){
    var hello = "你好";
    alert("hello world");
}
/*CC的示例代碼*/

第一步：“精簡”沉帮，去掉js文件中的空格、換行符贫堰、注釋等信息穆壕，使得js代碼變得緊湊而不失其語義。如：
function echo(stringA,stringB){var hello="你好"其屏；alert("hello world")};
第二步：”混淆”喇勋，將方法名和變量名用更簡短的方式來表達(dá)，如變量可以用一個(gè)字符來表示偎行。如：
function echo(c,b){var a="你好",alert("hello world")};
優(yōu)點(diǎn)：從js&CSS文件的源頭進(jìn)行壓縮川背，縮小了http傳輸過程數(shù)據(jù)大小。
缺點(diǎn)：通過兩步壓縮后蛤袒，再來閱讀js&CSS源碼是非诚ㄔ疲苦難的。并且經(jīng)過壓縮的代碼可能和另一個(gè)壓縮的代碼因變量被共用而引起語法錯(cuò)誤妙真。
最后缴允，經(jīng)過壓縮的腳本文件使用務(wù)器端GZIP來壓縮，能夠壓使文件縮得更加的淋漓盡致珍德。

7练般、是否添加緩存

緩存功能是一種減少http請求的方式，如下有兩種方式設(shè)置緩存锈候，測試時(shí)注意常用資源是否設(shè)置緩存：
<b>Cache-Control</b>
“no-cache”指示請求或響應(yīng)消息不能緩存（HTTP/1.0用Pragma的no-cache替換）

“no-store”用于防止重要的信息被無意的發(fā)布薄料。在請求消息中發(fā)送將使得請求和響應(yīng)消息都不使用緩存。

“max-age”指示客戶機(jī)可以接收生存期不大于指定時(shí)間（以秒為單位）的響應(yīng)泵琳。

“max-stale”指示客戶機(jī)可以接收超出超時(shí)期間的響應(yīng)消息都办。如果指定max-stale消息的值嫡锌，那么客戶機(jī)可以接收超出超時(shí)期指定值之內(nèi)的響應(yīng)消息。

“min-fresh” “=” delta-seconds指示客戶機(jī)可以接收響應(yīng)時(shí)間小于當(dāng)前時(shí)間加上指定時(shí)間的響應(yīng)琳钉。

<b>Expires:</b>
表示存在時(shí)間势木，允許客戶端在這個(gè)時(shí)間之前不去檢查（發(fā)請求），等同max-age的效果歌懒。但是如果同時(shí)存在啦桌，則被Cache-Control的max-age覆蓋。

<b>設(shè)置方式：</b>
通過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熙掺。
時(shí)間相關(guān)：

白屏?xí)r間：用戶首次看到網(wǎng)頁有內(nèi)容的時(shí)間，即第一次渲染流程完成時(shí)間咕宿。但是在傳統(tǒng)的采集方式里币绩，是在HTML的head標(biāo)簽結(jié)尾里記錄時(shí)間戳蜡秽，來計(jì)算白屏?xí)r間。在這個(gè)時(shí)刻缆镣，瀏覽器開始解析body標(biāo)簽內(nèi)的內(nèi)容芽突。而現(xiàn)代瀏覽器不會(huì)等待CSS樹和DOM樹（整個(gè)body標(biāo)簽解析完成）構(gòu)建完成才開始繪制，而是馬上開始顯示中間結(jié)果董瞻。所以經(jīng)常在低網(wǎng)速的環(huán)境中寞蚌，觀察到頁面由上至下緩慢顯示完，或者先顯示文本內(nèi)容后再重繪成帶有格式的頁面內(nèi)容钠糊。

首屏?xí)r間：是指用戶看到第一屏挟秤，即整個(gè)網(wǎng)頁頂部大小為當(dāng)前窗口的區(qū)域，顯示完整的時(shí)間〕椋現(xiàn)代瀏覽器處理圖片資源時(shí)是異步的艘刚，會(huì)先將圖片長寬應(yīng)用于頁面排版，然后隨著收到圖片數(shù)據(jù)由上至下繪制顯示的截珍。并且瀏覽器對每個(gè)頁面的TCP連接數(shù)限制攀甚，使得并不是所有圖片都能立刻開始下載和顯示。因此我們在dom樹構(gòu)建完成后即可遍歷獲得所有在設(shè)備屏幕高度內(nèi)的所有圖片資源標(biāo)簽笛臣，在所有圖片標(biāo)簽中添加document.onload事件云稚，在整頁加載完成（window.onLoad事件發(fā)生）時(shí)遍歷圖片標(biāo)簽并獲得之前注冊的document.onload事件時(shí)間的最大值隧饼，該最大值減去navigationStart即認(rèn)為近似的首屏?xí)r間沈堡。

完整頁面時(shí)間：整個(gè)H5頁面資源全部被下載的時(shí)間。相對于首屏?xí)r間燕雁，頁面完整下載時(shí)間往往更高诞丽，當(dāng)頁面大小恰好和窗口大小相等時(shí)，可認(rèn)為完整頁面下載時(shí)間為首屏?xí)r間拐格。首屏?xí)r間和完整頁面時(shí)間我們通過注入js代碼到webview中的方式來實(shí)現(xiàn)僧免；具體實(shí)現(xiàn)上，在WebChromeClient的onReceivedTitle事件被觸發(fā)時(shí)注入我們的js代碼捏浊，然后通過WebChromeClient的onJsPrompt事件來獲取懂衩。

首資源下載時(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)重的卡頓流出典徘。