H5 page release is flexible, lightweight, and has the characteristics of cross-platform, there are many application scenarios in business. But at the same time, the performance of H5 is always inferior to that of App. For example, a blank screen often appears when the page is opened, and it is not as smooth as Native page in interactive scenes such as sliding list. For these white screen, slow and other problems, we test from what aspects to carry out test analysis and data comparison? Next, THE author shares some experience of H5 front-end testing practice, and hopes that we can talk about it and explore more valuable topics together.

I. Introduction: Analysis of the loading process of H5 page

Here are a few screenshots of the process of opening the H5 page on selected platforms.

Figure 1 to Figure 4 can be categorized simply. Figure 1 shows what the App is responsible for, mainly initializing the Webview context. The next three images are an H5 page loading process. Among them, the time-consuming of App stage is mainly the time-consuming of Native code, which will not be discussed here. We will focus on the later stages. The fourth figure is the first screen that the user sees intuitively, which is often referred to as the first screen.

1) Load the network request

After the Webview gets the H5 url, it calls the loadUrl method to request the first resource file on the network. This phase involves the time required for DNS resolution, network connection establishment, and data transmission.

2) HTML parsing

After the Webview gets the HTML back, it needs to parse the tags and content in the HTML from top to bottom, identify the external link resources, calculate the layout of the page frame, and render it. In this process, we build the DOM Tree responsible for page structure and the Render Tree responsible for page layout display, as shown below:

3) External chain resource loading

This part is mainly from the network to load external chain CSS, images and JS, etc., and then refill into the HTML. Then re-evaluate the layout calculation and render the page to see the complete content of the page. As shown in the figure below, pages need to wait for images and CSS to load before they can be displayed. Js is also an external resource, but generally speaking, as long as it is loaded at the bottom of the HTML, it will not block the rendering and display of the page.

Two, case analysis: white screen problem

How do you know what stage the page is in, how long each stage takes, and how long it takes for the entire first screen to load?

Let’s take a look at emulating the H5 page from PC Chrome. The Performance tool, provided by Chrome Devtool, can record all the events from the first request to the completion of the page load. This way, you can see in detail what is done in each stage and the specific time.

Two of the most critical first screen time metrics are: First screen page domContentLoaded * * (visible) and onLoad (the first screen loaded) * * time-consuming, in addition to the graphic method, you can print global variables in the console window. Performance. The timing, to get the timestamp and calculated.

But what we really want is real data on mobile devices, which is a true reflection of page performance and user experience. Want to get H5 real machine time, one way is to report js code; The other is for Android devices, you can use remote-debug to remotely debug the real page. Just make sure the WebView debug switch is on & connect to PC USB and enable USB debug, you can access Chrome ://inspect in PC Chrome to get the debug object. Then refer to PC Chrome simulation H5 method to get the data.

For traditional pages, the actual analysis found that most of the time is still spent on mobile network requests, so the most direct and effective way is to directly transform the page, that is, to change the loading of HTML, CSS and other data. First, the back end (such as NodeJS) loads all CSS, JS and background interface data that the first screen relies on in parallel, and then assemble a finished HTML to be presented and send it back to the front end to achieve the effect of opening in seconds.

Three, case analysis: slow problem

Sometimes users experience a lag in page interaction, such as scrolling up and down a list, switching left and right, or rotating. This process is nothing more than executing JS, requesting resources, calculating a new page layout, and rendering. Through the Performance analysis, it can be found that the slowness is not all the “poor Performance of transfer equipment” that many people think, but sometimes it is false slowness.

For example, the following is the problem of too small hot zone:

In the case of real card, often the script error accounted for a large proportion, intuitive performance is the page is stuck, rather than slow. Others, such as memory issues, usually show up as pages become more and more jammed because the longer they are used, the more resources they consume. Pages that use complex Canvas animations, performance-intensive IFrame elements, or live streaming are prone to memory leaks.

Here is a memory leak caused by dom nodes, where the list of commentlists that are not used is not released and starts to pile up to tens of thousands of commentlists.

Iv. Summary: H5 front-end performance test scheme

Of course, front-end performance is not only shown in the white screen, the lag problem, but also may be the phone overheat and so on. From the perspective of user core experience, we believe that the most important reference criteria for H5 front-end performance is to provide the best user experience in the lightest way possible. From this perspective, we have accumulated some experience in testing, among which the most important requirement is first screen speed (which not only improves user experience, but also improves business conversion rate), followed by fluency, flow, CPU, etc., which also need to be considered in some scenarios.