一、測試關注指標
Http相關：
1、Http請求個數
有統計證明：一個網頁最終到達終端用戶有80%的時間都是js，CSS，圖片，mp3，flash等資源的http請求。另一方面，http請求的數量也是有限制的，瀏覽器對同一個域名有連接數限制，不同內核、版本的瀏覽器請求數不盡相同，大部分的并發請求數是6個。
通過夠控制http請求的數量，減少http請求時間，達到減少網頁加載和呈現的時間，能帶來更好的用戶體驗。
優化方案：
（1）雪碧圖：即CSS Sprite，也稱CSS精靈，是一種CSS圖像合并技術，該方法是將小圖標和背景圖像合并到一張圖片上，然后利用CSS的背景定位來顯示需要顯示的圖片部分。
如圖有16個icon，每一次取圖片都需要一個http請求，如果通過CSS雪碧圖將16個資源合并，再通過background-image和backgorund-position定位出雪碧圖中的小區域，那么只需要一個http請求就可以獲得全部圖片。
（2）圖片地圖：是一種小圖合并大圖的范式，和雪碧圖相似，區別僅在實現原理上有不同，雪碧圖僅僅是通過CSS的方式來呈現圖片的某個局部，而圖片地圖是從html代碼的方式來控制顯示區域。
（3）JS&CSS合并：將多個小的js、CSS合并成一個大的js、CSS文件，間接達到減少http請求的目的。
2、組件是否壓縮
<b>壓縮方法：</b>在http請求中設置所接受的壓縮方式，在Server端對Response資源進行壓縮再傳給瀏覽器。一般使用GZIP設置content-Encoding字段。
<b>壓縮對象：</b>http請求返回資源中的html，js，CSS，xml等都可以設置壓縮，值得注意的是我們不需要對圖片音樂等資源設置壓縮，因為這些資源本身已經壓縮過了，再次壓縮收益并不高，而且增加CPU負擔。Js，CSS我們通常通過去掉空格和回車來壓縮，再經過GZIP壓縮，能達到良好的壓縮效果。
通常來說，組件壓縮是一種增加CPU壓縮解壓縮時間來減少網絡傳輸消耗的辦法，并且通常網絡資源較cpu資源更緊張，所以對合適的對象設置壓縮能個取得良好的收益。
3、圖片格式和大小是否合適
<b>圖片格式：</b>顯示效果較好的圖片格式中，有webp、jpg和png24/32這幾種常見的圖片格式。一般來說，webp的圖片最小，但在iOS或者android4.0以下的系統中可能會有兼容性問題需要解決。
<li>JPG:</li>JPG是我們最常使用的方案，大小適中，解碼速度快，兼容性問題也基本不存在，是我們在H5的應用中使用起來性價比最高的方案。
<li>png8：</li>有些png24/32圖片本身顏色較為簡單，將其轉變為png8得到的顯示效果很類似，但卻能極大地減少圖片的大小。Png24或png32，一般來說，顯示效果肯定會比jpg和png8更好，但是實際上人眼很難感知出來，所以在H5應用中要避免這種格式的大圖片。當然bmp這種未壓縮的圖片格式就不應該考慮。
<b>圖片尺寸：</b>獲取圖片尺寸時候應該考慮圖片具體的展示場景，如當前移動設備中常用尺寸規格為480×800、600×1024、720×1280，800×1280等，從原圖來保證圖片能夠被呈現，而不是通過代碼對圖片放大或縮小。
<b>圖片壓縮：</b>對于jpg，png格式圖片來說本身就已經經過了壓縮，這對于稀缺的帶寬資源是不夠的，我們還需要更加優化的壓縮算法，通過一系列的圖片壓縮工具如TinyPNG, Smush.it可以得到更好的壓縮且圖片質量不變。
4、CSS放在頂部
在瀏覽器渲染過程中談到，dom樹構建完成后。CSS要放到html代碼的開頭的head標簽結束前。如果網頁是動態生成的，那么在head代碼完成后可以頁面輸出，這樣瀏覽器就會更快地解析出來head中的內容，開始下載CSS文件資源。而CSS放在底部則會引起重新繪制，用戶側感受到“閃屏”的不好體驗。
5、JS放在底部
JS在下載的時候會引起兩個問題：阻止網頁內容的展示并組織其他資源下載。在“減少http數量”部分中，我們談到各種資源的下載是并行的，根據不同域名不同瀏覽器內核并行數量有所不同，所以下載js時候，并行下載機制失效。并且在js中可能包括document.write等改變頁面布局的操作，所以渲染引擎會等待js下載完成再開始渲染。所以用戶側頁面加載時間會因為等待而變得更長。
6、JS &CSS壓縮
首先舉一個例子，相信大家在使用jquery時注意到有兩個文件jquery-1.4.2.js和 jquery-1.4.2.min.js，這里的min.js就是js方式的壓縮結果。具體壓縮方法如下：
/*CC的示例代碼*/
function echo(stringA,stringB){
var hello = "你好";
alert("hello world");
}
/*CC的示例代碼*/
第一步：“精簡”，去掉js文件中的空格、換行符、注釋等信息，使得js代碼變得緊湊而不失其語義。如：
function echo(stringA,stringB){var hello="你好"；alert("hello world")};
第二步：”混淆”，將方法名和變量名用更簡短的方式來表達，如變量可以用一個字符來表示。如：
function echo(c,b){var a="你好",alert("hello world")};
優點：從js&CSS文件的源頭進行壓縮，縮小了http傳輸過程數據大小。
缺點：通過兩步壓縮后，再來閱讀js&CSS源碼是非常苦難的。并且經過壓縮的代碼可能和另一個壓縮的代碼因變量被共用而引起語法錯誤。
最后，經過壓縮的腳本文件使用務器端GZIP來壓縮，能夠壓使文件縮得更加的淋漓盡致。
7、是否添加緩存
緩存功能是一種減少http請求的方式，如下有兩種方式設置緩存，測試時注意常用資源是否設置緩存：
<b>Cache-Control</b>
“no-cache”指示請求或響應消息不能緩存（HTTP/1.0用Pragma的no-cache替換）
“no-store”用于防止重要的信息被無意的發布。在請求消息中發送將使得請求和響應消息都不使用緩存。
“max-age”指示客戶機可以接收生存期不大于指定時間（以秒為單位）的響應。
“max-stale”指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale消息的值，那么客戶機可以接收超出超時期指定值之內的響應消息。
“min-fresh” “=” delta-seconds指示客戶機可以接收響應時間小于當前時間加上指定時間的響應。
<b>Expires:</b>
表示存在時間，允許客戶端在這個時間之前不去檢查（發請求），等同max-age的效果。但是如果同時存在，則被Cache-Control的max-age覆蓋。
<b>設置方式：</b>
通過HTTP的META設置expires和cache-control
8、避免非200返回值
每一個http請求都有一個相對于的返回狀態標志當次請求是否如期完成，如：
1xx：請求收到，這些狀態代碼表示臨時的響應。
2xx：操作成功，這類狀態代碼表明服務器成功地接受了客戶端請求。
3xx：重定向，客戶端瀏覽器必須采取更多操作來實現請求。
4xx：客戶端錯誤，發生錯誤，客戶端似乎有問題。
5xx：服務器錯誤，服務器由于遇到錯誤而不能完成該請求。
所以，如果有http請求返回為非200的狀態碼，我們認為這一次請求時無意義的，占用了稀缺的網絡資源，所應該避免非200的返回狀態碼。
9、使用CDN
CDN內容分發網絡（Content Delivery Network）將源站內容發布到最接近用戶的“邊緣”節點，使用戶可就近取得所需內容，提高用戶訪問的響應速度和成功率。解決因分布、帶寬、服務器能力帶來的訪問延遲高問題，提供一系列加速解決方案。所以，如果H5的用戶分散在全國各地，建議盡可能的將資源放到CDN。
時間相關：
白屏時間：用戶首次看到網頁有內容的時間，即第一次渲染流程完成時間。但是在傳統的采集方式里，是在HTML的head標簽結尾里記錄時間戳，來計算白屏時間。在這個時刻，瀏覽器開始解析body標簽內的內容。而現代瀏覽器不會等待CSS樹和DOM樹（整個body標簽解析完成）構建完成才開始繪制，而是馬上開始顯示中間結果。所以經常在低網速的環境中，觀察到頁面由上至下緩慢顯示完，或者先顯示文本內容后再重繪成帶有格式的頁面內容。
首屏時間：是指用戶看到第一屏，即整個網頁頂部大小為當前窗口的區域，顯示完整的時間。現代瀏覽器處理圖片資源時是異步的，會先將圖片長寬應用于頁面排版，然后隨著收到圖片數據由上至下繪制顯示的。并且瀏覽器對每個頁面的TCP連接數限制，使得并不是所有圖片都能立刻開始下載和顯示。因此我們在dom樹構建完成后即可遍歷獲得所有在設備屏幕高度內的所有圖片資源標簽，在所有圖片標簽中添加document.onload事件，在整頁加載完成（window.onLoad事件發生）時遍歷圖片標簽并獲得之前注冊的document.onload事件時間的最大值，該最大值減去navigationStart即認為近似的首屏時間。
完整頁面時間：整個H5頁面資源全部被下載的時間。相對于首屏時間，頁面完整下載時間往往更高，當頁面大小恰好和窗口大小相等時，可認為完整頁面下載時間為首屏時間。首屏時間和完整頁面時間我們通過注入js代碼到webview中的方式來實現；具體實現上，在WebChromeClient的onReceivedTitle事件被觸發時注入我們的js代碼，然后通過WebChromeClient的onJsPrompt事件來獲取。
首資源下載時間：從開始下載到第一個資源均下載完成的時間，不包括頁面繪制時間。
總資源下載時間：從開始下載到所有資源均下載完成的時間，不包括頁面繪制時間。
用戶可操作時間：從頁面開始加載到用戶操作可響應的時間。
上述各種時間指標應根據當前H5的具體情況，選擇合適的測試指標。
WebView相關：
在android和IOS上測試H5性能，測試員還應該關注因加載H5而引起的app常規性能指標。
內存：加載頁面前后內存變化，可間接反映H5中資源數量和大小，如dom數量，圖片大小。
CPU：當頁面中資源樣式復雜，強調視覺效果時，測試員可觀察CPU占用率來反映H5繪制質量。如果CPU長期處于高占用率，可考慮降低高計算量的視覺效果等手段。
FPS：幀率尤其在有視頻和動畫效果的H5中，測試員應該重點關注，防止嚴重的卡頓流出。
