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

語言: CN / TW / HK

測試通過發現、分析、驗證三板斧,驅動推進頁面效能優化快速有效,在業務方或其他同學提過來之前,我們都已經發現並有了分析,在優化節奏上更具有主動性。

背景

   前端效能優化的業務意義

前端的本質價值是什麼? 我認為是 給使用者創造良好的互動體驗

前端效能對使用者體驗、對業務跳失率的影響,在業界已有共識,不言而喻。

根據 Google 的資料,

如果移動站點的載入時間超過 3 秒,53% 的使用者會放棄訪問;

載入時間從 1s 延長到 3s 時,跳失率增加32%;

載入時間從 1s 延長到 5s 時,跳失率增加90%;

——使用者還沒看到辛苦優化的頁面,就走了一部分 。

(參考文末連結)

抵達率優化應該在轉化率之前, 使用者能夠正常訪問網頁,網頁的內容才能產生價值。所以在優化著陸頁內容、提高轉化率之前,要先保障抵達率。抵達率太低,哪怕頁面轉化100%,整體的轉化效果也會很差。

   測試把控難點

  1. 現在流行的,運營自行搭建頁面+自行多端投放方式,使我們的不可控。

  2. 原先發現效能問題主要通過感受+效能跑測資料,或者運營以業務要挾、或者質疑受機器等因素影響、或者相互推諉主要瓶頸點,使優化無法落實。

  3. 部分效能優化困難,影響效能點比較複雜,實行優化的收益不可預知,也阻礙了優化的落實。

前端效能優化 測試視角的解法

很多人都以為,前端效能優化,重點在“前端”優化,“測試”很難起到主導作用。試著換個角度,從整個研發團隊視角看,前端做運動員專項治理,測試做裁判員專項評測,這套機制,是否更能切實做到優化,達成的資料也更讓大家信賴?再者,測試不止侷限於此,還可做隊醫、分析師......

   可持續優化閉環

以下持續優化閉環,是我們摸索著實行了一年多,有效且高效的解法。

從上圖看,整個過程為:

step0、前端事先進行埋點,(一般前端做了sdk,直接引入即可)

step1、測試通過效能黑榜,發現最為突出的重點效能問題頁面(首屏平均時長&秒開率,PV&業務意義, 多項結合度量)

step2、協助前端一起專業分析問題頁面,找出效能瓶頸點

step3、前端更有策略地針對性治理

step4、檢視效能趨勢變化,驗證優化效果

step5、假設已達到優化預期,或者有更糟糕的頁面把之前頁面擠下去,繼續關注黑榜前列的頁面(即跳 到step1,繼續輪轉)

核心是step1.發現問題,通過持續發現問題,推動持續的優化輪轉

我們可以發現,測試通過發現、分析、驗證三板斧,驅動推進頁面效能優化。

   效果明顯

從2021年10月份開始迭代以來,共發現了8類嚴重效能問題。

包括:端外(支付寶)效能問題,外投&跨端效能問題,pha架構效能問題,運營不規範配置導致、其他業務原因導致的效能問題等。

並且快速有效,在業務方或其他同學提過來之前,我們都已經發現並有了分析,在優化節奏上更具有主動性。

效能問題的發現

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

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

   效能資料的採集

  • 幾個名詞解釋

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月中旬的資料正在持續惡化,必須要採取措施治理!

效能問題的分析

(下文以2022年2月A頻道頁面為例,均為dummy仿造後資料,也不代表整體情況)

   如何衡量效能問題嚴重性

衡量效能問題嚴重性,是為了讓大家意識到優化的必要性,以及急迫性

  • 進入效能黑榜前幾名

同性能黑榜章節,不贅述

  • 看完全載入時長分佈

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

即使不去統計,我們都能很明顯的看出來,這個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、支付寶端。

效能問題的驗證

主要通過單頁面效能趨勢分析,主要2個作用

  1. 驗證效能優化效果,做到可量化

  2. 及時洞察到頁面效能向差的趨勢,更具有主動性

   效能惡化及時反饋 

再如下圖,今年1月,一次業務需求,致使效能變差,通過每週定時效能報表傳送群裡,馬上發現。推薦大家把效能趨勢圖,定時傳送到群內,更及時發現。

   效能優化效果驗證

參考連結:https://zhuanlan.zhihu.com/p/51673262

團隊介紹

阿里拍賣-技術質量團隊,創新業務新賽道,建立和完善一套適合阿里拍賣業務的測試體系。結合搜尋,資料,演算法,導購,營銷,交易,直播等多領域的測試能力,繼續深度拓展自動化,效能測試,業務監控,精準測試,程式碼覆蓋等方面的測試價值。

✿    拓展閱讀

作者 | 悠醬(錢文玲)

編輯| 橙子君