淘寶小程序體驗優(yōu)化：數(shù)據(jù)分析和優(yōu)化實踐

作者：莫緒旻(向嶼) 2022-05-06 12:01:01

開發(fā) 新聞

體驗優(yōu)化是個老生常談的話題，如何讓小程序跑得又穩(wěn)又快，成了我們最大的挑戰(zhàn)之一。

寫在前面

如何定義好的體驗

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

為了有更立體的衡量標(biāo)準(zhǔn)，有了如下設(shè)想：頁面加載速度和流暢度提升（技術(shù)視角）-> 用戶跳失率下降（用戶視角）-> 商品曝光和點擊上漲（平臺視角）

困境

下面是一些 TOP 二、三方業(yè)務(wù)的性能數(shù)據(jù)（數(shù)據(jù)取自2020年5月），可以說比較糟糕。（“跳失”的定義為：用戶打開小程序后，頁面渲染未完成或未達到產(chǎn)生交互的條件就退出頁面）

復(fù)雜的技術(shù)架構(gòu)

小程序在邏輯/渲染分離的架構(gòu)下，保證了開放安全的同時，也引入了更大的性能挑戰(zhàn)。

三方生態(tài)的質(zhì)量和安全

小程序是淘寶開放體系中的重要一環(huán)，面向商家和外部開發(fā)者，給研發(fā)質(zhì)量保障、數(shù)據(jù)安全帶來了更大挑戰(zhàn)。

衡量指標(biāo)單一

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

破局

通過運維數(shù)據(jù)標(biāo)準(zhǔn)化，貫穿研發(fā)->發(fā)布->上線流程，形成數(shù)據(jù)閉環(huán)：

數(shù)據(jù)采集：定義采集算法、數(shù)據(jù)模型，形成一套標(biāo)準(zhǔn)化運維數(shù)據(jù)
運維平臺：連接二/三方開發(fā)者，提供數(shù)據(jù)透出和回流能力，定義監(jiān)控&卡口規(guī)則
數(shù)據(jù)分析：科學(xué)的數(shù)據(jù)分析方法論，有實驗、有數(shù)據(jù)、有證據(jù)
效能工具：打通研發(fā)基礎(chǔ)設(shè)施，賦能開發(fā)者

數(shù)據(jù)采集

T2（首屏算法）

阿里集團小程序?qū)R了首屏加載衡量口徑，采用UC內(nèi)核的T2首屏算法，T2指標(biāo)定義為從頁面開始加載到頁面首次渲染滿屏內(nèi)容的時間。簡單說，是在頁面加載的過程中，記錄所有的渲染幀，待頁面加載結(jié)束之后，回溯檢查每一幀，圖片渲染面積首次達到最大值的一幀記為T2。

小程序性能模型

為了把小程序啟動性能進行分階段拆解，定義了小程序性能模型，從小程序啟動開始到首屏渲染完成結(jié)束，拆解成了：Downloading（資源請求：元信息請求和包下載）、Launch（容器啟動和小程序Runtime啟動）、Rending（業(yè)務(wù)邏輯執(zhí)行和渲染）

同時，面向小程序開發(fā)者提供了標(biāo)準(zhǔn)的 Web API performance.mark()，支持開發(fā)者自定義打點。

通過分析各階段耗時，可以較為清晰的發(fā)現(xiàn)性能瓶頸。

數(shù)據(jù)分析和優(yōu)化實踐

篇幅有限，僅分享幾個經(jīng)典案例。

頁面性能與用戶跳失的關(guān)系

根據(jù)小程序加載性能和用戶跳失的直方圖，能更直觀的分析出小程序加載性能跟用戶跳失的關(guān)系。如下圖，可以看出當(dāng)小程序加載耗時超過2s時，跳失率程指數(shù)級增長。也正是基于這個結(jié)論，我們將小程序可交互時長的大盤目標(biāo)定為了1.8s。（其中橫軸表示可交互時長，縱軸表示跳失的用戶分布在該時間內(nèi)的占比）

小程序啟動漏斗

小程序啟動漏斗，能更直觀的分析出各階段耗時和跳失率/白屏率等指標(biāo)的關(guān)系。以下圖為例：

Downloading 請求階段耗時過長，是白屏率/跳失率的重要因素旗艦店小程序接入資源預(yù)熱，Downloading 耗時縮短50%，階段跳失/白屏收窄至0.08%內(nèi)；
業(yè)務(wù)數(shù)據(jù)請求耗時長

旗艦店小程序接入數(shù)據(jù)預(yù)取，店鋪框架數(shù)據(jù)請求耗時基本降為0，階段跳失/白屏基本降至0。

最佳實踐之：小程序引擎實例復(fù)用和預(yù)啟動

小程序進程啟動后，在空閑時機，會初始化并保留有且僅有一個通用的小程序 Engine 環(huán)境（與業(yè)務(wù)無關(guān)），直到小程序進程被殺死；
在運行過程中，小程序 Engine 實例會在3個狀態(tài)之間切換：

可運行：小程序進程啟動后，新創(chuàng)建的小程序Runtime環(huán)境為”可運行“狀態(tài)；
運行中：小程序業(yè)務(wù)啟動時，將狀態(tài)為”可運行“的實例取出使用，狀態(tài)變?yōu)椤斑\行中"；
重置中：小程序業(yè)務(wù)關(guān)閉后，將使用過的實例取出，狀態(tài)變?yōu)椤敝刂弥小?；狀態(tài)重置完畢后，變?yōu)椤笨蛇\行“狀態(tài)，供下個小程序使用。

最佳實踐之：數(shù)據(jù)預(yù)取2.0

根據(jù)小程序性能模型分析，在小程序啟動過程中，Worker啟動總是快于Render完成（Worker 處于空閑狀態(tài)），Worker 空閑時長分布如下：

可以看出，線上有92.2%的概率會發(fā)生Worker閑置，閑置時長集中在300-500ms，可以完成1-2次網(wǎng)絡(luò)請求；
閑置 Worker 具備了完備的小程序 JS 執(zhí)行能力，可在受限范圍內(nèi)執(zhí)行小程序 JSAPI，發(fā)送網(wǎng)絡(luò)請求獲取定位信息/系統(tǒng)信息等；

動態(tài)預(yù)取優(yōu)點

靈活：環(huán)境具備JS執(zhí)行能力，更靈活
豐富：提供受限的 JSAPI 調(diào)用能力
安全：支持權(quán)限管控，面向三方開放更安全

最佳實踐之：基于模板的快照渲染

快照渲染能夠提升頁面二次打開性能，但在旗艦店場景下存在如下弊端：

（1）數(shù)據(jù)真實性：快照渲染使用了上次打開時的老數(shù)據(jù)，會先展示舊內(nèi)容再刷新；

（2）磁盤占用和命中率：旗艦店屬于模板類小程序，有百萬數(shù)量級的實例化小程序，快照渲染會為每家店鋪生成不同的快照文件；龐大的基數(shù)條件下，再考慮磁盤占用建立的淘汰機制，使得快照命中率較低；

（3）長尾問題：訪問頻次較低的長尾店鋪，同一用戶二次訪問的概率較低，無法命中快照；

為解決上述問題，實現(xiàn)了”基于模板的快照渲染（Template Snapshot）“?；谀０逍〕绦蛏煽煺瘴募?shù)據(jù)剔除，在快照渲染時，配合數(shù)據(jù)預(yù)取將真實數(shù)據(jù)插入模板中。既能保證數(shù)據(jù)真實性，同時可讓所有店鋪共享同一快照文件，最大限度的提高快照命中率和降低磁盤占用。