Performance

1. First Screen Time

First screen time refers to the time it takes for users to see the main content of the mini-program after opening it. A long first screen time can result in users seeing a blank screen for a prolonged period, which negatively impacts the user experience.

Optimizing the first screen time can be approached in the following ways:

1. If the first screen rendering involves rendering a large amount of content and requires fetching multiple sets of data, prioritize the content and display high-priority content first to reduce the blank screen time.
2. If the data required for the first screen content takes too long to fetch from the server, analyze the reasons for the long server response time and optimize server-side data retrieval.
3. If rendering a large amount of data at once or the rendering process involves complex calculations, reduce the amount of data being rendered or optimize the algorithms used for rendering.

• Reference values: FCPThresholds = [1800, 3000]; LCPThresholds = [2500, 4000];
• If greater than thresholds[1], it indicates poor performance. Improvement is needed between thresholds[0] and thresholds[1]. If less than thresholds[0], it indicates excellent performance.

Official Advice: First screen time should not exceed 5 seconds

2. Rendering Time

Rendering time refers to the time it takes to render the page structure for the first time or when there are changes in data that affect the page structure.

Excessive rendering time can make the user experience feel sluggish. When this happens, it's important to check if the area being rendered is too large (e.g., a long list) or if the calculations required for rendering are too complex.

Official Advice: Rendering time should not exceed 500ms

3. Script Execution Time

Script execution time refers to the time consumed by JavaScript scripts during a single synchronous execution, such as lifecycle callbacks and event handler functions.

Long script execution times can make the user experience feel sluggish. When this happens, it's essential to identify and optimize the logic within the scripts.

Official Advice: Script execution time within a single execution cycle should not exceed 1 second

4. setData Call Frequency

Frequent calls to the setData interface involve communication between the logic layer and the rendering layer, which can lead to blocking the processing queue and delayed rendering of the interface, resulting in stuttering. Avoid unnecessary frequent calls.

Official Advice: The number of setData calls per second should not exceed 20 times

5. setData Data Size

Since the logic layer and the rendering layer of the mini-program are separated, calls to setData transfer data from the logic layer to the rendering layer. Sending large amounts of data can increase communication time.

Official Advice: The size of data passed to setData after JSON.stringify should not exceed 256KB

6. DLT Node Count

It is recommended that a page should have fewer than 1000 DLT nodes, a node tree depth of less than 30 layers, and no more than 60 child nodes. A large DLT node tree will increase memory usage and lengthen the time required for style recalculation, negatively impacting the user experience.

Official Advice: The number of DLT nodes on a page should be less than 1000, the node tree depth should be less than 30 layers, and the number of child nodes should not exceed 60

7. Image Cache

Enabling HTTP cache control allows subsequent loads of the same image to be retrieved directly from the cache, greatly improving loading speed.

Official Advice: Enable HTTP cache for all images

8. Image Size

Large images can increase download time and memory consumption. Image size should be controlled according to the display area.

Official Advice: Image width multiplied by height should be less than or equal to the actual displayed width multiplied by height (device pixel ratio squared)

9. Request Time

Long request times can lead to prolonged waiting or user abandonment. Server processing time and response size should be optimized to ensure quick responses.

Official Advice: All network requests should return results within 1 second

10. Network Requests Count

Initiating too many requests in a short period can trigger limitations on the number of parallel requests in mini-programs, leading to slow loading and other issues. Request count should be controlled appropriately, and requests can be combined where possible.

Official Advice: Number of concurrent requests initiated through dlt.request that take more than 300ms should not exceed 10

11. Image Requests Count

Initiating too many image requests in a short period can trigger browser limits on parallel loading, leading to slow image loading. The number of requests should be controlled appropriately, and techniques such as image sprites or lazy loading can be used.

Official Advice: Number of concurrent requests to the same domain taking over 100ms should not exceed 6

12. Network Request Cache

Initiating network requests always requires users to wait, potentially leading to a poor experience. Unnecessary requests should be avoided, and caching can be used for repetitive requests.

Official Advice: The same URL should not result in two responses larger than 128KB with identical content within 3 minutes