微信小程序 體驗評分

體驗評分是一項給小程序的體驗好壞打分的功能，它會在小程序運行過程中實時檢查，分析出一些可能導致體驗不好的地方，并且定位出哪里有問題，以及給出一些優(yōu)化建議。

運行環(huán)境要求

• 下載并安裝 1.02.1808300 或以上版本的開發(fā)者工具，下載地址。
• 基礎(chǔ)庫需要切到 2.2.0 或以上版本。

使用流程

1. 打開開發(fā)者工具，在詳情里切換基礎(chǔ)庫到 2.2.0 或以上版本。
2. 在調(diào)試器區(qū)域切換到 Audits 面板。
3. 點擊”開始“按鈕，然后自行操作小程序界面，運行過的頁面就會被“體驗評分”檢測到。

1. 點擊 “停止" 則結(jié)束檢測，在當前面板顯示相應的檢測報告，開發(fā)者可根據(jù)報告中的建議對相應功能進行優(yōu)化。
2. 如需再次運行體驗評分，可點擊報告上方的“清空體驗評分”恢復初始狀態(tài)。請注意，目前系統(tǒng)不提供報告存儲服務，一旦清空體驗評分，將無法再查看本次評分結(jié)果。

自動運行

為了方便開發(fā)者能夠及時發(fā)現(xiàn)小程序的體驗問題，從開發(fā)者工具 1.02.1811150 版本起支持體驗評分的 “自動運行” 功能。

該功能會在開發(fā)調(diào)試小程序時，實時檢查，一旦發(fā)現(xiàn)體驗分數(shù)低于 70 分時，系統(tǒng)會在 console 面板打印一個 warning 信息提示開發(fā)者，此時開發(fā)者可以切到 Audits 面板查看詳情。

開發(fā)者在工具的右上角 “詳情” 面板的 本地設(shè)置 中勾選 “自動運行體驗評分” 選項即可開啟。

評分規(guī)則

具體的評分細則和詳情的規(guī)則說明可參考下列文檔：

1、評分方法

---

目前體驗評分共有27條規(guī)則，共分為三類：性能、體驗、最佳實踐，滿足規(guī)則要求得分（100分），否則不得分（0分），最后根據(jù)各規(guī)則權(quán)重和公式計算出總得分。

權(quán)重為0的規(guī)則，表示該規(guī)則不參與評分，僅作為提示項。開發(fā)者可在開發(fā)者工具中可以點擊“忽略”。各規(guī)則的得分條件也可能會隨小程序的版本更新有一定的調(diào)整。

權(quán)重如下表

分類	規(guī)則	權(quán)重
性能	腳本執(zhí)行時間	7
	首屏時間	6
	渲染時間	6
	setData調(diào)用頻率	6
	setData數(shù)據(jù)大小	6
	WXML節(jié)點數(shù)	6
	請求耗時	5
	網(wǎng)絡(luò)請求數(shù)	5
	圖片請求數(shù)	5
	圖片緩存	4
	圖片大小	4
	網(wǎng)絡(luò)請求緩存	2
體驗	開啟慣性滾動	8
	避免使用:active偽類來實現(xiàn)點擊態(tài)	8
	保持圖片大小比例	4
	可點擊元素的響應區(qū)域	3
	iPhone X兼容	3
	合理的顏色搭配	0
最佳實踐	避免JS異常	3
	避免網(wǎng)絡(luò)請求異常	3
	廢棄接口	2
	使用HTTPS	1
	避免setData數(shù)據(jù)冗余	1
	最低基礎(chǔ)庫版本	0
	移除不可訪問到的頁面	0
	WXSS使用率	0
	及時回收定時器	0

2、性能

---

1. 首屏時間

首屏時間是指用戶從打開小程序看到第一屏主要內(nèi)容的時間，首屏時間太長會導致用戶長時間看到的都是白屏，影響使用體驗。

優(yōu)化首屏時間，可以分為以下幾種情況：

1. 首屏渲染的內(nèi)容較多，需要集合多份數(shù)據(jù)進行渲染。這種情況需要開發(fā)者把內(nèi)容分優(yōu)先級，把優(yōu)先級高的內(nèi)容做優(yōu)先展示，縮短白屏時間；
2. 首屏內(nèi)容依賴的數(shù)據(jù)從服務端請求的時間太長。開發(fā)者需要從服務端側(cè)具體分析服務端數(shù)據(jù)返回的時間長的原因；
3. 一次性渲染數(shù)據(jù)太大或依賴的計算過于復雜。減少渲染的數(shù)據(jù)量、優(yōu)化渲染相關(guān)數(shù)據(jù)的算法可以解決這類問題。

