如何做好H5性能優化

一、背景介紹

智能手機的普及、移動互聯網的發展、微信異軍突起，都為 H5 的發展提供了良好的環境。當前，H5 已被廣泛應用於營銷、廣告、傳播之中。而針對 H5 效率慢、體驗差的硬傷，如何做好性能測試並優化其性能就顯得尤為重要。

紅豆 Live 是微博子公司有信旗下的一款語音直播產品，有各種 H5 頁面。我們在做 H5 性能測試時進行了總結，本文將為大家詳細介紹 H5 性能測試的關注點、測試工具及常見問題。

 

二、H5 頁面的劣勢

 

HTML5 作為一門重要的開發語言，有着顯著的優勢，其開發速度快、運行效率高、安全性好、可擴展性強、開源自由等，但與手機端原生 APP 相比，H5 頁面還具有以下劣勢：

1. 不穩定性比較強，頁面跳轉時更加復雜，運行速度容易受網絡影響，很容易造成不流暢，甚至出現卡頓或卡死現象。

2. 由於瀏覽器的導航本身占用一部分屏幕空間，H5 頁面空間比 APP 小，在本身就小的移動設備屏幕中，容易造成信息記憶負擔。雖然可以利用滾屏擴大頁面，但人腦的短期記憶是不穩定的，用戶在滾動屏幕的過程中需要臨時記憶的信息越多，他們的表現就會越差。

3. 導航不明顯，原有底部導航消失，有效的導航遇到挑戰等。

4. 交互動態效果受到限制，影響一些頁面場景、邏輯的理解。

5. 功能實現相比 APP 存在差距，用戶重復使用難度大，用戶粘性差。

 

二、H5 性能優化技巧1. 代碼結構和設計 壓縮組件

 

用戶使用 H5 功能過程中，絕大多數時間都花在網絡請求上，所以減少使用緊張的網絡資源在提高性能上能取得良好的收益。組件壓縮就是一種減少網絡傳輸消耗的辦法。

從 HTTP 請求返回資源中的 HTML，JS，CSS，XML 等都可以設置壓縮。對於已經壓縮過的資源（如圖片音樂等）不需要再次壓縮，收益不高，而且增加 CPU 負擔。

JS，CSS 可以常通過去掉空格和回車來壓縮，再經過 GZIP 壓縮，能達到良好的壓縮效果。

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

 

 設計技巧

 

CSS 放在頂部、JavaScript 寫在底部或異步：DOM 樹構建完成后，CSS 要放到 HTML 代碼的開頭的 head 標簽結束前。如果網頁是動態生成的，那么在 head 代碼完成后可以頁面輸出，這樣瀏覽器就會更快地解析出來 head 中的內容，開始下載 CSS 文件資源。而 CSS 放在底部則會引起重新繪制，用戶會感受到“閃屏”的不好體驗。

 

 CSS 使用技巧

 

• 正確使用 Display 屬性，因為 Display 屬性會影響頁面的渲染

• 避免圖片和 iFrame 等空 Src

• 盡量避免重設圖片大小

• 避免 CSS 表達式

• 移除空的 CSS 規則

• 不濫用 Web 字體、Float

• 不聲明過多的 Font-Size

• 值為 0 時不需要單位

• 標准化各種瀏覽器的前綴

• 避免讓選擇符看起來像正則表達式

JS 在下載的時候會引起兩個問題：阻止網頁內容的展示並組織其他資源下載。下載 JS 時候，並行下載機制失效。並且在 JS 中可能包括 Document.write 等改變頁面布局的操作，所以渲染引擎會等待 JS 下載完成再開始渲染。用戶側頁面加載時間會因為等待而變得更長。

 

 關於緩存

 

添加緩存的最終目的是為了減少 HTTP 請求，最終達到提升性能的效果，所有靜態資源都要在服務器端設置緩存，並且盡量使用長 Cache 緩存一切可緩存的資源。

 

 

2. 網絡請求 HTTP 請求個數

 

有統計證明：一個網頁最終到達終端用戶有 80% 的時間都是在 JS，CSS，圖片，MP3，Flash 等資源的 HTTP 請求。另一方面，HTTP 請求的數量也是有限制的，瀏覽器對同一個域名有連接數限制，不同瀏覽器內核、不同版本的請求數不盡相同，大部分的並發請求數是 6 個。通過夠控制 HTTP 請求的數量，減少 HTTP 請求時間，達到減少網頁加載和呈現的時間，能帶來更好的用戶體驗。

 

 圖片格式和大小是否合適

 

圖片格式：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 開發者工具進行性能測試，該工具有以下優點：

1. 支持移動端 H5 在 PC 端遠程調試，能夠對具體的移動端設備進行測試；

2. 集成了 Page Speed；

3. 提供 Network 面板，展示瀑布流視圖，各類資源清晰羅列，還提供圖的縮略圖，方便查看圖片大小尺寸和冗余或缺失；

4. 提供 TimeLine 面板，展示 CPU、內存、FPS 等性能數據。

下面看下參考 Google 官方網站，重點介紹 Chrome 開發者工具中的 Network 和 Timeline 面板。

 

1.Network 面板

 

Network 面板可以記錄頁面上的網絡請求的詳情信息，從發起網頁頁面請求 Request 后分析 HTTP 請求后得到的各個請求資源信息（包括狀態、資源類型、大小、所用時間、Request 和 Response 等），可以根據這個進行網絡性能優化。該面板主要包括 5 大塊窗格 (Pane)：

1. Controls 控制 Network 的外觀和功能。

2. Filters 控制 Requests Table 具體顯示哪些內容。

3. Overview 顯示獲取到資源的時間軸信息。

