背景

體驗評分 Audits 是微信開發者工具内置的一項功能，會在小程序運行過程中(zhōng)實時檢查，分析出一些可(kě)能導緻體驗不好的地方，并且定位出哪裡有問(wèn)題，以及給出一些優化建議。

京喜小程序作為京東戰略級業(yè)務，擁有千萬級别的流量入口，經過長時間的業(yè)務疊代，代碼邏輯已經十分複雜臃腫，有迫切的性能優化需求。因此，結合體驗評分功能，以京喜首頁做試點，我們進行了一次體驗評分的優化實踐。目的是探索小程序體驗評分的指标原則：拿到100分的小程序應該是什麼樣子(zǐ)的；同時希望借此給項目優化提供更多思路(lù)。

我會按照「了解首頁評分現狀，分析扣分項規則，解決扣分項」這個(gè)思路(lù)來介紹，就讓我們開始吧～

京喜首頁評分現狀

打開小程序開發者工具-調試器(qì)-Audits，點擊運行，操作頁面滾一滾點一點，然後點擊結束。

評分結果會根據評測頁面内容差異、操作習慣、有無緩存有一定浮動(dòng)，下(xià)圖是京喜首頁的一次評分：總分68，性能、體驗、最佳實踐都有扣分，合計8項扣分項，後面我們來逐條分析這些扣分項。

扣分項分析和(hé)優化

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

得分标準：頁面 WXML 節點少(shǎo)于 1000 個(gè)，節點樹(shù)深度少(shǎo)于 30 層，子(zǐ)節點數不大于 60 個(gè)。

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

現有節點2500+，想要進行優化，首先需要了解頁面各個(gè)模塊的節點數分布。

如(rú)何統計每個(gè)模塊的節點數呢(ne)？可(kě)以使用「控制變量法」，利用性能評測工具中(zhōng)，節點數超過1000時會列出節點總數的能力，我們可(kě)以在總指标超過1000的情況下(xià)，每次隐藏一個(gè)模塊：

? 目标模塊節點數 = 原總節點數 - 當前節點數

（實測節點數會有小範圍浮動(dòng)，可(kě)以測3次取平均值）

首頁的模塊分析圖如(rú)下(xià)：

? （第一屏） （第二屏）

簡化數據如(rú)下(xià)：

觀察列表可(kě)以得到兩個(gè)信息：首頁分為展示狀态互斥的第一屏和(hé)第二屏；列表模塊的節點數是大頭。

因此，我們得到優化的兩個(gè)方向：

• 頁面元素按需加載，不展示時不渲染
• 長列表減少(shǎo)元素個(gè)數

第一個(gè)優化項可(kě)以通(tōng)過變量控制組件顯示隐藏，按需加載卸載。

第二個(gè)優化項首先想到的是減少(shǎo)列表接口分頁數值，比如(rú)一次請求20條數據改為請求5條。但是如(rú)果接口不支持自定義分頁，還可(kě)以實現更小的分頁拉取嗎？

那就自己寫一個(gè)分頁方法的代理吧～

思路(lù)如(rú)下(xià)：

上方為原始請求，每次20條數據，下(xià)方為代理請求的實現，每次返回5條。灰色虛線框是真實的請求數據動(dòng)作，通(tōng)過維護一個(gè)全量數據，需要哪頁取哪頁，這是示例代碼：

通(tōng)過以上兩個(gè)優化，可(kě)以成功的把首頁的頁面節點數瘦身一下(xià)了，最後我們成功達到 wxml 節點總數不大于1000的目标。

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

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

簡單理解是圖片尺寸太大而展示尺寸太小，導緻浪費網絡請求時間和(hé)内存資(zī)源。

解決方案：cdn服務商(shāng)一般都支持通(tōng)過參數獲取不同尺寸的圖片，前端可(kě)以包裝一個(gè)公共方法，根據頁面元素尺寸拉取合适大小的圖片。

此外，補充一下(xià)圖片體積的内容，除了關(guān)注圖片尺寸，具體的體積大小其實更值得關(guān)注，有以下(xià)兩個(gè)點可(kě)以了解下(xià)：

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

  

  這張圖裡未考慮 webp，加上 webp 其他類型競争力瞬間不足了，移動(dòng)端 androd 支持率基本可(kě)用，可(kě)以考慮根據設備類型漸進式使用：

  