得分條件：首屏時間不超過 5 秒

2. 渲染時間

渲染時間指的是首次渲染或因數(shù)據(jù)變化帶來的頁面結(jié)構(gòu)變化的渲染花費的時間。

渲染界面的耗時過長會讓用戶覺得卡頓，體驗較差，出現(xiàn)這一情況時，需要校驗下是否同時渲染的區(qū)域太大（例如列表過長），或渲染依賴的計算是否過于復雜。

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

3. 腳本執(zhí)行時間

腳本執(zhí)行時間是指JS腳本在一次同步執(zhí)行中消耗的時間，比如生命周期回調(diào)、事件處理函數(shù)的同步執(zhí)行時間。

執(zhí)行腳本的耗時過長會讓用戶覺得卡頓，體驗較差，出現(xiàn)這一情況時，需要確認并優(yōu)化腳本的邏輯

得分條件：一個執(zhí)行周期內(nèi)腳本運行時間不超過 1 秒

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

setData接口的調(diào)用涉及邏輯層與渲染層間的線程通信，通信過于頻繁可能導致處理隊列阻塞，界面渲染不及時而導致卡頓，應避免無用的頻繁調(diào)用。

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

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

由于小程序運行邏輯線程與渲染線程之上，setData的調(diào)用會把數(shù)據(jù)從邏輯層傳到渲染層，數(shù)據(jù)太大會增加通信時間。

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

6. WXML節(jié)點數(shù)

建議一個頁面使用少于 1000 個 WXML 節(jié)點，節(jié)點樹深度少于 30 層，子節(jié)點數(shù)不大于 60 個。一個太大的 WXML 節(jié)點樹會增加內(nèi)存的使用，樣式重排時間也會更長，影響體驗。

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

7. 圖片緩存

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

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

8. 圖片大小

圖片太大會增加下載時間和內(nèi)存的消耗，應根據(jù)顯示區(qū)域大小合理控制圖片大小。

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

9. 請求耗時

請求的耗時太長會讓用戶一直等待甚至離開，應當優(yōu)化好服務器處理時間、減小回包大小，讓請求快速響應。

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

10. 網(wǎng)絡(luò)請求數(shù)

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

得分條件：通過wx.request發(fā)起的耗時超過 300ms 的請求并發(fā)數(shù)不超過 10 個

11. 圖片請求數(shù)

短時間內(nèi)發(fā)起太多圖片請求會觸發(fā)瀏覽器并行加載的限制，可能導致圖片加載慢，用戶一直處理等待。應該合理控制數(shù)量，可考慮使用雪碧圖技術(shù)或在屏幕外的圖片使用懶加載。

得分條件：同域名耗時超過 100ms 的圖片請求并發(fā)數(shù)不超過 20 個

12. 網(wǎng)絡(luò)請求緩存

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

得分條件：3 分鐘以內(nèi)同一個url請求不出現(xiàn)兩次回包大于 128KB 且一模一樣的內(nèi)容

3、體驗

---

1. 開啟慣性滾動

慣性滾動會使?jié)L動比較順暢，在安卓下默認有慣性滾動，而在 iOS 下需要額外設(shè)置-webkit-overflow-scrolling: touch的樣式；

得分條件：wxss中帶有overflow: scroll的元素，在 iOS 下需要設(shè)置-webkit-overflow-scrolling: touch樣式

2. 避免使用:active偽類來實現(xiàn)點擊態(tài)

使用 css :active偽類來實現(xiàn)點擊態(tài)，很容易觸發(fā)，并且滾動或滑動時點擊態(tài)不會消失，體驗較差。建議使用小程序內(nèi)置組件的 'hover-class' 屬性來實現(xiàn)

得分條件：不使用:active偽類，并使用hover-class替換:active

3. 保持圖片大小比例

圖片若沒有按原圖寬高比例顯示，可能導致圖片歪曲，不美觀，甚至導致用戶識別困難?？筛鶕?jù)情況設(shè)置 image 組件的 mode 屬性，以保持原圖寬高比。

得分條件：顯示的高/寬與原圖的高/寬不超過 15%

4. 可點擊元素的響應區(qū)域

