The enterprise wechat terminal product “C-terminal user small program” is a tool that serves vivo offline agents, stores and shopping guides to connect users and quickly communicate with users. The amount of PU/UV based on “C-side applets” is relatively large. In order to provide more extreme user experience, it is inevitable to improve the performance optimization of applets.

I. Business status quo

1.1 Existing users to operate enterprises’ wechat “Client Small Program”

The “user side small program” of wechat operated by existing users is mainly a tool that serves vivo agents, offline stores and shopping guides to help shopping guides connect users.

  • User group: Vivo offline users.
  • Main functions: Vivo new machine presale, new user registration.

Take a look at the pages of “New User Registration” and “New phone Presale” under “Client Applets” as follows:

Vivo new user registration

Vivo new phone presale

1.2 Performance Data

A picture is worth thousands of words. Let’s look at the data of “code package downloads, opening time distribution, network request delay, network traffic consumption” obtained from “small program Data Assistant” before the existing users run “small program”. As follows:

As can be seen from the figure, the download of the small program code package is mainly concentrated in 2-5 seconds. In addition, the time delay of some HTTP request interfaces is very long, which will affect the overall rendering effect of the page. It can be seen that there is still a lot of room for optimization of existing user operations.

Two, performance indicators

2.1 How do I define High Performance?

Simply fast is not enough. Instead of focusing on speed metrics and ignoring the user’s perceived experience, we should fully measure every node that users perceive during application loading.

2.2 Key terms of performance Indicators

FCP: Blank screen loading is complete

FMP: First screen rendering complete

TTI: All content is loaded

2.3 We optimized the targets to be achieved

Applets official indicators:

  1. The first screen time does not exceed 5 seconds.
  2. Render time does not exceed 500ms.
  3. SetData is called no more than 20 times per second.
  4. SetData data does not exceed 256KB after json.stringify.
  5. The number of WXML nodes on the page is less than 1000, the node tree depth is less than 30 layers, and the number of child nodes is less than 60.
  6. All network requests return results within 1 second.

Indexes to be achieved by “Client Applets” of stock user operation:

  1. The first screen time does not exceed 2.5 seconds.
  2. The amount of setData data does not exceed 100kb.
  3. All network requests return results within 1 second.
  4. Component sliding, long list scrolling without the sense of lag.

Three, some basic concepts of small programs

3.1 Basic framework of applets

The final rendering vehicle for applets is still the browser kernel, not the native client. The two-threaded model is enabled:

  1. View layer: the WebView thread is responsible for enabling different WebViews to render different applet pages.
  2. Logic layer: A single thread executes THE JS code and controls the logic of the view layer.

3.2 Startup steps of small programs

1. Prepare the operating environment.

  • Before starting the small program, wechat will start the dual-thread environment first, and complete the initialization and pre-execution of the basic library of the small program in the thread.

Applets base library includes WebView base library and AppService base library. The former is injected into the view layer, and the latter is injected into the logic layer, respectively, to provide the basic framework capabilities needed by the hierarchy to run.

2. Download the small program code package.

3. Load the applets code package.

  • At this stage, all page JS files and their dependencies within the main package are automatically executed.

During Page registration, the base library calls the Page constructor method of the Page JS file to record the basic information of the Page (including initial data, methods, etc.).

4. Initialize the home page of the applet.

  • After the applets are loaded, the base library will find the home page based on the startup path, initialize a page instance based on the basic information of the home page, and pass the information to the view layer, which will combine the WXML structure, WXSS style, and the initial data to render the interface.

3.3 Applet development Tools — Experience the scoring tools audits

(PS: Scoring plug-ins for the applet developer tools can be used to comprehensively score applet performance, user experience, practices, UI styles, HTTP requests, and other dimensions and are recommended for applet developers to use in their projects.)

Four, small program optimization technical scheme

4.1 Programs that start small programs too slowly

** Solution 1: ** useless files, functions, WXSS style removal, unnecessary import cut.

** Scheme 2: ** Reduce the static resource files in the code package.

In addition to some pictures must be placed in the code package (such as network exception prompt), it is recommended that developers put static resources such as pictures and videos on the CDN.

** Solution 3: Move the logic back and simplify the service logic.

Try to write the business logic in the back end, if there is an online problem, the small program version needs to be audited by Tencent, and the back end can release the code in time.

** Option 4: ** Subcontract loading and subcontract predownload.

  • Refer to the applets Open platform documentation

  • Independent of the subcontract

  • Subcontract predownload

** Scheme 5: ** part of the page h5.

  • The applet provides a Web-view component that enables access to H5 within the applet. If the small program source is too large to affect the download time, you can consider downgrading, the part of the page H5.

  • For details, see the web-view document.