4. Requests Table 按資源獲取的前后順序顯示所有獲取到的資源信息，點擊資源名可以查看該資源的詳細信息。

5. Summary 顯示總的請求數、數據傳輸量、加載時間信息。

 

其中 Requests Table 顯示如下信息列：

•   Name 資源名稱，點擊名稱可以查看資源的詳情情況，包括 Headers、Preview、Response、Cookies、Timing。

•   Status HTTP 狀態碼。

•   Type 請求的資源 MIME 類型。

•   Initiator 標記請求是由哪個對象或進程發起的（請求源）。•   Parser： 請求由 Chrome 的 HTML 解析器時發起的。

•   Redirect：請求是由 HTTP 頁面重定向發起的。

•   Script：請求是由 Script 腳本發起的。

•   Other：請求是由其他進程發起的，比如用戶點擊一個鏈接跳轉到另一個頁面或者在地址欄輸入 URL 地址。

•   Size 從服務器下載的文件和請求的資源大小。如果是從緩存中取得的資源則該列會顯示 (from cache)

•   Time 請求或下載的時間，從發起 Request 到獲取到 Response 所用的總時間。

•   Timeline 顯示所有網絡請求的可視化瀑布流 (時間狀態軸)，點擊時間軸，可以查看該請求的詳細信息，點擊列頭則可以根據指定的字段可以排序。

 

2.Timeline 面板

 

在 Chrome 中點擊開發者工具，打開 Timeline 面板，這個工具真的很強大，Timeline 工具欄提供了對於在裝載你的 Web 應用的過程中，時間花費情況的概覽，這些應用包括處理 DOM 事件, 頁面布局渲染或者向屏幕繪制元素。Timeline 可以通過事件，框架，和實時內存用量 3 個方面的數據來監測網頁，通過這些數據，我們可以方便的找出頁面中存在問題的地方。該面板主要包括 4 大塊窗格 (Pane)：

1. Controls 錄制開關和控制錄制過程中需要記錄哪些信息。

2. Overview 網頁性能的概要信息。

3. Flame Chart CPU 堆棧軌跡的可視化圖表 (火焰圖)。在圖表里面有 1 到 3 條虛豎線。

4. Details 當選擇一個指定的事件后，會顯示這個事件的更多信息；當沒有選擇事件時，會顯示指定的時間幀信息。Flame Chart 里面的虛豎線含義：藍色標記 DOMContentLoaded 事件；綠色標記第一次的繪制時間點；紅色代表 load 事件。

 

其中第 2 塊 Overview 顯示了網頁性能相關的概要信息，可以通過鼠標或者區域邊界上的灰色滑塊來拖出一個指定區域范圍，Flame Chart 會跟着局部放大顯示指定區域內的詳情信息。

可以通過鍵盤上的 W,S 來放大和縮小指定區域，通過 A,D 來向左或向右移動指定區域。這個窗格包含了三個圖表：

1. FPS 每秒幀數 (Frames Per Second)。綠色柱狀條越高，則每秒幀數越高。在 FPS 圖表上方的紅色塊是標記一個長幀。

2. CPU 標記 CPU 資源的使用情況，這里的面積圖標記着消耗 CPU 資源的各類事件。

3. NET 各種顏色的柱狀條分別顯示一種資源。柱狀條越長，代表獲取這個資源的時間越長。

 

CPU 面積圖中各顏色的含義：藍色代表 HTML 文件；黃色代表腳本文件；紫色代表樣式文件；綠色代表媒體文件；灰色代表其它雜項文件。NET 圖表柱狀條兩種顏色的含義：較亮的部分表示等待時間（當資源被請求時，直到第一個字節被下載的時間）；較暗的部分表示傳輸時間 (在第一個和最后一個字節被下載之間的時間)。

 

四、常見問題及優化方案

 

1. 在請求的資源中有未使用的圖片，造成不必要的資源消耗，應過濾掉，如下圖所示。

 

1. 接口請求次數太多。

 

優化方案：合並頁面的多個圖片資源，減少請求次數。通過 CSS Sprite 將直播間頁面的多個資源合並（如截圖中標注的圖片），再通過 background-image 和 backgorund-position 定位出圖中的小區域，那么只需要一個 HTTP 請求就可以獲得全部圖片。

 

1. 事件處理時間長，每項事件最好控制在 500ms 以內。

 

優化方案：

•   減少重繪和回流

•   緩存 Dom 選擇與計算

•   緩存列表.length

•   盡量使用事件代理，避免批量綁定事件

•   盡量使用 ID 選擇器

•   使用 touchstart、touchend 代替 click，因快影響速度快。

1. 幀率低。應用的幀率最好一直保持在 30-60fps，如果太低了，應用就會因為丟幀看上去混亂或者抖動。

 

優化方案：要想檢查一段時間內的繪制（paint）是另一個挑戰。如果想知道為什么某個特定的元素繪制的比較慢，可以把 DOM 樹中的部分元素設置成 display:none，將它們從布局 / 內容樹中移除，並且設置 visibility:hidden 不讓它們繪制。然后你可以用 Timeline 進行錄制以便測量，看一下繪制時間，在強制重繪模式中可以觀察（實驗性的）繪制率。（感謝 Paul 提供的竅門）

1. 點擊界面按鈕后，二級頁面彈出慢。

 

優化方案：可以調整請求的順序，由拿到數據再彈層，變成彈層的同時取數據，加快彈層展示時間.

 

五、總結

 

目前 H5 的應用非常廣泛，如何把控好 H5 的性能是一門重要的課程。從代碼設計可以優化 CSS、JS、圖片、緩存等。還可以通過 Chrome 開發者工具，監控 H5 的網絡請求和加載時間，找到性能消耗較大的根源，優化網絡請求數、網絡加載時間以及渲染優化。