Experience scoring is a feature that rates the experience of a small program, checks it in real time as it runs, analyzes some areas that might cause the experience to be bad, and locates where something is wrong, and gives some optimization recommendations.

Operating environment requirements

• Download and install 1.02.1808300 or above versions of the developer tool, download address.
• The base library needs to be cut to version 2.2.0 or above.

Use the process

1. Open the developer tool and switch the base library to version 2.2.0 or above in the details.
2. Switch to the Audits panel in the debugger area.
3. Click the Start button, then operate the small program interface yourself, and the run page will be detected by Experience Score.

1. Click "Stop" to end the detection and display the appropriate detection report in the current panel, and the developer can optimize the functionality according to the recommendations in the report.
2. To run the experience score again, click Empty Experience Score above the report to restore the initial state. Please note that there is currently no report storage service available and once the experience score is emptied, you will no longer be able to view the results of this rating.

Run automatically

To make it easier for developers to spot experience issues with small programs in a timely manner, the "Auto-Run" feature that supports experience scoring starts with developer tool version 1.02.1811150.

This feature checks in real time when debugging a small program is developed, and once you find that the experience score is less than 70 points, the developer is prompted by printing a warning message on the console panel, which allows the developer to cut to the Audits panel to see the details.

Developers check the Auto Run Experience Rate option in the local settings of the tool's upper right corner of the tool.

Judging rules

Specific score rules and details of the following documents:

1, rating method

---

The current experience score has a total of 27 rules, a total of three categories: performance, experience, best practice, meet rules required score (100 points), otherwise you will not score (0 points), and finally calculate total score according to each rule weight and formula..

Rules with weight are 0, indicating that this rule does not participate in the score, only as a prompt.Developers can click "ignore" in the developer tool.The score conditions of each rule may also be adjusted with the version of the applet.

The weights are shown in the table below

Classification	Rules	Weight
Performance	When the script was executed	7
	First screen time	6
	Render time	6
	SetData call frequency	6
	SetData data size	6
	The number of WXML nodes	6
	The request takes time	5
	The number of network requests	5
	The number of picture requests	5
	Picture cache	4
	The size of the picture	4
	The network request cache	2
Experience	Turn on inertial scrolling	8
	Avoid :active pseudo-class to implement click state	8
	Keep the picture size scale	4
	The response area of the clickable element	3
	The iPhone X is compatible	3
	Reasonable color matching	0
Best practices	Avoid JS exceptions	3
	Avoid network request exceptions	3
	Discarded interface	2
	Use HTTPS	1
	Avoid setData data redundancy	1
	Minimum base library version	0
	Remove pages that are not accessible	0
	WXSS usage	0
	Time the timer is recovered in a timely manner	0

2, performance

---

1. First screen time

The first screen time refers to the time when the user sees the main content of the first screen from the opening of the small program, and the first screen time is too long, which causes the user to see the white screen for a long time, affecting the user experience.

Optimizing the first screen time can be divided into the following situations:

1. The first screen renders more content and requires a collection of multiple copies of data for rendering. This situation requires developers to prioritize content, high priority content as a priority display, shorten the white screen time;
2. The data on which the first screen of content depends is requested from the service side for too long. The developer needs to analyze the reasons for the long time returned by the service-side data from the service side;
3. One-time rendering data is too large or dependent calculations are too complex. Algorithms that reduce the amount of rendered data and optimize render-related data can solve these problems.

Score condition: The first screen time does not exceed 5 seconds

2. Render time

Rendering time refers to the time it takes to render for the first rendering or for page structure changes due to data changes.

The length of time it takes to render the interface can make the user feel that Caton, the experience is poor, and when this happens, you need to check whether the area being rendered at the same time is too large (such as the list is too long), or whether the rendering dependent calculation is too complex.

Score condition: Render time does not exceed 500ms

3. When the script was executed

Script execution time refers to the time that a JS script spends in a synchronized execution, such as a lifecycle callback, and a synchronous execution time for an event handler.

Too long to execute a script can make the user feel that Caton has a poor experience, and when this happens, the logic of the script needs to be confirmed and optimized

Score condition: The script runs for no more than 1 second in a execution cycle

4. SetData call frequency

The call to the setData interface involves thread communication between the logical layer and the rendering layer, which can lead to processing queue blocking, and the interface rendering is not timely, so that frequent calls that are useless should be avoided.

Score condition: SetData is called no more than 20 times per second

5. SetData data size

Because the small program runs on top of the logical thread and the rendering thread, setData's call sends data from the logical layer to the rendering layer, and too much data increases communication time.

Score condition: SetData's data does not exceed 256KB after JSON.stringify

6. Number of WXML nodes

It is recommended that a page use fewer than 1000 WXML nodes, a node tree with a depth of less than 30 layers, and no more than 60 child nodes. A large WXML node tree increases memory usage and style rearring time, affecting the experience.

Scoring criteria: There are fewer than 1000 page WXML nodes, fewer than 30 layers deep in the node tree, and no more than 60 child nodes

7. Picture cache

When HTTP cache control is turned on, the next time the same picture is loaded, it is read directly from the cache, greatly increasing the loading speed.

Score condition: HTTP cache is turned on for all pictures

8. Picture size

Too large a picture increases download time and memory consumption, and the picture size should be reasonably controlled based on the size of the display area.

Score Conditions: Picture Wide-Height Multipliers .

9. The request takes time

Requests take too long for users to wait or even leave, and server processing time should be optimized, packets reduced, and requests respond quickly.

