Start performance

Small program start-up is an extremely important part of the small program user experience, start-up time is too long will cause the small program user loss.

The startup of this section includes only the cold start of the small program, not the hot start of the small program background cutting fore desk.

First, start the process

Before you start optimization, briefly describe the startup process for the following small programs. In the small program start-up process, mainly includes the following aspects:

• Note 1: These parts of the small program startup are not done serially and will be carried out in parallel as much as possible.
• Note 2: The small program starts parts that are not complete every time they start, and the cache is used as much as possible.

Resource preparation

1.1 Preparation of information about the small program

When the user accesses the small program, weChat client needs to obtain the configuration, version, permissions and other relevant information of the small program from WeChat background, in order to make the necessary version management, permission control and verification of the small program.

Impact on startup time

Access to and update of information can affect the time it takes for a small program to start, especially when the user first accesses the small program.

In order to ensure the real-time nature of the information with the ability to minimize the impact on startup time, the information is cached locally and updated periodically through a certain mechanism.

1.2 Small program running environment preparation

Before executing the small program code, weChat clients need to prepare the underlying environment in which the small program runs.

The operating environment of the applet includes a small program process, a UI element of the native part (such as navigation bar, Tabbar et al.), The webview container used by the rendering page, run the JS engine, applet base library, etc. of the developer JS code.

Influence of start-up time consumption

There is a significant impact on the time of operation of the operating environment.

In order to reduce the operational environment of the operating environment, the WeChat client is partially preloaded in advance according to the user's use scenario and device resource usage.However, due to the impact of equipment resources and operating system scheduling, it is difficult to ensure that each small program is started with preloaded environments.

1.3 small program package preparation

When the applet is started, you need to get the code package address from the server, download the applet code package, and check the code package.Different from the plug-in and use of the small program page, starting at a time, you may need to download multiple code packages or plug-in packages.

When the applet is updated, the WeChat client also needs to increment the code package.

Influence of start-up time consumption

Download consumption is an important bottleneck in the start-up time, and is positively correlated with the volume of the code package or increment package.WeChat uses the ZSTD algorithm to compress the small program code package to minimize the amount of data transmitted during the download process.

Considering the impact of the package size on the user experience, the platform limits the size of the single code package to 2m.The increase in the upper limit of the code package can achieve a richer function for developers, but for users, it also adds to download traffic and local space.In order to ensure the start speed, the developer should control the code package as much as possible.

2. Developer code injection (logical layer)

When the applet is started, you need to read the configuration and code of the applet from the code package and inject it into the JS engine.During the main package code injection, the app.onlaunch and the first App.onShow life cycle will be triggered during the main package code injection.After the developer code is completed, the frame side will initialize the page data according to the page data of the user, trigger the page.onload, page.onload event.

Influence of start-up time consumption

When the injection of the developer code directly affects the start of the applet.In the mainstream JS engine, the code injection consumption includes compilation and execution equal links, code quantity, synchronization interface calls, and some complex calculations, will affect the injection time consumption.

Since the home rendering requires the data sent by the logical layer, if the developer code injection is too long, the time for the start of the home page rendering will also be delayed.

On some platforms, the WeChat client uses the Code Caching technology of the V8 engine to caches the code compilation result, reducing the compilation time of secondary injection.

3. Developer code injection (rendering layer)

Developers' WXSS and WXML will be compiled into the rendering layer, containing pages and style information required for page rendering.The injection time of rendering layers is mainly related to page structure complexity and the number of custom components used.

The developer code injection of the rendering layer and the logic layer is in parallel.

Influence of start-up time consumption

Since the home rendering requires the page structure and style information of the rendered layer, if the developer code is too long, the time for the start of the home rendering will be delayed.

4. Home (first) rendering

After the developer code injection is complete, combined with the data obtained by the logical layer and the page structure and style information obtained by the rendering layer, the small program framework renders the home page of the small program, displays the first screen of the small program, and triggers the Page.onReady event of the home page. The Page.onReady event triggers the completion of the program startup process.

Impact on startup time

Home rendering time is primarily affected by the page structure and the amount of data involved in rendering.

Second, key concepts

There are several concepts that need to be clarified when discussing the time it takes for a small program to start:

1. The first screen rendering of the small program is complete

From a developer's point of view, the symbol of the completion of the first-screen rendering of the small program is the page.onReady event trigger.

From a framework perspective, the contents of the first screen of the program are rendered based on the initial data of the small program and the setData data that arrives before the rendering begins.

The completion of the first-screen rendering does not necessarily mean that the small program page must have complete content, and developer-triggered setData (e.g., requesting data asynchronously via wx.request) may not be able to participate in the first-screen rendering.