• 利用一些壓縮技術(shù)對圖片進行壓縮，壓縮尺寸可(kě)觀，但對圖片顯示質量影響甚微。

3、存在可(kě)點擊元素的響應區域過小

得分标準：可(kě)點擊元素的寬高都不小于 20px

移動(dòng)端操作全靠手指，過小的交互區域會帶來不好的體驗，可(kě)以通(tōng)過增大元素響應熱區的方式來優化，以下(xià)方式都可(kě)以：

• padding
• 透明的border
• box-shadow

4、對網絡請求做必要的緩存

得分标準：3 分鐘以内同一個(gè)url請求不出現兩次回包大于 128KB 且一模一樣的内容

這一項的理由是，發起網絡請求總會讓用戶等待，可(kě)能造成不好的體驗，應盡量避免多餘的請求，比如(rú)對同樣的請求進行緩存。

優化方式：

• 善用小程序的 storage 能力，做好更新和(hé)過期管理後，盡可(kě)能緩存請求到的數據。
• 針對确實需要多次請求的日志類接口，可(kě)以通(tōng)過在參數内添加随機數或者時間戳的方式進行區分，避免誤判。

5、存在短(duǎn)時間内發起太多的請求

得分标準：通(tōng)過wx.request發起的耗時超過 300ms 的請求并發數不超過 10 個(gè)。

不同于上一項，這一項關(guān)注的是接口并發數：

• wx.request （HTTP 連接）的最大并發限制是 10 個(gè)
• wx.connectSocket （WebSocket 連接）的最大并發限制是 5 個(gè)

優化方式：

• 計算邏輯後移， 接口聚合
• 對于職責類似的網絡請求，最好采用節流的方式，先在一定時間間隔内收集數據，再合并到一個(gè)請求體中(zhōng)發送給服務端

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

得分标準：setData傳入的所有數據都在模闆渲染中(zhōng)有相關(guān)依賴

這一項考察的是 data 冗餘的問(wèn)題，小程序設計了渲染和(hé)邏輯分離(lí)的雙線程，兩邊通(tōng)訊通(tōng)過 evaluateJavascript 轉換字符串再進行拼接實現，需要非常小心兩個(gè)線程之間通(tōng)訊的數據量。因此，未綁定wxml的變量，最好優化成不使用 setData。

根據使用場景，可(kě)以做的優化有：

• 與頁面展示無關(guān)的内部變量，可(kě)以挂載在組件實例上，比如(rú)維護一個(gè) this.privateData 對象
• 使用小程序新版本支持的「純數據字段」：該字段不會被傳遞到 wxml 内，配置正則劃定它的匹配範圍，可(kě)以正常使用 setData 方法

但是，如(rú)果你(nǐ)像我一樣遇到上面策略無法覆蓋的場景呢(ne)？

• 需要修改舊代碼，配置純數據字段的正則影響太大
• 京喜首頁使用了 Taro 做多端适配，Taro 編譯複雜邏輯的數組後會出現「影子(zǐ)變量」去代理邏輯，原本的數組變量被架空導緻扣分

那麼還有一個(gè)終極 hack 的方法：

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

7、發起太多的圖片請求

得分标準：同域名耗時超過 100ms 的圖片請求并發數不超過 20 個(gè)

最後這一項也是圖片相關(guān)，發起太多圖片請求會觸發浏覽器(qì)并行加載的限制，可(kě)能導緻圖片加載慢，用戶一直處于等待中(zhōng)。

優化方式：

• 雪(xuě)碧圖
• 圖片懶加載：小程序 Image 組件支持通(tōng)過配置 lazy-load 參數來實現懶加載，具體判定邏輯是圖片進入上下(xià)三屏就開始加載。如(rú)果需要更可(kě)控的實現，可(kě)以自己構建組件來處理。

總結

做完這些優化，再測一下(xià)體驗評分：

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

總結一下(xià)，小程序性能評分可(kě)以從指标和(hé)實際數據上給我們的項目優化提供一些建議，本文(wén)主要從評分角度去分析了各種優化可(kě)能，希望能為各位小程序開發者帶來參考價值。

文(wén)章轉載自：https://segmentfault.com/a/1190000023768105  作者：