如何打造小程序體驗評分滿分- 京喜小程序優化實踐

背景

體驗評分 Audits 是微信開發者工具內置的一項功能，會在小程序運行過程當中實時檢查，分析出一些可能致使體驗很差的地方，而且定位出哪裏有問題，以及給出一些優化建議。

京喜小程序做爲京東戰略級業務，擁有千萬級別的流量入口，通過長時間的業務迭代，代碼邏輯已經十分複雜臃腫，有迫切的性能優化需求。所以，結合體驗評分功能，以京喜首頁作試點，咱們進行了一次體驗評分的優化實踐。目的是探索小程序體驗評分的指標原則：拿到100分的小程序應該是什麼樣子的；同時但願藉此給項目優化提供更多思路。

我會按照「瞭解首頁評分現狀，分析扣分項規則，解決扣分項」這個思路來介紹，就讓咱們開始吧～

京喜首頁評分現狀

打開小程序開發者工具-調試器-Audits，點擊運行，操做頁面滾一滾點一點，而後點擊結束。

評分結果會根據評測頁面內容差別、操做習慣、有無緩存有必定浮動，下圖是京喜首頁的一次評分：總分68，性能、體驗、最佳實踐都有扣分，合計8項扣分項，後面咱們來逐條分析這些扣分項。

扣分項分析和優化

一、使用了過大的 WXML 節點數目

得分標準：頁面 WXML 節點少於 1000 個，節點樹深度少於 30 層，子節點數不大於 60 個。

頁面節點指標的意義在於，過大的節點數，過多過深的節點組成，都會增長內存使用，樣式重排時間更長，影響體驗。

現有節點2500+，想要進行優化，首先須要瞭解頁面各個模塊的節點數分佈。

如何統計每一個模塊的節點數呢？可使用「控制變量法」，利用性能評測工具中，節點數超過1000時會列出節點總數的能力，咱們能夠在總指標超過1000的狀況下，每次隱藏一個模塊：

​ 目標模塊節點數 = 原總節點數 - 當前節點數

（實測節點數會有小範圍浮動，能夠測3次取平均值）

首頁的模塊分析圖以下：

​ （第一屏） （第二屏）

簡化數據以下：

觀察列表能夠獲得兩個信息：首頁分爲展現狀態互斥的第一屏和第二屏；列表模塊的節點數是大頭。

所以，咱們獲得優化的兩個方向：

• 頁面元素按需加載，不展現時不渲染
• 長列表減小元素個數

第一個優化項能夠經過變量控制組件顯示隱藏，按需加載卸載。

第二個優化項首先想到的是減小列表接口分頁數值，好比一次請求20條數據改成請求5條。可是若是接口不支持自定義分頁，還能夠實現更小的分頁拉取嗎？

那就本身寫一個分頁方法的代理吧～

思路以下：

上方爲原始請求，每次20條數據，下方爲代理請求的實現，每次返回5條。灰色虛線框是真實的請求數據動做，經過維護一個全量數據，須要哪頁取哪頁，這是示例代碼：

經過以上兩個優化，能夠成功的把首頁的頁面節點數瘦身一下了，最後咱們成功達到 wxml 節點總數不大於1000的目標。

二、存在圖片太大而有效顯示區域較小

得分標準：圖片寬高乘積 <= 實際顯示寬高乘積 * (設備像素比 ^ 2)

簡單理解是圖片尺寸太大而展現尺寸過小，致使浪費網絡請求時間和內存資源。

解決方案：cdn服務商通常都支持經過參數獲取不一樣尺寸的圖片，前端能夠包裝一個公共方法，根據頁面元素尺寸拉取合適大小的圖片。

此外，補充一下圖片體積的內容，除了關注圖片尺寸，具體的體積大小其實更值得關注，有如下兩個點能夠了解下：

• 圖片類型的選擇大有文章，jpg/png/gif 還有 webp 應該怎麼選呢？先放一張 google 的圖

  

  這張圖裏未考慮 webp，加上 webp 其餘類型競爭力瞬間不足了，移動端 androd 支持率基本可用，能夠考慮根據設備類型漸進式使用：

  