Due to differences in the framework and startup process, the first-screen rendering of the program definition is not the same as the browser's load event.

2. Small program start-up phase

From the user clicking to access the small program to the first screen rendering of the small program (page page.onReady event triggered).

3. Open rate/arrival rate

The first rendering of the small program completes the ratio of PV to the user clicking to access the small program PV. The churn rate is 1 - the open rate

Third, start performance optimization

In the startup process, small package preparation, developer code injection, and home rendering are related to the developer, who can do some optimization work. Other parts are currently unable for developers to intervene, and the framework side is responsible for continuous optimization.

1. Small package optimization

The core approach to code pack optimization is to reduce the size of the code pack, which directly affects the download time and the user's experience when starting a small program.

Developers can optimize the package size by:

1.1 Subcontract loading

Using subcontract loading is the most obvious way to optimize the time-consuming effect of small program startup. It is recommended that developers split the functionality of the small program according to the frequency of use and the scene, so that the code package can be loaded on demand.

Subcontract loading has the following benefits:

• Host more features: Small programs have a maximum volume of 2M per individual code package, and subcontracting can increase the total volume cap for small packages and host more features and services.
• Reduce code package download time: Use subcontracts to significantly start when you need to download the size of the code package, without affecting the normal use of functionality to significantly increase startup time.
• Reduce developer code injection time: Small programs start with a one-time injection of all developer code, using subcontracts to reduce the amount of code injected, thereby reducing injection time.
• Reduce page rendering time

In addition, in combination with several extensions of subcontract loading, startup time can be further optimized:

Subcontract pre-download

After using "subcontract loading", although it can significantly improve the startup speed of small programs, but when the user jumps to the subcontracted page during the use of small programs, you need to wait for the subcontract download to complete before entering the page, resulting in a delay in page switching, affecting the experience of the small program. Subcontract pre-downloads are designed to address latency issues when entering the subcontracted page for the first time.

Separate subcontracts

However, some scenarios in a small program , such as ad pages, campaign pages, payment pages, and so on, are often less complex and relatively independent, with high requirements for startup performance. S tand-alone subcontracts can run independently of the main package and other subcontracts. W hen you enter a small program from a separate subcontract page, you do not need to download the main package. It is recommended that developers place some pages that are highly demanding on startup performance in special separate subcontracts.

Independent subcontract and subcontract pre-download can be used together for better results, please refer to the independent subcontract and subcontract pre-download tutorial for details

1.2 Code refactoring and optimization

Code redundancy is reduced through code refactoring. When using packaging tools such as Webpack, try to take advantage of features such as tree-shaking to remove redundant code, and be careful to prevent unwanted libraries and dependencies from being introduced when packaging.

1.3 Control resources such as pictures within the code pack

Avoid including or using too many and over-inline images of base64 in the code pack in WXSS, and try to use network images. P ictures within a code pack should generally contain only smaller icons. Other types of resources, such as sound and video, should be avoided in code packs.

Small packages are compressed using the ZSTD algorithm when downloading, reducing the amount of data transferred during download. These resource files can be bulky and often difficult to compress further, with a much greater impact on download time than code files.

1.4 Clean up unavailable code and resources in a timely manner

In day-to-day development, we may have introduced some new library files, and after a while, for various reasons, we no longer use the library, we often just remove the references in the code, and forget to delete such library files.

At present, small program packaging is to put all the files under the project into the code package, that is, these library files and resources that are not actually used are also into the code package, which affects the size of the overall code package.

2. Developer code injection optimization

The optimization of developer code injection can start with optimizing execution time and optimizing the amount of code.

2.1 Reduces the synchronization of calls to the startup process

In the small program startup process, developer code is injected and executed sequentially App.onLaunch, App.onShow, Page.onLoad, Page.onShow I n several life cycles related to the initialization of small program code (content other than Page, app definition) and startup, you should avoid performing complex computational logic or overusing sync APIs at the end of Sync, such as wx.getStorageSync, wx.getSystemInfoSync, and so on. For getSystemInfo, the results of getSystemInfoSync should be cached to avoid repeated calls.

2.2 Use lazy injection

Typically, when a small program starts, all JS code from the subcontract and the main package (except for the separate subcontract) on which the launch page is located is merged and injected, including other unrecoled pages and unused custom components, resulting in a lot of unused code being injected into the small program running environment, affecting injection time and memory consumption.

Starting with base library version 2.11.1, the program supports injecting only the custom components and current page code required for the current page to reduce the startup time and runtime memory of the gadget. Developers can configure it in app.json:

