Mini Program
取消
Development
中文
EN
取消
  • Guide

    • # 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 opening the Mini Program, and the first screen time is too long, which will cause the user to see the white screen for a long time, affecting the use experience.

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

    1. The content of the first screen rendering is more, and it needs to collect multiple data for rendering. This situation requires developers to prioritize the content, give priority to the high priority content to show, shorten the white screen time
    2. The data that the header content depends on is being requested from the server for too long. Developers need to analyze the reasons for the long time to return server-side data from the server-side
    3. One-time rendering data is too large or dependent computations are too complex. Reducing the amount of rendering data and optimizing the algorithm of rendering related data can solve these problems.

    Scoring conditions: The first screen time does not exceed 5 second

    # 2. Rendering time

    Render time refers to the time it takes to render the first time or to render the page structure due to changes in data.

    Rendering the interface takes too long to make the user feel stuck and the experience is poor, and when this happens, it is necessary to check whether the area being rendered at the same time is too large (for example, the list is too long), or whether the calculations dependent on the rendering are too complicated.

    Scoring condition: rendering time does not exceed 500ms

    # 3. Script execution time

    Script execution time refers to the time that a JS script consumes in a synchronous execution, such as life cycle callbacks and synchronous execution time of event handling functions.

    Executing a script takes too long to make the user feel stuck and experience worse. When this happens, you need to confirm and optimize the logic of the script

    Scoring condition: Script runs no longer than one execution cycle 1 second

    # 4. SetData Call Frequency

    The call of setData interface involves the thread communication between the logic layer and the rendering layer. Too frequent communication may lead to the blocking of the processing queue, and the interface rendering is not timely and lead to stuttering. We should avoid useless frequent calls.

    Scoring conditions: calls per secondsetDataNo more than the number of 20 second

    # 5. SetData Data Size

    Since the Mini Program runs above the logical thread and the rendering thread, the setData call will transfer the data from the logical layer to the rendering layer, and the data will increase the communication time.

    Scoring conditions:setDataThe data in theJSON.stringifyAfter not more than 256KB

    # 6. Number of WXML nodes

    It is recommended that a page use less than 1000 individual WXML Nodes, the node tree depth is less than 30 Layer, the number of child nodes is not greater than 60 A. A too big WXML Node trees increase memory usage and take longer to rearrange styles, affecting the experience.

    Score Condition: Page WXML nodes are less than 1000 The node tree depth is less than 30 Layer, the number of child nodes is not greater than 60 individual

    # 7. Image cache

    open HTTP After cache control, the next time the same image is loaded, it will be read directly from the cache, greatly improving the loading speed.

    Conditions: All images are open HTTP cache

    # 8. Image size

    Picture too general assembly to increase download time and memory consumption, should be based on the size of the display area reasonable control picture size.

    Scoring conditions: Image width height product <= Actual Display Width Height Product * (Device pixel ratio 2)

    # 9. Request time

    Requests that take too long will keep the user waiting or even leaving, and should be optimized for server processing time, reduce the size of the return packet, and make the request respond quickly.

    Scoring condition: All network requests are in 1 Return results in seconds

    # 10. Number of network requests

    Launching too many requests in a short time will trigger the limit of the number of parallel requests of the Mini Program, and too many requests may also lead to problems such as slow loading, so the number of requests should be reasonably controlled, and even the merge of requests should be done.

    Scoring Conditions: Passwx.requestInitiated takes more than 300ms The number of requests concurrency does not exceed 10 individual

    # 11. Number of image requests

    Too many requests for images in a short period of time can trigger the browser's parallel loading limit, which can cause images to load slowly and users to handle the wait. Should be reasonable to control the number, can consider the use of Sprite map technology or off-screen images using lazy loading.

    Scoring conditions: the same domain name takes more than 100ms The number of concurrent picture requests does not exceed 6 individual

    # 12. Network Request Cache

    Making a network request always makes the user wait, which can cause a bad experience. Try to avoid redundant requests, such as caching the same request

    Scoring Conditions: 3 The same URL request does not appear twice within minutes. 128KB And the exact same content.