Example analysis: HTML5 front-end performance testing (graphic)

This article brings the content is about the example analysis: HTML5 front-end performance test (graphics and text), there is a certain reference value, there is a need for friends to refer to, I hope you have some help.

H5 page is flexible, lightweight, and has cross-platform features, there are many application scenarios in the business. But at the same time compared to APP,H5 performance is always inferior to one, such as the page will often appear white screen, sliding list and other interactive scenarios than Native page fluent. For these white screen, card slow and so on, we test the aspects of how to expand the test analysis and data comparison? Next, I share some experience of H5 front-end test practice, I hope we all talk together, and dig more valuable topics together.

First, opening: H5 page loading Process analysis

As shown, there are several procedures for selecting a platform to open the H5 page.

Figure one to figure four can be easily categorized, figure one is the App is responsible for doing things, mainly to initialize the Webview context; The next three images are a H5 page loading process. The time spent in this phase of the App, mainly the time-consuming Native code, is not discussed here, and we focus on the next few stages. The fourth figure is the first screen that the user intuitively sees, and we are often called the first screen .

1) Load Network request

This process is mainly Webview get H5 page URL, call Loadurl method, start to go to the network to request the first resource file. This phase mainly includes the DNS resolution, the establishment of network links, the time-consuming data transmission.

2) HTML parsing

After Webview gets the HTML back, it needs to parse the tags and contents from top to bottom, identify the outer chain resources, calculate the layout of the page frame, and render the rendering. In this process, the DOM tree responsible for the page structure and the Render Tree responsible for the page layout are built, as shown in:

3) External chain resource loading

This part is mainly from the network loaded outside the chain of CSS, pictures and JS, and then re-populate the HTML. Then you re-make layout calculations and page rendering drawings, and what you see is a page with full content. As shown, the page needs to wait for pictures and CSS to display, JS is also the external chain resources, but generally, as long as the HTML at the bottom of the load, it will not block the page rendering and display.

Second, case analysis: white screen problem

We already know the H5 page loading process, then if we encounter white screen, we will naturally ask, how can we know the current stage of the page, how long each stage, and the overall first screen load time-consuming?

First look at the case where the H5 page is simulated via PC Chrome. Chrome Devtool provides a performance tool that can record pages from the first request to the loading of all events, in this way you can see in detail the things done in each stage and the specific time-consuming.

Two of the most critical first screen time-consuming metrics:domcontentloaded (the first screen is visible) and onLoad (first screen loading complete) time-consuming, in addition to the method shown, but also through the console To print the global variable window.performance.timing, get the timestamp and calculate it.

But what we actually want is the real data of the mobile device, which can really reflect the performance of the page and the user experience. One way to get the H5 real time is to escalate the JS code, and the other is for Android devices, you can remotely debug the real Machine page in a remote-debug way. Just make sure that the webview debug switch opens & connects to the PC USB connection and turns on USB debugging, so you can access Chrome://inspect in PC Chrome to get debugging objects. Then refer to the PC Chrome simulation H5 method to get the data.

For the traditional page, the actual analysis found that most of the time is still in the mobile network request this part, so the most direct and effective way is to direct the page to transform, that is, to change the loading of HTML, then load the CSS and other data, first in the back end (such as Nodejs) parallel loading of the first screen dependent on all the CSS, JS and background interface data, assembled good one finished the final HTML to render back to the front end, to achieve the effect of seconds .

Third, case analysis: Card slow problem

Sometimes users in the process of page interaction will encounter card slow, such as sliding list up and down, left and right switch or carousel. This process is nothing more than executing JS, requesting resources, calculating a new page layout, and rendering the drawing. Through performance analysis will find, card slow actually not all is a lot of people think of "transfer equipment performance is poor", sometimes is actually false lag.

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

Real card situation, often the foot of the newspaper wrong accounted for a large proportion, the intuitive performance is that the page is stuck, not slow. Other problems, such as memory, usually show that the page is getting more and more cards, because the longer it takes, the greater the resource consumption. For example, the page uses more complex canvas animations, performance-intensive IFRAME elements, or live streaming media, in which case memory leaks are prone to occur.

This is the memory leak caused by the DOM node, the unused list of Commentlist is not released, the more accumulate to tens of thousands of of the length of time to start stalling.

Iv. Summary: H5 front-end performance test plan

Of course, the front-end performance is not only in white screen, lag problem, it may be the phone over-heating and so on. Starting from the user's core experience, we believe that the most important reference standard for H5 front-end performance is to give the user the best experience in the lightest way possible. In this direction, we have accumulated a number of testing experience, the most important of which is the first screen speed (not only to improve the user experience, but also to improve the business conversion rate), followed by smoothness, traffic and CPU, and some scenarios are also need to focus on the point.