4.2 Solution for a Long Blank Screen time of small Programs

White screen stage of the applet: After the applet code package is downloaded (that is, the end of the startup screen), the page completes the first screen rendering stage, also known as FMP (first effective rendering).

Two factors affecting the white screen:

  • Load time of network resources.
  • Render time.

Solution 1: Enable local caching.

  • The data obtained from the request interface is stored in the storage. Some data do not need to be obtained by sending HTTP requests each time.

Solution 2: Prepull when switching to a page.

  • The interface data is usually retrieved during page onload.
  • NavigateTo (wx. NavigateTo) can call the HTTP interface of the next page before calling wx.navigateTo, store the data in the global Promise, and fetch the data directly from the Promise in the next page onload.

(PS: Request HTTP interface of next page B through promise when onHide or onUnload of page A, and get data from Promise when onload or onShow of page B.)

Scheme 3: Delay requests for non-critical render data.

  • Divide the page into body modules (skeleton, list data) and non-body modules (popovers, etc.).
  • Data requests for non-body modules can be lazily loaded, using setTimeout to request the interface.

Scheme 4: Split screen rendering.

  • Split render non-body modules.
  • As shown below, we set module A as the main screen, and modules B and C as non-main screen. After the rendering of module A is completed, we will render modules B and C.

Scheme 5: skeleton screen.

  • A skeleton screen with stable size can be used to assist in the realization of real module occupying and instant loading.

Scheme 6: Limit the number of HTTP requests.

  • The maximum concurrency limit for Wx. request (HTTP connection) is 10.
  • The maximum concurrency limit for wx.connectSocket (WebSocket connection) is 5.

Scheme 7: Image resource optimization.

  • Use WebP format.
  • Picture cropping, compression, Sprite
  • Lazy loading of images

4.3 Improve rendering performance

Concept: When calling wx.navigateTo to open a new page, the applet framework does the following:

  • Prepare the new WebView threading environment, including initialization of the base library.
  • Initial data communication from the logical layer to the view layer.
  • According to the data of the logical layer, the view layer constructs the node tree (including node attributes, event binding and other information) by combining with WXML fragments, and finally completes the page rendering by combining with WXSS.

The rendering loss of the small program is mainly in the process of data communication and node tree creation and update. The direction of rendering performance optimization is as follows:

  1. Reduces the communication frequency between threads.
  2. Reduces the amount of data communicated between threads.
  3. Reduce the WXML node number.

Scenario 1: Merge setData calls.

Combine as many setData calls as possible into one.

Put only Data related to interface rendering in Data.

Scheme 2: Remove unnecessary event bindings.

Unnecessary click, touch, onPageScroll should not be triggered.

Scheme 3: Remove unnecessary node attributes.

Component nodes support attaching custom data datasets. When user events are triggered, the view layer transmits the event target and dataset data to the logical layer. The following cases:

<view class="tabbar-item" wx:for="{{list}}" wx:key="index"  item="item">
  <view @tap="tabFn" data-index="{{item}}">
  </view>
</view>
 
methods = {
  tabFn (e) {
    const item = e.currentTarget.dataset['item'];
    console.log(item); }};Copy the code

The larger the amount of custom data is, the longer the event communication takes. Therefore, minimize the amount of custom data or do not use custom data.

4.4 Troubleshooting the High Memory Usage of small Programs

When small programs occupy too much system resources, they may be destroyed by the system or recycled by the wechat client, leading to the death of small programs.

Scheme 1: Reclaim the setTimeout and setInterval timers of the page.

Each page of the applet has a separate WebView thread, but the logic layer is single threaded, that is, all webView threads share a JS thread, so that the page jumps and the timer runs.

Clear the timer at onHide or onUnload.

Solution 2: Avoid heavy memory operations in frequent events.

  • The onPageScroll event callback uses throttling.
  • Avoid CPU intensive operations, such as complex calculations.
  • Avoid calling setData or reducing the size of setData.

5. Results after optimization

5.1 Take a look at audis’ score

The scores before optimization are as follows:

After optimization, the scores are as follows:

It can be seen that after the performance optimization of the small program in accordance with the above steps, the comprehensive score of Audis has a significant improvement.

5.2 Performance data in “Small Program Data Assistant” after optimization

Six, summarized

Applets performance optimization, like H5 optimization, is a process of continuous iteration based on diverse user scenarios, and it is also a lingering principle and theme of our daily web development. This paper discusses various scenarios and schemes of small program optimization, hoping to continue to optimize and create a better product in the future project development process.

Author: Vivo Fu Weilang