{
  "lazyCodeLoading": "requiredComponents"
}

Note: When this configuration is added, unused code files will not be executed.

3. Page rendering optimization

3.1 Advance first-screen data request

Most small programs rely on the interface data on the service side when rendering the home page, which gives developers the ability to initiate data requests in advance:

• Data pre-pull: can be cold start of small programs through WeChat background in advance to third-party servers to pull business data, when the code package loaded can be faster rendering of the page, reduce user waiting time, thereby improving the speed of opening small programs.
• Periodic updates: Data can also be pulled early from the server without the user opening the program, rendering the page faster when the user opens the program, reducing user wait times.

3.2 Skeleton screen

When the page data is not ready (if it needs to be obtained over the network), try to avoid showing blank pages, you should first display the approximate structure of the page through the skeleton screen, request the data back after the page update. to increase the user's willingness to wait.

3.3 Cache request data

The widget provides the ability to read and write local caches such as wx.setStorage, wx.getStorage, etc., where data is stored locally and returned faster than network requests. If developers are unable to use data pre-pull and periodic updates for some reason, we recommend that you prioritize getting data from the cache to render the view, waiting for the network request to return and update it.

3.4 Thin first-screen data

We recommend that developers delay requesting non-critical rendering data, and try not to put data independent of view layer rendering in data to speed up page rendering completion times.

Fourth, start performance analysis

1. Performance data acquisition

1.1 Small program assistant "Performance Analysis" section

The performance data of the small program management background has not been updated, is planning the revision, it is recommended that the developer take the performance data of the small program assistant before the revision is completed.

Developers are advised to use the Performance Analysis section in the Small Program Assistant to keep an eye on the performance of the small program. P erformance analytics provides performance data from the three dimensions of startup performance, operational performance, and network performance for developers to refine based on platform, model, network environment, and access sources. Scan the small program code below for immediate experience.

Currently, only weChat clients are included in the small program assistant, which is the official version of the program data.

1.2 Get it in a small program through the API

Developers can dot performance in small programs based on their business needs, or they can use wx.getPerformance to get information about the performance of current small programs.

After obtaining information, developers can self-report or use wx.reportPerformance for speed measurement.

1.3 Experience rating

Experience scoring tools are available in the gadget tool to enable developers to spot experience problems with the gadget in a timely manner.

2. Factors that affect startup performance

According to the startup process described in the "Startup Process" section, there are many factors that affect the time it takes for a small program to start, and analyzing the startup performance of a small program is a complex process.

For the same small program, the following factors directly affect the average startup time:

• Platform: There are big differences in device performance, operating system, framework implementation, optimization scheme, etc. under different platforms (Android, iOS, PC, etc.), and there are also big differences in startup time. se.
• Download scale: Both code pack downloads and updates can significantly affect the time it takes for small programs to start, and for large-scale startup times to increase when other processes are time-consuming and stable.
• Entry page: When different pages start, the number and size of code packages to download and the amount of code injection vary depending on the subcontract. There are also differences in page rendering time.
• Model distribution: Startup time and device performance are strongly correlated, and differences in user populations for different small programs or usage scenarios can lead to differences in model distribution, which in turn can affect the startup time of the large market.
• Network environment: Network environment mainly affects the time-consuming network request, such as small program information acquisition, code package download, etc.

In addition, the following conditions indirectly affect startup time:

• Scene/Access Source: Different pages visited by users in different scenarios, the purpose of the visit and their willingness to wait vary, which has an impact on startup time and opening rate.
• First-time access to user scale: When a user first accesses a small program, they need complete preparation of the small program information, the process of downloading the code package, and the code cache needs to be rebuilt, which can take more time to start than non-first-time access.
• Small program version update: When the little program version is updated, the user needs to update the gadget information and code package, the code cache also needs to be rebuilt, and the startup time will rise.

About Performance Analysis section data

The small program assistant provides developer-related download time, js injection time, and initial rendering time for developer optimization.

It's important to note here that startup takes a total ≠ download time, js injection time, and initial rendering time. /b10>During the startup process, the download does not necessarily occur, nor does it have to download only one code pack. js injection time and rendering time can also fluctuate due to cache updates.

The decrease in time-consuming at each stage does not necessarily reflect the decrease in total time-consuming. For example, after a new version of a small program is released, even if the time-consuming period decreases at each stage, an increase in the download rate can lead to an increase in total time-consuming.

3. Factors that affect the opening rate

Startup performance and the user's willingness to wait are two key factors that affect the open rate. In some scenarios, if the user's willingness to wait is low, they may not necessarily get a higher opening rate, even if the startup time is low.