H5前端頁面性能測試

1、瀏覽器渲染引擎

瀏覽器是Html解析和頁面最終展現的工具，因此測試H5前理解瀏覽器的工做原理是必不可少的。

瀏覽器的主要功能

瀏覽器的主要功能是將用戶選擇的web資源呈現出來，它須要從服務器請求資源，並將其顯示在瀏覽器窗口中，資源的格式一般是HTML，也包括PDF、image及其餘格式。在瀏覽器組成部分中，渲染引擎是用戶直接相關，呈現用戶所需頁面的部分。因此從渲染引擎入手，瞭解HTML解析與頁面展現。

渲染引擎工做流

 

dom樹構建：從html標籤的解析開始，將各類標籤解析爲dom樹中的各個節點，標籤和dom樹的中的節點是一一對應關係。

渲染樹構建：將CSS和style標籤中的樣式信息解析爲渲染樹，渲染樹由一些包含有顏色和大小等屬性的矩形組成，它們將被按照正確的順序顯示到屏幕上。

渲染樹佈局和繪製：渲染樹肯定各個dom節點在屏幕中單確切位置，根據渲染樹中的顏色等信息繪製出網頁。

 

 

值得注意的是，這個過程是逐步完成的，爲了更好的用戶體驗，渲染引擎將會盡量早的將內容呈現到屏幕上，並不會等到全部的html都解析完成以後再去構建和佈局渲染樹。它是解析完一部份內容就顯示一部份內容，同時，可能還在經過網絡下載其他內容。

2、測試關注指標

Http相關：

一、Http請求個數

一個網頁最終到達終端用戶有80%的時間都是在js，CSS，圖片，mp3，flash等資源的http請求。另外一方面，http請求的數量也是有限制的，瀏覽器對同一個域名有鏈接數限制，不一樣瀏覽器內核、不一樣版本的請求數不盡相同，大部分的併發請求數是6個。

看來經過夠控制http請求的數量，減小http請求時間，達到減小網頁加載和呈現的時間，能帶來更好的用戶體驗。

優化方案：

雪碧圖：即CSS Sprite，也稱CSS精靈，是一種CSS圖像合併技術，該方法是將小圖標和背景圖像合併到一張圖片上，而後利用CSS的背景定位來顯示須要顯示的圖片部分。

如圖有16個icon，每一次取圖片都須要一個http請求，若是經過CSS雪碧圖將16個資源合併，再經過background-image和backgorund-position定位出雪碧圖中的小區域，那麼只須要一個http請求就能夠得到所有圖片。

圖片地圖：是一種小圖合併大圖的方式，和雪碧圖類似，區別僅在實現原理上有不一樣，雪碧圖是經過CSS的方式來呈現圖片的某個局部，而圖片地圖是從html代碼的方式來控制顯示區域。

js CSS 合併：將多個小的js、CSS合併成一個大的js、CSS文件，間接達到減小http請求的目的。

二、組件是否壓縮

 

 

壓縮方法：在http請求中設置所接受到壓縮方式，在Server端對Response資源進行壓縮再傳給瀏覽器。通常使用GZIP設置content-Encoding字段。 壓縮對象：從http請求返回資源中的html，js，CSS，xml等均可以設置壓縮，值得注意的是咱們不須要對圖片音樂等資源設置壓縮，由於這些資源自己已經壓縮過了，再次壓縮收益並不高，並且增長CPU負擔。Js，CSS咱們一般經過去掉空格和回車來壓縮，再通過GZIP壓縮，能達到良好的壓縮效果。

一般來講，組件壓縮是一種增長CPU壓縮解壓縮時間來減小網絡傳輸消耗的辦法，而且一般網絡資源較cpu資源更緊張，因此對合適的對象設置壓縮能個取得良好的收益。

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

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

圖片尺寸：這獲取圖片尺寸時候應該考慮圖片具體的展現場景，如當前移動設備中經常使用個尺寸規格爲480×800、600×102四、720×1280，800×1280等，從原圖來保證圖片可以被呈現，而不是經過代碼對圖片放大或縮小。

圖片壓縮：對於jpg，png格式圖片來講自己就已經通過了壓縮，這對於稀缺的帶寬資源是不夠的，咱們還須要更加優化的壓縮算法，經過一系列的圖片壓縮工具如TinyPNG, Smush.it能夠獲得更好的壓縮且圖片質量不變。

四、CSS放在頂部

在瀏覽器渲染過程當中談到，dom樹構建完成後。CSS要放到html代碼的開頭的head標籤結束前。若是網頁是動態生成的，那麼在head代碼完成後能夠頁面輸出，這樣瀏覽器就會更快地解析出來head中的內容，開始下載CSS文件資源。而CSS放在底部則會引發從新繪製，用戶側感覺到「閃屏」的很差體驗。

五、JS放在底部

JS在下載的時候會引發兩個問題：阻止網頁內容的展現並阻止其餘資源下載。在「減小http數量」部分中，咱們談到各類資源的下載是並行的，根據不一樣域名不一樣瀏覽器內核並行數量有所不一樣，因此下載js時候，並行下載機制失效。而且在js中可能包括document.write等改變頁面佈局的操做，因此渲染引擎會等待js下載完成再開始渲染。因此用戶側頁面加載時間會由於等待而變得更長。

六、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壓縮算來壓縮，可以壓使文件縮得更加的淋漓盡致。

