前幾日作者在掘金上看到了【微信小程序性能優(yōu)化】這篇文章,當(dāng)時(shí)心想這個(gè)團(tuán)隊(duì)做的事情和我們方向很相似,仔細(xì)一看原來是微信公開課上小程序?qū)?chǎng)中“小程序性能優(yōu)化”模塊的記錄,而其中我們提出的建議(獨(dú)立分包)也即將發(fā)布。借著這個(gè)機(jī)會(huì),我們也決定把在掃碼付小程序中的一些優(yōu)化實(shí)踐分享出來。作者:@陳小二@simpxu
美團(tuán)掃碼付小程序是一款面向C端消費(fèi)者推出的線下收單業(yè)務(wù)。它寄托在美團(tuán)小程序下,在實(shí)際場(chǎng)景中,用戶先使用微信掃一掃掃描商家二維碼,接著調(diào)起掃碼付小程序,進(jìn)入支付頁后輸入金額向商家完成商品支付。
我們一直在做一件事情:提升掃碼付小程序的支付轉(zhuǎn)化率。這里所提的支付轉(zhuǎn)化率指:整個(gè)業(yè)務(wù)流程中用戶成功支付到掃碼的占比。支付轉(zhuǎn)化率與掃碼付業(yè)務(wù)來講,百分比越高,掃碼付業(yè)務(wù)的營業(yè)額收入越高,帶來的收益是成正比的。
而這部分轉(zhuǎn)化率流失的影響,我們認(rèn)為包含兩個(gè)部分:
對(duì)于小程序開發(fā)者而言,掃碼到小程序調(diào)起這個(gè)環(huán)節(jié)是黑盒的,我們無法得知此處的細(xì)節(jié)。而我們?cè)趻叽a付小程序中嘗試和微信的同學(xué)做了一次梳理,發(fā)現(xiàn)掃碼付小程序在外部環(huán)節(jié)的丟失率較高,查詢數(shù)據(jù)發(fā)現(xiàn)其中大部分用戶手動(dòng)點(diǎn)擊了右上角的退出。從業(yè)務(wù)出發(fā),用戶使用掃碼付可以認(rèn)為用戶是有強(qiáng)需求進(jìn)行支付,能夠造成用戶手動(dòng)點(diǎn)擊退出的行為部分原因可能來自于等待時(shí)間較長,而在這個(gè)環(huán)節(jié)對(duì)時(shí)間造成影響更多的是資源準(zhǔn)備,即小程序代碼下載或者更新的行為。
影響下載和更新時(shí)間可能的因素有:
用戶網(wǎng)絡(luò)是我們無法控制的,只能嘗試從代碼包開始下手。而在當(dāng)時(shí)未使用分包的情況下,我們的主包大小約3M,意味著新用戶和無緩存小程序用戶均需要在首次使用時(shí)等待下載3M左右的包大小,在這種情況下雖然用戶享受了小程序離線緩存包的福利,卻丟失了大部分新用戶的體驗(yàn)。于是我們嘗試從包代碼大小做了一些優(yōu)化:
在做了這些事情后,掃碼付分包從原先的整包3M縮減到了361k(主包300k+分包61),而外部環(huán)節(jié)的轉(zhuǎn)化率也提升了3%。雖然轉(zhuǎn)化率提升了,但前置環(huán)節(jié)的轉(zhuǎn)化率仍然有部分丟失,理論上繼續(xù)縮減300k的主包能有效提升,但由于業(yè)務(wù)性質(zhì)的原因無法再繼續(xù)縮減,于是我們向微信小程序提出了獨(dú)立分包的概念:用戶在使用獨(dú)立分包時(shí)無需下載主包。通過獨(dú)立分包加載,程序使用期間下載更新階段只需要加載61k的分包大小,目前這個(gè)功能還在內(nèi)測(cè)階段,掃碼付小程序也在作為第一批的內(nèi)測(cè)用戶進(jìn)行體驗(yàn),優(yōu)化效果在之后的實(shí)踐中我們也會(huì)分享出來。
在進(jìn)入小程序到支付這個(gè)環(huán)節(jié),屬于我們的業(yè)務(wù)流程。在這個(gè)環(huán)節(jié)中的轉(zhuǎn)化率丟失雖然是我們能掌控的,但我們并無頭緒,所以我們做了一些數(shù)據(jù)監(jiān)控來尋求方法:
日常監(jiān)控中,我們也發(fā)現(xiàn)了一些問題,例如接口調(diào)用超時(shí)、接口調(diào)用失敗,這些問題會(huì)導(dǎo)致頁面流程終止。針對(duì)這些問題,做了一些優(yōu)化:
自有的接口請(qǐng)求異常
小程序API調(diào)用異常
對(duì)于這兩類異常,在接口超時(shí)、調(diào)用失敗時(shí)采取重試。而為了避免在極端情況下服務(wù)端流量陡增、峰值倍數(shù)增加,頁面的可重試次數(shù)會(huì)在前置獲取全局配置時(shí)根據(jù)“可重試次數(shù)”控制,并且每次重試需要在一段時(shí)間后用戶手動(dòng)觸發(fā)。超過重試次數(shù)時(shí),則流程終止。
前面我們也提到,對(duì)于小程序開發(fā)者而言,掃碼到小程序調(diào)起這個(gè)環(huán)節(jié)是黑盒的,我們開發(fā)者無法得知此處的細(xì)節(jié),所以說在監(jiān)控外部環(huán)節(jié)這方面我們開發(fā)者似乎可做的事情屈指可數(shù)。但是,不知道細(xì)心的同學(xué)有沒有發(fā)現(xiàn),微信在每次掃碼后會(huì)給我們?cè)趒uery參數(shù)上附帶一個(gè)scancode_time字段。其實(shí)這個(gè)字段表示的是用戶在使用掃一掃時(shí)微信服務(wù)端記錄的時(shí)間,所以基于這個(gè)字段的考量,我們做了如下嘗試,針對(duì)以下兩個(gè)參數(shù)值分別做了實(shí)時(shí)監(jiān)控:
但由于我們掃碼付小程序的特殊應(yīng)用場(chǎng)景就是為了保障用戶進(jìn)行快速可靠的支付,既然在外部環(huán)節(jié)可控度不高,那是不是可以考慮在內(nèi)部的業(yè)務(wù)流程方面把監(jiān)控統(tǒng)計(jì)做的細(xì)粒度一點(diǎn),做到能對(duì)每一個(gè)可能影響到支付的環(huán)節(jié)有數(shù)據(jù)可循呢?所以我們針對(duì)這個(gè)方向,區(qū)別于傳統(tǒng)的pv、uv統(tǒng)計(jì),對(duì)業(yè)務(wù)上報(bào)做了如下分類:
基于上述方案的探索,我們小組基本上做到了對(duì)可能影響支付環(huán)節(jié)的某些業(yè)務(wù)指標(biāo)的把控。從而在下一步,可以針對(duì)每個(gè)潛在的可優(yōu)化點(diǎn)做進(jìn)一步思考與考量,作出及時(shí)的策略優(yōu)化與更新。
工作日 8:30-12:00 14:30-18:00
周六及部分節(jié)假日提供值班服務(wù)