驅動頁面效能優化的3個有效策略

通過線上使用者的真實採集，並制定能反應使用者體感的指標，進行效能黑榜和全域性趨勢分析。

從重點單點角度，我們通過效能黑榜；從整體視角，我們通過整體趨勢分析。

▐    效能資料的採集

• 幾個名詞解釋

ARMS前端監控專注於對Web場景、小程式場景的監控，從頁面開啟速度（測速）、頁面穩定性（JS診斷錯誤）和外部服務呼叫成功率（API）這三個方面監測Web和小程式頁面的健康度。

SLS日誌服務為Log、Metric、Trace等資料提供大規模、低成本、實時的平臺化服務。日誌服務一站式提供資料採集、加工、查詢與分析、視覺化、告警、消費與投遞等功能。

ODPS即MaxCompute，是適用於資料分析場景的企業級SaaS模式雲資料倉庫。

FBI是阿里內的智慧大資料分析和視覺化平臺，下面的所有截圖都是在FBI平臺配置圖表而成，還未對外開放。

• 全過程

arms-sdk結合前端的自定義埋點，在海量使用者訪問的同時，就會自動上報資料到sls日誌庫，整體過程如下圖：

1. 針對H5搭建頁的埋點，使用通用方案，一次性埋點即可，前端後續無需額外埋。

2. sls日誌報表查實時資料，用於實時分析，實時驗證。

3. ODPS資料長期儲存已計算完指標的資料，用於記錄、比較、趨勢分析。

▐    效能指標的確定

• 統計範圍--使用者視角

所有前臺頁面，每個使用者每次瀏覽的有效資料（完全載入<15s 內有效）

指標的影響因子：從使用者視角，頁面流量越大，則對整體資料的影響越大（也就是權重越大）

這樣做的好處：流量越大數值越嚴重的，優化的效果（正反饋）越明顯，確定了治理效能問題的優先順序。

• 三個指標

結合天貓淘寶、以及集團其他部門的

指標名	優先順序	指標描述	指標基準	量化邏輯
可互動時間	P0	完全載入、使用者可互動時間，取平均	1500ms以下良好	使用者體感 直接指標
可互動秒開率	P2	1秒內開啟的比例	45%以上良好	使用者體感良好指標
可互動5秒以上率	P1	5秒以上異常開啟的比例	3%以下良好	使用者體感不友好指標 更關注因不友好導致跳失

▐    效能黑榜

為何要用效能黑榜來作為主要發現手段？我們通常可推理得：

1. 排在效能黑榜前列的，必然是效能問題最突出的，相對方便分析

   （可根據各自業務，加個樣本量的篩選，如我們看每日pv 10w以上的）

2. 再結合樣本量（pv正相關）資料，樣本量非常大的，效能優化的收益必然也是非常大

3. 模組化元件開發盛行的今天，優化某個模組或場景的問題，收益點不僅僅在當前頁面，也在其他用了同樣模組或場景的頁

4. 榜單形式，更能引起老闆、對應前端負責同學、對使用者體驗關注的同學的重視

▐    整體效能趨勢分析

整體趨勢分析，即是為在整體角度，看我們的頁面效能趨勢，它是重要的度量指標。

這裡我們把所有的流量都納入，沒有頁面的區分，為的是基於使用者維度，流量大的頁面權重自然會更大。

從上圖看，1月初到2月中旬的資料正在持續惡化，必須要採取措施治理！

效能問題的分析

• 看完全載入時長分佈

見下圖“可互動時長分佈圖”，一個記錄代表一個使用者。

即使不去統計，我們都能很明顯的看出來，這個A頻道頁面：

<1.5s的比例很低

1.5~3s佔比最大

>3s的比例相對而言很高，居然還有這麼高比例在8s以上？

• 看時長分佈比例

和開發說明問題嚴重性時，這個會很有代入感，比如見下圖，10%的Android使用者在4.9s以上，是不是可以認為他們大部分都跳失了？

• 看和總體資料的對比

下圖不用算都能明顯發現，秒開率和整體資料差異實在太大

▐    分析效能瓶頸-分析思路

首先要明確，效能分析主要是給相關頁面的前端、開發同學看，給關心問題的測試同學看，所以我們可以拆分的更細節、更專業。可以先分前端、後端2個大類：

▐    分析效能瓶頸-前端環節

• 分終端分析

業務因素（具體不表），分終端是重點。

從可互動時長、秒開率、3秒+率、5秒+率，分別分析，都能論證--支付寶端問題更明顯。

• 分階段分析

下圖將t1~t9 每個階段打點情況視覺化，並分析重點環節的差值（打點邏輯由前端定義）

見下圖可以明顯觀察到：

1、介面耗時太久，且2.12後變差明顯（可以去追溯下2.12發生了什麼）；

2、LBS獲取耗時很久，高於平均1倍以上，而取lbs是A頻道頁的關鍵邏輯

• 分高中低端機分析

我們根據淘寶的高中低端機評判標準，埋點獲得資料。平均時長，高中低各自佔比，以及低端時長分佈（也可選中高階）。下圖可發現，低端機比例很低（需要思考是否有必要重點優化），但低端機超過3秒以上的比例遠高於其他的（和總體的完全時間分佈對比） 。

• 其他分析

包括：機型、系統等，可做參考

▐    分析效能瓶頸-後端環節

• 後端介面分析

主要從後端維度來分析

1. 服務端鏈路邏輯，需要另做具體分析

2. 分頁面的處理邏輯，需要結合業務邏輯來看

這裡可見，下圖儘管是開始發起請求-》收到請求的全過程，但也嚴重超標（幾乎是標準值的2倍）

• 網路傳輸消耗分析

整個介面過程：

請求連線(apiConnect)--》服務端處理(apiRequest)--》資料下載(apiResponse)

細節不表了

▐    分析結論關鍵思路

1. 資料差值越大的，樣本量越多的，效能資料優化越明顯

2. 結合業務意義

3. 為前端分析提供方向，更細節分析，還是要依賴前端的專業分析

還是以A頻道為例，從資料差值看，介面和lbs，和均值差異最大。從樣本量看，支付寶流量佔有一定比例，因此，我們優化的重點在：介面、LBS、支付寶端。

效能問題的驗證