支付寶小程序 性能

1. 首屏時間

首屏內(nèi)容全部顯示出來的時間，代表了用戶可以感受到的頁面加載完成、可進行交互的時間，耗時過長會導(dǎo)致用戶看到的都是白屏或者內(nèi)容有缺失，用戶會一直等待內(nèi)容加載完成。建議檢查加載過程中的所有操作，分析是否存在請求數(shù)據(jù)耗時過長或者一次性渲染數(shù)據(jù)過大的情況。

得分條件：首屏時間不超過 4500ms

2. 渲染時間

渲染界面的耗時過長會讓用戶覺得卡頓，體驗較差，出現(xiàn)這一情況時，需要校驗下是否同時渲染的區(qū)域太大。

得分條件：渲染時間不超過 500ms

3. setData 調(diào)用頻率

避免頻繁觸發(fā) setData 或者 $spliceData。需要頻繁觸發(fā)重新渲染時，避免使用頁面級別的 setData 和 $spliceData， 將這一塊封裝成自定義組件，然后使用組件級別的 setData 或 $spliceData 觸發(fā)組件重新渲染。長列表數(shù)據(jù)觸發(fā)渲染時，使用 $spliceData 多次追加數(shù)據(jù)，而不用傳遞整個列表。復(fù)雜頁面建議封裝成自定義組件，減少頁面級別的 setData。詳情參考 優(yōu)化 setData 邏輯方案明細。

得分條件：每秒調(diào)用 setData 的次數(shù)不超過 20 次

4. setData 數(shù)據(jù)大小

setData 數(shù)據(jù)不宜過大，避免一次性傳遞過長的列表。 首屏請勿一次性構(gòu)造太多節(jié)點，服務(wù)端可能一次請求傳遞大量數(shù)據(jù)，請勿一次性 setData，可先 setData 一部分數(shù)據(jù)，然后等待一段時間（比如 400ms，具體需要業(yè)務(wù)調(diào)節(jié)）再調(diào)用 $spliceData 將其他數(shù)據(jù)傳輸過去。

得分條件：setData 的數(shù)據(jù)在 JSON.stringify 后不超過 256KB

5. AXML節(jié)點數(shù)

建議一個頁面使用少于 1000 個節(jié)點，節(jié)點樹深度少于 30 層，子節(jié)點數(shù)不大于 60 個，一個過大的 DOM 樹會引起內(nèi)存消耗增長，樣式計算時間過長，與復(fù)雜的樣式規(guī)則相結(jié)合可能會嚴重減慢渲染速度。

得分條件：頁面AXML節(jié)點少于 1000 個，節(jié)點樹深度少于 30 層，子節(jié)點數(shù)不大于 60 個

6. JS 函數(shù)耗時

頁面打開期間調(diào)用的 JS 函數(shù)較多，如果多個函數(shù)執(zhí)行耗時都較長，串行起來會更長，嚴重影響用戶體驗，因此建議對耗時較長的函數(shù)進行優(yōu)化。

得分條件：JS 函數(shù)耗時都小于 100ms

7. 請求耗時

請求的耗時太長會讓用戶一直等待甚至離開，應(yīng)優(yōu)化好服務(wù)器處理時間，可減少回包大小，可服務(wù)端 rpc/mtop/http 等網(wǎng)絡(luò)請求預(yù)加載，讓請求快速響應(yīng)。

得分條件：網(wǎng)絡(luò)請求都在 1 秒內(nèi)返回結(jié)果

8. 網(wǎng)絡(luò)請求頻率

短時間內(nèi)發(fā)起太多請求會觸發(fā)小程序并行請求數(shù)量的限制，同時太多請求也可能導(dǎo)致加載慢等問題，應(yīng)合理控制請求數(shù)量，甚至做請求的合并等。

得分條件：每秒通過 my.request 發(fā)起的請求數(shù)不超過 10 個

9. 圖片請求頻率