我們應該合理地設(shè)置好可點擊元素的響應區(qū)域大小，如果過小會導致用戶很難點中，體驗很差。

得分條件：可點擊元素的寬高都不小于 20px

5. iPhone X 兼容

對于position: fixed的可交互組件，如果渲染在iPhone X的安全區(qū)域外，容易誤觸 Home Indicator，應當把可交互的部分都渲染到安全區(qū)域內(nèi)。

建議使用以下wxss進行兼容

padding-bottom: constant(safe-area-inset-bottom);
padding-bottom: env(safe-area-inset-bottom);

得分條件：position: fixed且高度小于 68px 的可交互組件渲染在安全區(qū)域內(nèi)

6. 合理的顏色搭配

文字顏色與背景色需要搭配得當，適宜的顏色對比度可以讓用戶更好地閱讀，提升小程序的用戶體驗。

由于顏色搭配的計算方法較為復雜，目前算法還在不斷優(yōu)化中。因此該指標僅作為評分的提醒項，不計入總分中。

判斷標準：

1. 對于較大字體（font-size >= 24px，或同時滿足font-size >= 19px與font-weight >= 700），文字顏色和背景顏色的對比度不小于3

2. 其他字體，文字顏色和背景顏色的對比度不小于4.5

對比度計算方法參考W3C標準

4、最佳實踐

---

1. 避免JS異常

出現(xiàn) JavaScript 異?？赡軐е鲁绦虻慕换o法進行下去，我們應當追求零異常，保證程序的高魯棒性和高可用性。

得分條件：不出現(xiàn)任何JS異常

2. 避免網(wǎng)絡(luò)請求異常

請求失敗可能導致程序的交互無法進行下去，應當保證所有請求都能成功。

得分條件：所有已授權(quán)網(wǎng)絡(luò)請求都正常返回，未授權(quán)網(wǎng)絡(luò)請求需要給出 401 或 403 這兩種狀態(tài)碼

3. 不使用廢棄接口

使用即將廢棄或已廢棄接口，可能導致小程序運行不正常。一般而言，接口不會立即去掉，但保險起見，建議不要使用，避免后續(xù)小程序突然運行異常。

得分條件：不使用任何文檔中提示廢棄的接口

4. 使用HTTPS

使用HTTPS，可以讓你的小程序更加安全，而HTTP是明文傳輸?shù)?，存在可能被篡改?nèi)容的風險

得分條件：所有網(wǎng)絡(luò)請求都使用HTTPS

5. 避免setData數(shù)據(jù)冗余

setData操作會引起框架處理一些渲染界面相關(guān)的工作，一個未綁定的變量意味著與界面渲染無關(guān)，傳入setData會造成不必要的性能消耗。

得分條件：setData傳入的所有數(shù)據(jù)都在模板渲染中有相關(guān)依賴

6. 最低基礎(chǔ)庫版本

當使用的組件/API 的支持版本大于配置的線上最低基礎(chǔ)庫版本時，可能導致相應功能不可用。開發(fā)者可通過調(diào)整最低基礎(chǔ)庫版本或在代碼上兼容的方式解決該問題。

由于用戶可以通過代碼兼容的方式解決該問題，因此該指標僅作為評分的提醒項，不計入總分中。

判斷標準：不存在使用的組件/API 的支持版本大于配置的線上最低基礎(chǔ)庫版本

7. 移除不可訪問到的頁面

小程序的包大小會影響加載時間，應該盡量控制包體積大小，避免將不會被使用的文件打包進去。

由于該項指標依賴開發(fā)者的操作路徑，因此僅作為評分的提醒項，不計入總分中。

判斷標準：不存在訪問不到的頁面被打包到小程序中

8. WXSS使用率

我們應該按需引入 wxss 資源，如果小程序中存在大量未使用的樣式，會增加小程序包體積大小，從而在一定程度上影響加載速度。

由于該項指標依賴開發(fā)者的操作路徑，因此僅作為評分的提醒項，不計入總分中。

判斷標準：每個 wxss 資源的未使用部分不超過 2KB

9. 及時回收定時器

定時器是全局的，并不是跟頁面綁定的，當小程序從一個頁面路由到另一個頁面之后，前一個頁面定時器應注意手動回收。

由于該項指標依賴開發(fā)者的操作路徑，因此僅作為評分的提醒項，不計入總分中。

判斷標準：所有定時器的回調(diào)執(zhí)行時所在的頁面都與設(shè)置定時器的頁面一致