七、是否添加緩存

 

爲一種減小http請求的方式，以下有兩種方式設置緩存，測試時注意經常使用資源是否請求資源時否設置緩存：

 

Cache-Control

「no-cache」指示請求或響應消息不能緩存（HTTP/1.0用Pragma的no-cache替換）

「no-store」用於防止重要的信息被無心的發佈。在請求消息中發送將使得請求和響應消息都不使用緩存。根據緩存超時

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

設置方式：經過HTTP的META設置expires和cache-control
 

八、避免非200返回值

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

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

2xx：操做成功，這類狀態代碼代表服務器成功地接受了客戶端請求。

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

4xx：客戶端錯誤，發生錯誤，客戶端彷佛有問題。

5xx：服務器錯誤，服務器因爲遇到錯誤而不能完成該請求。

因此，若是有http請求返回爲非200的狀態碼，咱們認爲這一次請求時無心義的，佔用了稀缺的網絡資源，所應該避免非200的返回狀態碼。

九、使用CDN

 

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

時間相關：

 

 

 

白屏時間：用戶首次看到網頁有內容的時間，即第一次渲染流程完成時間。

首屏時間：是指用戶看到第一屏，即整個網頁頂部大小爲當前窗口的區域，顯示完整的時間。

首資源下載時間：從開始下載到第一個資源均下載完成的時間，不包括頁面繪製時間。

總資源下載時間：從開始下載到全部資源均下載完成的時間，不包括頁面繪製時間。

用戶可操做時間：從頁面開始加載到用戶操做可響應的時間。

上述各類時間指標應根據當前H5的具體狀況，選擇合適的測試指標。

WebView相關：

在Android和IOS上測試H5性能，測試員還應該關注因加載H5而引發的app常規性能指標。

內存：加載頁面先後內存變化，可間接反映H5中資源數量和大小，如dom數量，圖片大小。

CPU：當頁面中資源樣式複雜，強調視覺效果時，測試員可觀察CPU佔用率來反映H5繪製質量。若是CPU長期處於高佔用率，可考慮下降高計算量的視覺效果等手段。

FPS：幀率尤爲在有視頻和動畫效果的H5中，測試員應該重點關注，防止嚴重的卡頓流出。

3、經常使用工具

工欲善其事，必先利其器，在作H5前端性能測試以前，選擇合適的工具能讓咱們的測試工做事半功倍。本文要提到的工具備兩類：

一類是抓包工具，如Fiddler、Charles等。這類工具不只能夠抓包，還能夠對包進行修改，動態展現瀑布流，對web進行調試。在咱們作H5前端性能測試的時候，我的以爲只要不修改包，不對H5調試，就能夠放棄使用這類工具，不是工具很差，而是大材小用。

還有一類，這裏重點提到的是如Page Speed、PCAP Web Performance Analyzer、WebPagetest這類平臺型工具。咱們能夠快捷的測試出H5前端性能中數據，視圖，並給出必定程度的優化建議。

（*以上爲我的看法，若有疏漏和錯誤，請及時指正）

以手機管家端午節運營活動H5爲例，附上上述工具測試結果頁，固然這裏僅僅是結果的羅列。具體的分析仍是須要測試人員來作，衡量是否符合當前運營需求。

WebPagetest

Page Speed：

PCAP Web Performance Analyzer：

Chrome DevTools：

常見問題舉例：

一樣以手機管家端午節運營活動H5爲例：（完成整個加載性能測試耗時只需20分鐘左右）

一、HTTP請求過多

圖爲PCAP Web Performance Analyzer解析pcap包的結果，圖中咱們能夠看出，21個http請求中，有7個是統計點發出的請求。這裏能夠考慮統計點合併上報和首屏時減小上報統計點。

二、圖片空白部分太多

這裏須要用到的圖片僅僅是做爲右上角分享，可是在咱們請求的圖片確實整張完整的圖。
能夠考慮請求小的切圖，經過CSS控制圖片顯示位置。

三、圖片尺寸

下面一張背景圖，咱們能夠看到尺寸是1080X1919，而後當前市面上Android主流機型主要爲 480x800, 480x854, 540x960, 720x1280, 800x1280 。因此，爲每個移動設備都提供一張1080X1919的圖片實在沒有必要。

四、沒有使用的資源

下面這一幅圖，在chrome DevTools中看到請求響應並下載成功，可是在實際的H5活動中並無使用過。

五、返回碼非200

非200的返回碼意味着本次請求沒有實質性的收穫，如上圖所示的兩次非200請求返回值：

404：上圖請求圖片時出現404：一方面，可能圖片自己在H5中就不展現，因此這裏直接去掉多餘的鏈接就行了。另外一方面，可能H5中須要該圖片，而剛好訪問結果爲404，那此時就定位了一個bug 的存在。

302：請求音樂時出現302重定向：從圖中能夠明顯看出兩次請求後才獲取到背景音樂，從用戶側可能會感知是音樂加載速度慢。

六、未使用CDN，未設置cache

若是該運營活動是全國性的，且用戶量很大，那麼很是有可能網絡「邊緣」的用戶沒有辦法正常訪問該H5活動。

七、資源未壓縮

這裏詳細列出了各個沒有壓縮的圖片資源。這裏要建議的圖片的壓縮，如上圖測試結果，壓縮後能夠減小16K的圖片資源大小。還能夠考慮是否採用圖片地圖來減小http請求。