作者 | 蔡媚霞 （紅豆 Live 軟體測試工程師）
編輯 | 尾尾
備註 | 本文為作者投稿， 投稿請發郵件至luna.han@infoq.com
一、背景介紹
二、H5 頁面的劣勢
HTML5 作為一門重要的開發語言， 有著顯著的優勢， 其開發速度快、運行效率高、安全性好、可擴展性強、開源自由等， 但與手機端原生 APP 相比， H5 頁面還具有以下劣勢：
不穩定性比較強， 頁面跳轉時更加複雜， 運行速度容易受網路影響， 很容易造成不流暢， 甚至出現卡頓或卡死現象。
由於流覽器的導航本身佔用一部分螢幕空間， H5 頁面空間比 APP 小， 在本身就小的移動設備螢幕中， 容易造成資訊記憶負擔。
導航不明顯， 原有底部導航消失， 有效的導航遇到挑戰等。
交互動態效果受到限制， 影響一些頁面場景、邏輯的理解。
功能實現相比 APP 存在差距， 用戶重複使用難度大， 用戶粘性差。
二、H5 性能優化技巧1. 代碼結構和設計 壓縮元件
使用者使用 H5 功能過程中， 絕大多數時間都花在網路請求上， 所以減少使用緊張的網路資源在提高性能上能取得良好的收益。 元件壓縮就是一種減少網路傳輸消耗的辦法。
從 HTTP 請求返回資源中的 HTML， JS， CSS， XML 等都可以設置壓縮。 對於已經壓縮過的資源（如圖片音樂等）不需要再次壓縮，
JS， CSS 可以常通過去掉空格和回車來壓縮， 再經過 GZIP 壓縮， 能達到良好的壓縮效果。
壓縮方法：在 HTTP 請求中設置所接受到壓縮方式， 在 Server 端對 Response 資源進行壓縮再傳給流覽器。 一般使用 GZIP 設置 content-Encoding 欄位。
設計技巧
CSS 使用技巧
正確使用 Display 屬性， 因為 Display 屬性會影響頁面的渲染
避免圖片和 iFrame 等空 Src
儘量避免重設圖片大小
避免 CSS 運算式
移除空的 CSS 規則
不濫用 Web 字體、Float
不聲明過多的 Font-Size
值為 0 時不需要單位
標準化各種流覽器的首碼
避免讓選擇符看起來像規則運算式
關於緩存
添加緩存的最終目的是為了減少 HTTP 請求， 最終達到提升性能的效果， 所有靜態資源都要在伺服器端設置緩存， 並且儘量使用長 Cache 緩存一切可緩存的資源。
2. 網路請求 HTTP 請求個數
有統計證明：一個網頁最終到達終端使用者有 80% 的時間都是在 JS， CSS， 圖片， MP3， Flash 等資源的 HTTP 請求。 另一方面， HTTP 請求的數量也是有限制的， 流覽器對同一個功能變數名稱有連接數限制， 不同流覽器內核、不同版本的請求數不盡相同， 大部分的併發請求數是 6 個。
圖片格式和大小是否合適
圖片格式：H5 中常用的圖片格式有 WebP、JPG 和 PNG8。 其中 WebP 的圖片最小， 但在 IOS 或者 Android4.0 以下的系統中可能會有相容性問題需要解決。 JPG 是最常使用的方案， 大小適中， 解碼速度快， 相容性問題也基本不存在， 在 H5 的應用中使用起來性價比最高的方案。 如果有 PNG24|32 圖片， 儘量將其轉換層 PNG8， 能極大減少圖片大小。 BMP 是未壓縮的圖片格式， 應該避免使用。
圖片尺寸：當前移動設備中常用個尺寸規格為 480×800、600×1024、720×1280， 800×1280 等， 保證提供的原圖能夠被呈現， 避免在代碼中調整圖片大小。
避免非 200 返回值
每一個 HTTP 請求都有一個相對於的返回狀態標誌當次請求是否如期完成，
1：請求收到， 這些狀態碼表示臨時的回應。
2：操作成功， 這類狀態碼表明伺服器成功地接受了用戶端請求。
3：重定向， 用戶端流覽器必須採取更多操作來實現請求。
4：用戶端錯誤， 發生錯誤， 用戶端似乎有問題。
5：伺服器錯誤， 伺服器由於遇到錯誤而不能完成該請求。
所以， 如果有 HTTP 請求返回為非 200 的狀態碼， 我們認為這一次請求時無意義的， 佔用了稀缺的網路資源， 所應該避免非 200 的返回狀態碼。
三、性能測試工具
推薦採用 Chrome 開發者工具進行性能測試， 該工具有以下優點：
支持移動端 H5 在 PC 端遠端調試， 能夠對具體的移動端設備進行測試；
集成了 Page Speed；
提供 Network 面板， 展示瀑布流視圖， 各類資源清晰羅列， 還提供圖的縮略圖， 方便查看圖片大小尺寸和冗餘或缺失；
提供 TimeLine 面板，展示 CPU、記憶體、FPS 等性能資料。
下面看下參考 Google 官方網站，重點介紹 Chrome 開發者工具中的 Network 和 Timeline 面板。
1.Network 面板
Network 面板可以記錄頁面上的網路請求的詳情資訊，從發起網頁頁面請求 Request 後分析 HTTP 請求後得到的各個請求資源資訊（包括狀態、資源類型、大小、所用時間、Request 和 Response 等），可以根據這個進行網路性能優化。該面板主要包括 5 大塊窗格 (Pane)：
Controls 控制 Network 的外觀和功能。
Filters 控制 Requests Table 具體顯示哪些內容。
Overview 顯示獲取到資源的時間軸資訊。
Requests Table 按資源獲取的前後順序顯示所有獲取到的資源資訊，點擊資源名可以查看該資源的詳細資訊。
Summary 顯示總的請求數、資料傳輸量、載入時間資訊。
其中 Requests Table 顯示如下資訊列：
• Name 資源名稱，點擊名稱可以查看資源的詳情情況，包括 Headers、Preview、Response、Cookies、Timing。
• Status HTTP 狀態碼。
• Type 請求的資源 MIME 類型。
• Initiator 標記請求是由哪個物件或進程發起的（請求源）。• Parser： 請求由 Chrome 的 HTML 解析器時發起的。
• Redirect：請求是由 HTTP 頁面重定向發起的。
• Script：請求是由 Script 腳本發起的。
• Other：請求是由其他進程發起的，比如使用者點擊一個連結跳轉到另一個頁面或者在位址欄輸入 URL 位址。
• Timeline 顯示所有網路請求的視覺化瀑布流 (時間狀態軸)，點擊時間軸，可以查看該請求的詳細資訊，點擊列頭則可以根據指定的欄位可以排序。
2.Timeline 面板
在 Chrome 中點擊開發者工具，打開 Timeline 面板，這個工具真的很強大，Timeline 工具列提供了對於在裝載你的 Web 應用的過程中，時間花費情況的概覽，這些應用包括處理 DOM 事件, 頁面配置渲染或者向螢幕繪製元素。Timeline 可以通過事件，框架，和即時記憶體用量 3 個方面的資料來監測網頁，通過這些資料，我們可以方便的找出頁面中存在問題的地方。該面板主要包括 4 大塊窗格 (Pane)：
Controls 錄製開關和控制錄製過程中需要記錄哪些資訊。
Overview 網頁性能的概要資訊。
Flame Chart CPU 堆疊軌跡的視覺化圖表 (火焰圖)。在圖表裡面有 1 到 3 條虛分隔號。
Details 當選擇一個指定的事件後，會顯示這個事件的更多資訊；當沒有選擇事件時，會顯示指定的時間幀資訊。Flame Chart 裡面的虛分隔號含義：藍色標記 DOMContentLoaded 事件；綠色標記第一次的繪製時間點；紅色代表 load 事件。
其中第 2 塊 Overview 顯示了網頁性能相關的概要資訊，可以通過滑鼠或者區域邊界上的灰色滑塊來拖出一個指定區域範圍，Flame Chart 會跟著局部放大顯示指定區域內的詳情資訊。
可以通過鍵盤上的 W,S 來放大和縮小指定區域，通過 A,D 來向左或向右移動指定區域。這個窗格包含了三個圖表：
FPS 每秒幀數 (Frames Per Second)。綠色柱狀條越高，則每秒幀數越高。在 FPS 圖表上方的紅色塊是標記一個長幀。
CPU 標記 CPU 資源的使用情況，這裡的面積圖標記著消耗 CPU 資源的各類事件。
NET 各種顏色的柱狀條分別顯示一種資源。柱狀條越長，代表獲取這個資源的時間越長。
四、常見問題及優化方案
在請求的資源中有未使用的圖片，造成不必要的資源消耗，應過濾掉，如下圖所示。
介面請求次數太多。
優化方案：合併頁面的多個圖片資源，減少請求次數。通過 CSS Sprite 將直播間頁面的多個資源合併（如截圖中標注的圖片），再通過 background-image 和 backgorund-position 定位出圖中的小區域，那麼只需要一個 HTTP 請求就可以獲得全部圖片。
事件處理時間長，每項事件最好控制在 500ms 以內。
優化方案：
• 減少重繪和回流
• 緩存 Dom 選擇與計算
• 緩存列表.length
• 儘量使用事件代理，避免批量綁定事件
• 儘量使用 ID 選擇器
• 使用 touchstart、touchend 代替 click，因快影響速度快。
幀率低。應用的幀率最好一直保持在 30-60fps，如果太低了，應用就會因為丟幀看上去混亂或者抖動。
優化方案：要想檢查一段時間內的繪製（paint）是另一個挑戰。如果想知道為什麼某個特定的元素繪製的比較慢，可以把 DOM 樹中的部分元素設置成 display:none，將它們從佈局 / 內容樹中移除，並且設置 visibility:hidden 不讓它們繪製。然後你可以用 Timeline 進行錄製以便測量，看一下繪製時間，在強制重繪模式中可以觀察（實驗性的）繪製率。（感謝 Paul 提供的竅門）
點擊介面按鈕後，二級頁面彈出慢。
優化方案：可以調整請求的順序，由拿到資料再彈層，變成彈層的同時取資料，加快彈層展示時間.
五、總結
目前 H5 的應用非常廣泛，如何把控好 H5 的性能是一門重要的課程。從代碼設計可以優化 CSS、JS、圖片、緩存等。還可以通過 Chrome 開發者工具，監控 H5 的網路請求和載入時間，找到性能消耗較大的根源，優化網路請求數、網路載入時間以及渲染優化。
方便查看圖片大小尺寸和冗餘或缺失；提供 TimeLine 面板，展示 CPU、記憶體、FPS 等性能資料。
下面看下參考 Google 官方網站，重點介紹 Chrome 開發者工具中的 Network 和 Timeline 面板。
1.Network 面板
Network 面板可以記錄頁面上的網路請求的詳情資訊，從發起網頁頁面請求 Request 後分析 HTTP 請求後得到的各個請求資源資訊（包括狀態、資源類型、大小、所用時間、Request 和 Response 等），可以根據這個進行網路性能優化。該面板主要包括 5 大塊窗格 (Pane)：
Controls 控制 Network 的外觀和功能。
Filters 控制 Requests Table 具體顯示哪些內容。
Overview 顯示獲取到資源的時間軸資訊。
Requests Table 按資源獲取的前後順序顯示所有獲取到的資源資訊，點擊資源名可以查看該資源的詳細資訊。
Summary 顯示總的請求數、資料傳輸量、載入時間資訊。
其中 Requests Table 顯示如下資訊列：
• Name 資源名稱，點擊名稱可以查看資源的詳情情況，包括 Headers、Preview、Response、Cookies、Timing。
• Status HTTP 狀態碼。
• Type 請求的資源 MIME 類型。
• Initiator 標記請求是由哪個物件或進程發起的（請求源）。• Parser： 請求由 Chrome 的 HTML 解析器時發起的。
• Redirect：請求是由 HTTP 頁面重定向發起的。
• Script：請求是由 Script 腳本發起的。
• Other：請求是由其他進程發起的，比如使用者點擊一個連結跳轉到另一個頁面或者在位址欄輸入 URL 位址。
• Timeline 顯示所有網路請求的視覺化瀑布流 (時間狀態軸)，點擊時間軸，可以查看該請求的詳細資訊，點擊列頭則可以根據指定的欄位可以排序。
2.Timeline 面板
在 Chrome 中點擊開發者工具，打開 Timeline 面板，這個工具真的很強大，Timeline 工具列提供了對於在裝載你的 Web 應用的過程中，時間花費情況的概覽，這些應用包括處理 DOM 事件, 頁面配置渲染或者向螢幕繪製元素。Timeline 可以通過事件，框架，和即時記憶體用量 3 個方面的資料來監測網頁，通過這些資料，我們可以方便的找出頁面中存在問題的地方。該面板主要包括 4 大塊窗格 (Pane)：
Controls 錄製開關和控制錄製過程中需要記錄哪些資訊。
Overview 網頁性能的概要資訊。
Flame Chart CPU 堆疊軌跡的視覺化圖表 (火焰圖)。在圖表裡面有 1 到 3 條虛分隔號。
Details 當選擇一個指定的事件後，會顯示這個事件的更多資訊；當沒有選擇事件時，會顯示指定的時間幀資訊。Flame Chart 裡面的虛分隔號含義：藍色標記 DOMContentLoaded 事件；綠色標記第一次的繪製時間點；紅色代表 load 事件。
其中第 2 塊 Overview 顯示了網頁性能相關的概要資訊，可以通過滑鼠或者區域邊界上的灰色滑塊來拖出一個指定區域範圍，Flame Chart 會跟著局部放大顯示指定區域內的詳情資訊。
可以通過鍵盤上的 W,S 來放大和縮小指定區域，通過 A,D 來向左或向右移動指定區域。這個窗格包含了三個圖表：
FPS 每秒幀數 (Frames Per Second)。綠色柱狀條越高，則每秒幀數越高。在 FPS 圖表上方的紅色塊是標記一個長幀。
CPU 標記 CPU 資源的使用情況，這裡的面積圖標記著消耗 CPU 資源的各類事件。
NET 各種顏色的柱狀條分別顯示一種資源。柱狀條越長，代表獲取這個資源的時間越長。
四、常見問題及優化方案
在請求的資源中有未使用的圖片，造成不必要的資源消耗，應過濾掉，如下圖所示。
介面請求次數太多。
優化方案：合併頁面的多個圖片資源，減少請求次數。通過 CSS Sprite 將直播間頁面的多個資源合併（如截圖中標注的圖片），再通過 background-image 和 backgorund-position 定位出圖中的小區域，那麼只需要一個 HTTP 請求就可以獲得全部圖片。
事件處理時間長，每項事件最好控制在 500ms 以內。
優化方案：
• 減少重繪和回流
• 緩存 Dom 選擇與計算
• 緩存列表.length
• 儘量使用事件代理，避免批量綁定事件
• 儘量使用 ID 選擇器
• 使用 touchstart、touchend 代替 click，因快影響速度快。
幀率低。應用的幀率最好一直保持在 30-60fps，如果太低了，應用就會因為丟幀看上去混亂或者抖動。
優化方案：要想檢查一段時間內的繪製（paint）是另一個挑戰。如果想知道為什麼某個特定的元素繪製的比較慢，可以把 DOM 樹中的部分元素設置成 display:none，將它們從佈局 / 內容樹中移除，並且設置 visibility:hidden 不讓它們繪製。然後你可以用 Timeline 進行錄製以便測量，看一下繪製時間，在強制重繪模式中可以觀察（實驗性的）繪製率。（感謝 Paul 提供的竅門）
點擊介面按鈕後，二級頁面彈出慢。
優化方案：可以調整請求的順序，由拿到資料再彈層，變成彈層的同時取資料，加快彈層展示時間.
五、總結
目前 H5 的應用非常廣泛，如何把控好 H5 的性能是一門重要的課程。從代碼設計可以優化 CSS、JS、圖片、緩存等。還可以通過 Chrome 開發者工具，監控 H5 的網路請求和載入時間，找到性能消耗較大的根源，優化網路請求數、網路載入時間以及渲染優化。