淘寶小程式體驗優化:資料分析和優化實踐

語言: CN / TW / HK

作者:莫緒旻(向嶼)

淘寶小程式已經走過若干個雙十一,淘寶開放業務有序鋪開。體驗優化是個老生常談的話題,如何讓小程式跑得又穩又快,成了我們最大的挑戰之一。

寫在前面

如何定義好的體驗

過去我們定義這個問題,更多的是從頁面載入速度和流暢度去解釋,但這還遠遠不夠。載入速度的提升是否讓使用者更願意“玩”了,流暢度提升是否也提升了模組曝光和成交。

為了有更立體的衡量標準,有了如下設想:頁面載入速度和流暢度提升(技術視角)-> 使用者跳失率下降(使用者視角)-> 商品曝光和點選上漲(平臺視角)

困境

下面是一些 TOP 二、三方業務的效能資料(資料取自2020年5月),可以說比較糟糕。(“跳失”的定義為:使用者開啟小程式後,頁面渲染未完成或未達到產生互動的條件就退出頁面)

複雜的技術架構

小程式在邏輯/渲染分離的架構下,保證了開放安全的同時,也引入了更大的效能挑戰。

三方生態的質量和安全

小程式是淘寶開放體系中的重要一環,面向商家和外部開發者,給研發質量保障、資料安全帶來了更大挑戰。

衡量指標單一

過去我們定義這個問題,更多的是從頁面載入速度和流暢度去解釋,但這遠遠不夠。

破局

通過運維資料標準化,貫穿研發->釋出->上線流程,形成資料閉環:

  • 資料採集:定義採集演算法、資料模型,形成一套標準化運維資料
  • 運維平臺:連線二/三方開發者,提供資料透出和迴流能力,定義監控&卡口規則
  • 資料分析:科學的資料分析方法論,有實驗、有資料、有證據
  • 效能工具:打通研發基礎設施,賦能開發者

資料採集

T2(首屏演算法)

阿里集團小程式對齊了首屏載入衡量口徑,採用UC核心的T2首屏演算法,T2指標定義為 從頁面開始載入到頁面首次渲染滿屏內容的時間。簡單說,是在頁面載入的過程中,記錄所有的渲染幀,待頁面載入結束之後,回溯檢查每一幀,圖片渲染面積首次達到最大值的一幀記為T2。

小程式效能模型

為了把小程式啟動效能進行分階段拆解,定義了小程式效能模型,從小程式啟動開始到首屏渲染完成結束,拆解成了:Downloading(資源請求:元資訊請求和包下載)、Launch(容器啟動和小程式Runtime啟動)、Rending(業務邏輯執行和渲染)

同時,面向小程式開發者提供了標準的 Web API performance.mark(),支援開發者自定義打點。

通過分析各階段耗時,可以較為清晰的發現效能瓶頸。

資料分析和優化實踐

篇幅有限,僅分享幾個經典案例。

頁面效能與使用者跳失的關係

根據小程式載入效能和使用者跳失的直方圖,能更直觀的分析出小程式載入效能跟使用者跳失的關係。如下圖,可以看出當小程式載入耗時超過2s時,跳失率程指數級增長。也正是基於這個結論,我們將小程式可互動時長的大盤目標定為了1.8s。(其中橫軸表示可互動時長,縱軸表示跳失的使用者分佈在該時間內的佔比)

小程式啟動漏斗

小程式啟動漏斗,能更直觀的分析出各階段耗時和跳失率/白屏率等指標的關係。以下圖為例:

  • Downloading 請求階段耗時過長,是白屏率/跳失率的重要因素

a、旗艦店小程式接入 資源預熱,Downloading 耗時縮短50%,階段跳失/白屏收窄至0.08%內;

  • 業務資料請求耗時長

a、旗艦店小程式接入資料預取,店鋪框架資料請求耗時基本降為0,階段跳失/白屏基本降至0。

最佳實踐之:小程式引擎例項複用和預啟動

  • 小程式程序啟動後,在空閒時機,會初始化並保留有且僅有一個通用的小程式 Engine 環境(與業務無關),直到小程式程序被殺死;
  • 在執行過程中,小程式 Engine 例項會在3個狀態之間切換:

a、可執行:小程式程序啟動後,新建立的小程式Runtime環境為”可執行“狀態;

b、執行中:小程式業務啟動時,將狀態為”可執行“的例項取出使用,狀態變為“執行中";

c、重置中:小程式業務關閉後,將使用過的例項取出,狀態變為”重置中“;狀態重置完畢後,變為”可執行“狀態,供下個小程式使用。

最佳實踐之:資料預取2.0

根據小程式效能模型分析,在小程式啟動過程中,Worker啟動總是快於Render完成(Worker 處於空閒狀態),Worker 空閒時長分佈如下:

  • 可以看出,線上有92.2%的概率會發生Worker閒置,閒置時長集中在300-500ms,可以完成1-2次網路請求;
  • 閒置 Worker 具備了完備的小程式 JS 執行能力,可在受限範圍內執行小程式 JSAPI,傳送網路請求獲取定位資訊/系統資訊等;

  • 動態預取優點

a、靈活:環境具備JS執行能力,更靈活

b、豐富:提供受限的 JSAPI 呼叫能力=

c、安全:支援許可權管控,面向三方開放更安全

最佳實踐之:基於模板的快照渲染

  • 快照渲染能夠提升頁面二次開啟效能,但在旗艦店場景下存在如下弊端:

a、資料真實性:快照渲染使用了上次開啟時的老資料,會先展示舊內容再重新整理;

b、磁碟佔用和命中率:旗艦店屬於模板類小程式,有百萬數量級的例項化小程式,快照渲染會為每家店鋪生成不同的快照檔案;龐大的基數條件下,再考慮磁碟佔用建立的淘汰機制,使得快照命中率較低;

c、長尾問題:訪問頻次較低的長尾店鋪,同一使用者二次訪問的概率較低,無法命中快照;

  • 為解決上述問題,實現了”基於模板的快照渲染(Template Snapshot)“。基於模板小程式生成快照檔案並將資料剔除,在快照渲染時,配合資料預取將真實資料插入模板中。既能保證資料真實性,同時可讓所有店鋪共享同一快照檔案,最大限度的提高快照命中率和降低磁碟佔用。

工具和平臺

建立標準化運維資料,輸出到不同場景,貫穿整個研發和上線流程:

  • 工具側:提供效能除錯工具,幫助開發者快速分析和解決問題
  • 釋出卡口:設定釋出前質量卡口和靜態掃描,避免業務帶病上線
  • 線上監控:通過小程式運維平臺,承擔日常高可用資料的監控和告警職責

資料效果

經歷漫長的優化週期,資料結果上,淘寶小程式大盤T2指標由 2.7s優化至1.9s;旗艦店首屏大盤從 4s+提升至1.8s。

同時,為了驗證體驗優化對業務資料的正向效果,對旗艦店業務做了分桶實驗,資料證明也收穫了不錯的業務效果。

下圖是Top二、三方業務優化前後的資料對比:

關注【阿里巴巴移動技術】微信公眾號,每週 3 篇移動技術實踐&乾貨給你思考!