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、元件是否壓縮

壓縮方法：在http請求中設定所接受到壓縮方式，在Server端對Response資源進行壓縮再傳給瀏覽器。一般使用GZIP設定content-Encoding欄位。

壓縮物件：從http請求返回資源中的html，js，CSS，xml等都可以設定壓縮，值得注意的是我們不需要對圖片音樂等資源設定壓縮，因為這些資源本身已經壓縮過了，再次壓縮收益並不高，而且增加CPU負擔。Js，CSS我們通常通過去掉空格和回車來壓縮，再經過GZIP壓縮，能達到良好的壓縮效果。

通常來說，元件壓縮是一種增加CPU壓縮解壓縮時間來減少網路傳輸消耗的辦法，並且通常網路資源較cpu資源更緊張，所以對合適的物件設定壓縮能個取得良好的收益。

3、圖片格式和大小是否合適

圖片格式：顯示效果較好的圖片格式中，有webp、jpg和png24/32這幾種常見的圖片格式。一般來說，webp的圖片最小，但在iOS或者android4.0以下的系統中可能會有相容性問題需要解決。

• JPG:JPG是我們最常使用的方案，大小適中，解碼速度快，相容性問題也基本不存在，是我們在H5的應用中使用起來價效比最高的方案。

• png8：有些png24|32圖片本身顏色較為簡單，將其轉變為png8得到的顯示效果很類似，但卻能極大地減少圖片的大小。Png24或png32，一般來說，顯示效果肯定會比jpg和png8更好，但是實際上人眼很難感知出來，所以在H5應用中要避免這種格式的大圖片。當然bmp這種未壓縮的圖片格式就不應該考慮。

圖片尺寸：這獲取圖片尺寸時候應該考慮圖片具體的展示場景，如當前移動裝置中常用個尺寸規格為480×800、600×1024、720×1280，800×1280等，從原圖來保證圖片能夠被呈現，而不是通過程式碼對圖片放大或縮小。

圖片壓縮：對於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方式的壓縮結果。具體壓縮方法如下：

第一步：“精簡”，去掉js檔案中的而空格和換行符和註釋等資訊，使得js程式碼變得緊湊而不失其語義。如：

第二步：”混淆”，將方法名和變數名用更簡短的方式來表達，如變數可以用一個字元來表示。如：

優點：從js&CSS檔案的源頭進行壓縮，縮小了http傳輸過程資料大小。

缺點：通過兩步壓縮後，再來閱讀js&CSS原始碼是非常苦難的。並且經過壓縮的程式碼可能和另一個壓縮的程式碼因變數被共用而引起語法錯誤。

最後，經過壓縮過的指令碼檔案使用務器端設定GZIP壓縮算來壓縮，能夠壓使檔案縮得更加的淋漓盡致。

7、是否新增快取

為一種減少http請求的方式，如下有兩種方式設定快取，測試時注意常用資源是否請求資源時否設定快取：

Cache-Control

“no-cache”指示請求或響應訊息不能快取（HTTP/1.0用Pragma的no-cache替換）

“no-store”用於防止重要的資訊被無意的釋出。在請求訊息中傳送將使得請求和響應訊息都不使用快取。根據快取超時

“max-age”指示客戶機可以接收生存期不大於指定時間（以秒為單位）的響應。

“max-stale”指示客戶機可以接收超出超時期間的響應訊息。如果指定max-stale訊息的值，那麼客戶機可以接收超出超時期指定值之內的響應訊息。

“min-fresh” “=” delta-seconds指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。

Expires表示存在時間，允許客戶端在這個時間之前不去檢查（發請求），等同max-age的效果。但是如果同時存在，則被Cache-Control的max-age覆蓋。

設定方式：通過HTTP的META設定expires和cache-control

8、避免非200返回值

每一個http請求都有一個相對於的返回狀態標誌當次請求是否如期完成，如：

1xx：請求收到，這些狀態程式碼表示臨時的響應。

2xx：操作成功，這類狀態程式碼表明伺服器成功地接受了客戶端請求。

3xx：重定向，客戶端瀏覽器必須採取更多操作來實現請求。

4xx：客戶端錯誤，發生錯誤，客戶端似乎有問題。

5xx：伺服器錯誤，伺服器由於遇到錯誤而不能完成該請求。

所以，如果有http請求返回為非200的狀態碼，我們認為這一次請求時無意義的，佔用了稀缺的網路資源，所應該避免非200的返回狀態碼。

9、使用CDN

CDN內容分發網路（Content Delivery Network）將源站內容釋出到最接近使用者的“邊緣”節點，使使用者可就近取得所需內容，提高使用者訪問的響應速度和成功率。解決因分佈、頻寬、伺服器能力帶來的訪問延遲高問題，提供一系列加速解決方案。所以，如果H5的使用者分散在全國各地，建議儘可能的將資源放到CDN，如騰訊雲CDN。

時間相關：

白屏時間：使用者首次看到網頁有內容的時間，即第一次渲染流程完成時間。但是在傳統的採集方式裡，是在HTML的head標籤結尾裡記錄時間戳，來計算白屏時間。在這個時刻，瀏覽器開始解析body標籤內的內容。而現代瀏覽器不會等待CSS樹和DOM樹（整個body標籤解析完成）構建完成才開始繪製，而是馬上開始顯示中間結果。所以經常在低網速的環境中，觀察到頁面由上至下緩慢顯示完，或者先顯示文字內容後再重繪成帶有格式的頁面內容。

如上通過 WebPagetest 檢視分析發現，白屏時間和最後一個資源解析完成時間相同，因為瀏覽器只有載入並解析完頭部資源才會真正渲染頁面，也印證了上面首屏時間採集的原理。

首屏時間：是指使用者看到第一屏，即整個網頁頂部大小為當前視窗的區域，顯示完整的時間。現代瀏覽器處理圖片資源時是非同步的，會先將圖片長寬應用於頁面排版，然後隨著收到圖片資料由上至下繪製顯示的。並且瀏覽器對每個頁面的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中，測試員應該重點關注，防止嚴重的卡頓流出。