Scoring criteria: All network requests return results within 1 second

10. Number of network requests

Making too many requests in a short period of time triggers a limit on the number of parallel requests from small programs, while too many requests can lead to problems such as slow loading, reasonable control of the number of requests, and even the consolidation of requests.

Score condition: No more than 10 requests that take more than 300ms to initiate through wx.request

11. Number of photo requests

Launching too many picture requests in a short period of time triggers the browser's limit on parallel loading, which can cause pictures to load slowly and the user to wait. The quantity should be reasonably controlled, consider using Sprite technology or lazy loading for off-screen pictures.

Scoring criteria: No more than 20 picture requests with the same domain name taking more than 100ms

12. The network request caches

Making a network request always leaves the user waiting, which can create a bad experience, and you should try to avoid redundant requests, such as caching the same requests

Scoring conditions: Within 3 minutes, the same url request does not appear twice the return package is greater than 128KB and is exactly the same content

3, experience

---

1. Turn on inertial scrolling

Inertial scrolling makes scrolling smoother, with inertial scrolling by default under Android, and additional settings are required under iOS -webkit-overflow-scrolling: touch style;

Scoring conditions: Elements with overflow: scroll in wxs, need to be set under iOS -webkit-overflow-scrolling: touch style

2. Avoid using: active pseudo-classes to implement click state

Use the css:active pseudo-class to implement click state, which is easy to trigger, and the click state does not disappear when scrolling or sliding, and the experience is poor. It is recommended to implement this using the 'hover-class' property of the components built into the gadget

Score condition: Do not use: active pseudo-class, and replace with hover-class: active

3. Keep the picture size scale

If the picture is not displayed at the original width and height ratio, it may cause the picture to be distorted, unseemly, and even cause the user to identify difficulties. Depending on the situation, you can set the mode property of the image component to maintain the aspect ratio of the original figure.

Score conditions: Show no more than 15% high/wide as the original figure

4. The response area of the clickable element

We should reasonably set the response area size of the clickable element, if too small will make it difficult for the user to point in, the experience is poor.

Score condition: Clickable elements are not less than 20px in width

5. iPhone X is compatible

For the interaction components of theposition: Fixed, if rendering is outside the safe area of the iPhone X and easily mis-touches Home Indicator, the interactive parts should be rendered to the safe area.

The following wxss are recommended for compatibility

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

Score condition: position: Fixed and highly less than 68px interactable rendered in a safe area

6. Reasonable color matching

Text color and background color need to be matched properly, appropriate color contrast can allow users to better read, improve the user experience of small programs.

Because the calculation method of color matching is complicated, the algorithm is still being optimized. Therefore, the metric is only a reminder of the score and does not count in the total score.

Criteria for judgment:

1. For larger fonts (font-size, or 24px, or for both font-size, 19px and font-weight, 700), the contrast between text color and background color is not less than 3

2. The contrast between other fonts, text colors and background colors is not less than 4.5

The contrast calculation method refers to the W3C standard

4, best practices

---

1. Avoid JS exceptions

A JavaScript exception may prevent the interaction of the program from going on, and we should pursue zero exceptions to ensure the program's high robustness and high availability.

Score condition: No JS exceptions appear

2. Avoid network request exceptions

A request failure may prevent the program from interacting and all requests should be guaranteed to succeed.

Score condition: All authorized network requests return normally, and unauthorized network requests require 401 or 403 status codes

3. Do not use an abandoned interface

Using an interface that is about to be obsolete or obsolete may cause the small program to not function properly. In general, the interface is not removed immediately, but for insurance's part, it is not recommended to use it to avoid subsequent minor programs that suddenly run abnormally.

Score condition: Do not use any interfaces that are prompted to be discarded in any document

4. Use HTTPS

With HTTPS, you can make your small programs more secure, and HTTP is transmitted in clear text and risks being tampered with

Score condition: HTTPS is used for all network requests

5. Avoid setData data redundancy

SetData operations cause the framework to handle some rendering interface-related work, and an unbound variable means that, independent of interface rendering, passing in setData can cause unnecessary performance consumption.

Score condition: All data passed in by setData has dependencies in template rendering

6. Minimum base library version

When the supported version of the component/API used is larger than the configured minimum on-line base library version, the functionality may not be available. Developers can resolve this issue by adjusting the minimum base library version or by being it code-compatible.

Because the user can resolve the issue in a code-compatible manner, the metric is only a reminder of the score and does not count in the total score.

Criterion: The supported version of the component/API that does not exist is larger than the configured online minimum base library version

7. Remove pages that are not accessible

The package size of the small program affects the load time, and you should try to control the package size so that you do not package files that will not be used.

Because this metric relies on the developer's action path, it is only a reminder of the score and does not count in the total score.

Criterion of judgment: There are no pages that are not accessible that are packaged into small programs

8. WXSS usage

We should introduce wxss resources on demand, and if there are a lot of unused styles in the small program, it will increase the size of the small package, which will affect the loading speed to some extent.

Because this metric relies on the developer's action path, it is only a reminder of the score and does not count in the total score.

Criterion: The unused portion of each wxs resource does not exceed 2KB

9. Recover the timer in a timely manner

The timer is global and not tied to a page, and when a small program is routed from one page to another, the previous page timer should be careful to recycle manually.

Because this metric relies on the developer's action path, it is only a reminder of the score and does not count in the total score.

Criterion: All callbacks to the timer are executed on the same page as the page on which the timer is set