• 利用一些壓縮技術對圖片進行壓縮，png 推薦 https://tinypng.com/ ，壓縮尺寸可觀，但對圖片顯示質量影響甚微。

三、存在可點擊元素的響應區域太小

得分標準：可點擊元素的寬高都不小於 20px

移動端操做全靠手指，太小的交互區域會帶來很差的體驗，能夠經過增大元素響應熱區的方式來優化，如下方式均可以：

• padding
• 透明的border
• box-shadow

四、對網絡請求作必要的緩存

得分標準：3 分鐘之內同一個url請求不出現兩次回包大於 128KB 且如出一轍的內容

這一項的理由是，發起網絡請求總會讓用戶等待，可能形成很差的體驗，應儘可能避免多餘的請求，好比對一樣的請求進行緩存。

優化方式：

• 善用小程序的 storage 能力，作好更新和過時管理後，儘量緩存請求到的數據。
• 針對確實須要屢次請求的日誌類接口，能夠經過在參數內添加隨機數或者時間戳的方式進行區分，避免誤判。

五、存在短期內發起太多的請求

得分標準：經過wx.request發起的耗時超過 300ms 的請求併發數不超過 10 個。

不一樣於上一項，這一項關注的是接口併發數：

• wx.request （HTTP 鏈接）的最大併發限制是 10 個
• wx.connectSocket （WebSocket 鏈接）的最大併發限制是 5 個

優化方式：

• 計算邏輯後移， 接口聚合
• 對於職責相似的網絡請求，最好採用節流的方式，先在必定時間間隔內收集數據，再合併到一個請求體中發送給服務端

六、存在未綁定在wxml上的變量

得分標準：setData傳入的全部數據都在模板渲染中有相關依賴

這一項考察的是 data 冗餘的問題，小程序設計了渲染和邏輯分離的雙線程，兩邊通信經過 evaluateJavascript 轉換字符串再進行拼接實現，須要很是當心兩個線程之間通信的數據量。所以，未綁定wxml的變量，最好優化成不使用 setData。

根據使用場景，能夠作的優化有：

• 與頁面展現無關的內部變量，能夠掛載在組件實例上，好比維護一個 this.privateData 對象
• 使用小程序新版本支持的「純數據字段」：該字段不會被傳遞到 wxml 內，配置正則劃定它的匹配範圍，能夠正常使用 setData 方法，具體用法參見文檔：https://developers.weixin.qq....

可是，若是你像我同樣遇到上面策略沒法覆蓋的場景呢？

• 須要修改舊代碼，配置純數據字段的正則影響太大
• 京喜首頁使用了 Taro 作多端適配，Taro 編譯複雜邏輯的數組後會出現「影子變量」去代理邏輯，本來的數組變量被架空致使扣分

那麼還有一個終極 hack 的方法：

這樣 list 會被判斷爲有綁定節點，就不會扣分了

七、發起太多的圖片請求

得分標準：同域名耗時超過 100ms 的圖片請求併發數不超過 20 個

最後這一項也是圖片相關，發起太多圖片請求會觸發瀏覽器並行加載的限制，可能致使圖片加載慢，用戶一直處於等待中。

優化方式：

• 雪碧圖
• 圖片懶加載：小程序 Image 組件支持經過配置 lazy-load 參數來實現懶加載（https://developers.weixin.qq.... ），具體斷定邏輯是圖片進入上下三屏就開始加載。若是須要更可控的實現，能夠本身構建組件來處理。

總結

作完這些優化，再測一下體驗評分：

以上就是京喜首頁在小程序體驗評分優化方面進行的實踐內容了。

總結一下，小程序性能評分能夠從指標和實際數據上給咱們的項目優化提供一些建議，本文主要從評分角度去分析了各類優化可能，但願能爲各位小程序開發者帶來參考價值。

參考資料

[1] 小程序開發文檔：https://developers.weixin.qq....

[2] Images: Your easiest page speed win: https://searchengineland.com/...

[3] Tiny Png: https://tinypng.com/

---

歡迎關注凹凸實驗室博客：aotu.io

或者關注凹凸實驗室公衆號（AOTULabs），不定時推送文章。