Analyzing Touch Response Latency of Web Pages

The following figure shows the effect of loading a web page using the Web component on ArkTS. Upon touching a text block, the user may notice a considerable lag before the animation effect commences. To measure the touch response latency, the performance metric commences at the moment the user touches an app element and concludes when the app UI starts to alter. To ensure a prompt response and uphold a seamless user experience, this alteration should occur within 100 ms. You can use DevEco Profiler to quantify the touch response latency and determine whether optimization is required.

Figure 1 Scene-specific animation

1. Confirm the start point. If the event is triggered by a touch, find the DispatchTouchEvent item on the app, as shown by the dotted line in the following figure.
   Figure 3 Trace start point

   

2. Confirm the end point. Select the first frame of stable Vsync signals rather than unstable Vsync signals as the end point, because unstable Vsync signals may not trigger rendering on the UI. This section analyzes the touch response latency from when an app element is touched until the app UI starts to change. Therefore, the first frame of stable Vsync signals is selected as the end point.
   Figure 4 Trace end point

   

   As shown in the figure, the subsequent animation has reached the maximum frame rate, indicating that the unresponsive period occurs within the area in the figure.

3. Based on the analysis of the H:ReceiveVsync signal, you can find that several frames occur in the unresponsive phase, but the time consumed by each frame is short. This is also true on the app side, indicating that no heavy load exists in the UI drawing process.
   Figure 5 Analyzing the trace frame rate

   

4. In this process, the app occupies the CPU for a long time possibly due to extensive computations.
   Figure 6 Possible causes for time-consuming operations

   

According to the preceding analysis, excessive computations may be generated on the web side. You need to use DevTools for further analysis.

Figure 7 Area division in the DevTools lane graph

• Area ①: an area which contains the start point. Enter Event to search for touch events.
• Area ②: an area for loading components. It is responsible for JavaScript (JS) execution.
• Area ③: an area which contains the end point of the response. The first frame of the frame lane is displayed.
• Area ④: an area for animation. It is responsible for executing animation.
• Area ⑤: a blank area. It is generally caused by delay functions such as setTimeout.

This page does not involve network interactions. Therefore, some areas such as the network area are not marked. Examples will be provided later.

Example for Analyzing Common Issues

When you touch to switch on the HTML5 page, the Web component has been initialized, and the touch event is processed by the Web component. This process mainly occurs in areas ①, ②, ③, and ④ in the following figure.

Figure 8 Area division in the DevTools lane graph

The following process is executed after a touch:

1. The web navigation waits for the first non-blank frame to be rendered on the home page.
2. The main resource of the main page is downloaded, parsed, and rendered. Then, the sub-resources are downloaded, parsed, and rendered alternately.
3. If the main resource is rendered and is not a blank frame, the navigation animation is invoked and the page responds.
4. If the main resource is rendered and is a blank frame, the web page discards the frame. The first non-blank frame rendered by the subsequent sub-resources invokes the navigation animation and the page responds.

The response is slow due to the following reasons:

1. The structure of the main resource rendering component is complex and time-consuming.
2. The main resource is empty, the sub-resources are dynamically loaded, and therefore the first frame display is delayed.

This following describes the component loading exception, network exception, animation exception, and blank area exception.

Analyzing Exceptions in the Component Loading Area

This matches area ② in the following figure. You can record the time consumed for loading the content.

Figure 9 Area division in the DevTools lane graph

Exceptions:

1. The time consumption of an area is long, for example, about 290 ms in area ②, which can be optimized.
2. Multiple areas involve loading and rendering components, which might be dynamically loaded, thereby causing a long latency. In this case, you can observe a large number of myFun1 calls. Tap the lower left corner to go to the source code.

Figure 10 Area division in the DevTools lane graph

The following figure shows the time consumed by the source code.

It can be seen that the source code shows the time consumed by a specific method. The myFun1 method uses recursion, which greatly increases the CPU computing time and causes response latency. The recursive method myFun1 is optimized to the loop method myFun2. The time complexity is reduced from O(2^n) to O(n), which significantly reduces the time consumption in this scenario. According to the test, the actual time consumed by myFun2 is measured in microseconds, which cannot be collected by DevTools. You are advised to use other methods to collect and analyze the function time consumption.

Analyzing Exceptions in the Network Area

The high ratio of time consumed on a network usually occurs in the response phase. After a request on a network is complete, the JS or task execution thread is blocked. As a result, the overall time consumption increases significantly. For details, see area ② in the following figure.

Figure 12 Area division in the DevTools lane graph

Analyzing Exceptions in the Animation Area

If there is a large difference between the trace start point and end point of the response time tested in area ④, an exception may occur in the animation area. Typically, the background color of the page in the animation is transparent, and the animation curve is slow and then fast. As a result, when the animation starts, the transparent background does not change visually.

Figure 13 Area division in the DevTools lane graph

Analyzing Exceptions in the Blank Area

This matches area ⑤ in the following figure.

Figure 14 Area division in the DevTools lane graph

Exceptions:

1. The network request takes a long time. As a result, page elements cannot be rendered and displayed in a timely manner.
2. After the timer waits, the timer-related function execution can be found in the blank area.

If the timer delay function await delayFun(500) exists in the code, remove the redundant latency function for optimization.

After the optimization measures are taken as mentioned in the preceding analysis, you can call DevTools again for analysis.

Figure 15 Lane graph after optimization

The consumed time is significantly reduced and changes to the normal value.