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

    • # performance

    # 1. First screen time

    First screen time refers to the user from opening Mini Programs to see the first screen of the main content of time, first screen too long will lead to users to see a long time are white screen, affect the experience.

    Optimize first screen time, can be divided into the following cases:

    1. The first screen rendering content is more, need to gather multiple data for rendering. This situation requires developers to prioritize the content, high priority content to do priority display, shorten the white screen time
    2. First screen content relies on data that takes too long to request from the server. Developers need to specifically analyze the reasons for the long time to return server data from the server side
    3. One-time rendering data is too large or relies on calculations that are too complex. These problems can be solved by reducing the amount of rendered data and optimizing the rendering data.

    Scoring conditions: First screen time does not exceed 5 Seconds

    # 2. Render time

    Render time refers to the time spent rendering for the first time or rendering for page structure changes caused by data changes.

    The rendering interface takes too long to make the user feel that the Caton experience is poor, when this happens, you need to check whether the rendering area is too large (such as the list is too long), or the rendering dependency calculation is too complicated.

    Scoring conditions: rendering time does not exceed 500ms

    # 3. Script execution time

    Script execution time is the amount of time that a JS script consumes during a synchronous execution, such as lifecycle callbacks and synchronous execution of event handlers.

    It takes too long to execute a script that makes the user feel that the experience is poor, and when this happens, you need to confirm and optimize the logic of the script

    Scoring condition: Scripts run for no more than one execution cycle 1 Seconds

    # 4. SetData Call Frequency

    The calling of setData interface involves thread communication between logic layer and rendering layer. Too frequent communication may lead to blocking of processing queue. The interface rendering is not timely and leads to Caton. We should avoid useless frequent calling.

    Scoring conditions: calls per secondsetDataNot to exceed the number of 20 second

    # 5. SetData data size

    Since the Mini Program runs on top of the logical thread and the render thread, the call to setData transfers data from the logical layer to the render layer, which increases communication time.

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

    # 6. Number of WXML nodes

    It is recommended that a page use less than 1000 individual WXML Node, the node tree depth is less than 30 Layer, the number of child nodes is not greater than 60 1. A too-big WXML The node tree will increase memory usage and style rearrangements will take longer, affecting the experience.

    Scoring conditions: 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. PictureCache

    open HTTP After caching control, the next load the same picture, will be directly from the cache read, greatly improve the loading speed.

    Scoring conditions: All pictures are on HTTP cache

    # 8. Image size

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

    Scoring conditions: Picture width height product <= Actual display width height product * (Device pixel ratio 2)

    # 9. Request time-consuming

    Requests that take too long can make users wait or even leave. We should optimize server processing time, reduce the size of return packets, and make requests respond quickly.

    Scoring conditions: All network requests are in 1 Returns results in seconds

    # 10. Number of network requests

    Too many requests in a short period of time will trigger the limitation of the number of parallel requests for Mini Programs, and too much requests may also lead to problems such as slow loading, so we should reasonably control the amount of requests, or even merge the requests.

    Scoring conditions: Passwx.requestInitiated takes more than 300ms The number of request concurrency of the 10 individual

    # 11. Number of picture requests

    Too many image requests in a short period of time will trigger the limitation of parallel loading in the browser, which may cause images to load slowly and users to wait for processing. The quantity should be controlled reasonably. Consider using Sprite Graphics technology or lazy loading on off-screen pictures.

    Scoring conditions: the same domain name takes more than 100ms The number of picture request concurrency of not more than 6 individual

    # 12. Network Request Cache

    Initiating network requests will always make users wait, which can lead to a bad experience. Try to avoid redundant requests, such as caching the same request

    Scoring conditions: 3 Within minutes the same url request does not appear twice back packet greater than 128KB And the exact same thing.