The small program measures speed

To help developers optimize the performance of small programs, we have introduced the "small program speed measurement" feature. " Small program speed measurement" can easily and easily count the real-time time-consuming situation of an event in a small program, and can be based on geographical, operator, operating system, network type, model and other key dimensions of real-time cross-analysis. Starting with the basic library 2.9.2, after the developer reports the time-consuming situation of an indicator through the "speed escalation" interface, they can view the time-consuming trends of each indicator in the background of the small program management "Development - Operations Center - Small program speed measurement" and support the real-time viewing of minute-level data.

Create a new monitoring ID

In order to achieve time-consuming monitoring of a metric, developers need to define monitoring metrics first. Create a new monitoring ID in the small program management background: "Development - Operations Center - Small program speed measurement" and fill in the name and explanation of the monitoring metrics.

Click "New" to create a new ID, you need to select the indicator type and fill in the indicator name and the corresponding explanation of the indicator. Monitoring metrics fall into two categories:

Network Request Class: This type of time-consuming is primarily influenced by the network environment and includes statistical dimensions such as operating system, carrier, network environment, region, and so on. S uch as network api time-consuming, cloud call time-consuming, network data read and write time-consuming, etc. Note that up to 20 such indicators can be created.

Load/render class: This type of time is primarily affected by device performance and includes statistical dimensions such as operating system, model category, and so on. C an be used to measure page switching time, component rendering time, and so on. Note that up to 20 such indicators can be created.

After new construction, you can see the monitor ID that is needed to be used.

Measurement report

After the developer defines the monitoring ID, you need to call in the small program code. wx.reportPerformance The time-consuming time-consuming monitoring is achieved on the interface:

Undering Method 1: Judgment using CaniUSE

// * 需要使用 canIUse 判断接口是否可用
if (wx.canIUse('reportPerformance')) {
  wx.reportPerformance(id, val)
}

Reporting Method 2: Judgment using CompareVersion

// * 需要先使用 compareVersion 判断接口是否可用
const sdkVersion = wx.getSystemInfoSync().SDKVersion
if (compareVersion(sdkVersion, '2.9.2') >= 0) {
  wx.reportPerformance(id, val)
}

Both ID and val are UINT32 type, where ID is the monitor ID defined by the small program management background, VAL is the time-consuming value (calculated by the developer).Interface calls require the version number of the base library above 2.9.2, otherwise it may be wrong in some low version of the base library.

(compareVersion definition)

Data observation

Once the code escalation is complete, you can view the time-consuming trends for each metric in the small program management background , Development - Operations Center - Small Program Speed Measurement. Currently, online data has a data delay of approximately 15 minutes, and escalation data is retained for 7 days, which can be aggregated at different time granularity, such as 1 minute - 1 hour.

Each indicator can observe two curves, the mean curve and the escalation curve.

​

At the same time, for different dimensions of data, we provide cross-comparison function to help you quickly and easily complete the analysis, note that the number of cross-comparison curves can not exceed 10.

For network request class metrics, we provide a region map to help you quickly locate regional resource issues.

Custom dimensions (optional features)

For more complex user scenarios, users may need to segment speed measurement data based on url, pages, and other dimensions, so we provide custom dimensions that allow users to fill in some business-level dimension strings into custom dimensions for ease of business analysis. C urrently, the number of custom latitude values for each metric needs to be limited to 50 (data that exceeds the limit is discarded), and the length of the custom dimension value needs to be limited to 256 bytes (the value of the super-limit is truncated). The effect of a custom dimension is as follows: To use a custom dimension, simply add a third parameter, dimensions, to the wx.reportPerformance to escalate the custom dimension:

wx.reportPerformance(id, value, dimensions)

(wx.reportPerformance documentation)

Q&A

Q : In what scenarios can the speed measurement system function?

A: You can measure network class metrics (e.g. network call/cloud call time, network data read and write speed, etc.) and non-network class metrics (page switching loading speed, component rendering speed, etc.). Y ou can see how these metrics differ in quantity distribution and performance across dimensions. In some calculated video first-screen delay, frame rate and other scenes can also play a role.

Q: What is the base library version required to escalate the API?

A: More than version 2.9.2 of the base library is required. Errors may be reported on some low-version base libraries, and subsequent canIUse interfaces are supported for judgment.

Q: Can the system be re-beta? W hat is the approximate escalation delay? How long does the data last?

A : Can be used in beta and the current escalation delay is about 15 minutes. The data is saved for 7 days.

Q: How many indicator IDs can I define?

A: A single applet can define 20 IDs per category.