短時間內(nèi)發(fā)起太多圖片請求會觸發(fā)瀏覽器并行加載的限制，可能導(dǎo)致圖片加載慢。應(yīng)控制并發(fā)加載數(shù)量，可考慮使用雪碧圖技術(shù)或在屏幕外的圖片使用懶加載。

得分條件：每秒發(fā)起的圖片請求數(shù)不超過 20 個

10. JSAPI 調(diào)用耗時

JSAPI 調(diào)用耗時過長，會影響 JSAPI 調(diào)用性能，應(yīng)縮短單個 API 接口的耗時時長。

得分條件：JSAPI 單次調(diào)用耗時都小于 1 秒

11. 同步 JSAPI 調(diào)用

同步 JSAPI 的調(diào)用過多將造成進程的阻塞，影響后續(xù)業(yè)務(wù)邏輯的執(zhí)行。建議盡量避免同步調(diào)用，getSystemInfo、getStorage、getLocation、getCities 是同步調(diào)用的高發(fā)區(qū)。

得分條件：每個頁面中所有同步 JSAPI 調(diào)用累計總耗時小于1秒

12. JSAPI 重復(fù)調(diào)用

多次調(diào)用同一個 JSAPI，會增加無用耗時，應(yīng)減少單頁面同一 JSAPI 調(diào)用次數(shù)，采用緩存方式處理前一執(zhí)行接口后的結(jié)果數(shù)據(jù)，減少調(diào)用次數(shù)。

得分條件：同一個 JSAPI 的調(diào)用次數(shù)小于 20 次

13. 避免加載屏幕外圖片

加載當前屏幕中暫時不需要展示的圖片，會影響頁面加載耗時，增大內(nèi)存消耗，建議分屏懶加載。

得分條件：沒有加載當前屏幕不需要顯示的圖片

14. 圖片緩存

開啟 HTTP 緩存控制后，下一次加載同樣的圖片，會直接從緩存讀取，大大提升加載速度。

得分條件：所有圖片均開啟 HTTP 緩存

15. 圖片大小

圖片過大會影響包資源大小和加載耗時，應(yīng)避免使用大圖，合理壓縮圖片尺寸，圖片格式建議轉(zhuǎn)化成 SVG/webp，必要的大圖從 CDN 渠道上傳。

得分條件：圖片小于 70KB

16. 圖片尺寸

圖片太大而有效顯示區(qū)域較小時會增加內(nèi)存的消耗，應(yīng)根據(jù)顯示區(qū)域大小合理控制圖片大小。

得分條件：圖片寬高都不超過實際顯示寬高的 3 倍

17. 避免重復(fù)請求

發(fā)起請求總會讓用戶等待，可能造成不好的體驗，應(yīng)盡量避免多余的請求，比如對同樣的請求進行緩存。

得分條件：不存在重復(fù)請求同一資源的情況

18. 頁面請求域名收斂

頁面多個請求的域名建議盡量收斂在一起，如果域名太過分散，DNS 和鏈接復(fù)用率低，影響資源的加載速度，同時也需要考慮同域資源是否有并行加載的能力。

得分條件：頁面前 6 個請求的域名總數(shù)占比超過 90%

19. 首頁流量消耗

應(yīng)避免頁面加載對用戶造成過大的流量開銷，可以考慮使用資源合并、壓縮等技術(shù)方案來降低流量開銷。

得分條件：首頁首次打開總流量消耗不超過 4M

20. 圖片壓縮

圖片建議使用 webp、hevc 等壓縮格式，這樣不僅能提升網(wǎng)絡(luò)傳輸效率和加載體驗，同時也可以減少內(nèi)存消耗和包體積。

得分條件：webp、hevc 圖片占比不低于 60.0%

21. 文本資源壓縮

建議使用 gzip/deflate 等壓縮技術(shù)來降低文件的網(wǎng)絡(luò)傳輸負載，以提升資源傳輸速度。

得分條件：文本資源均使用了 gzip/deflate 壓縮