Shulou(Shulou.com)06/02 Report--

This article mainly explains the "H5 front-end performance example testing tutorial", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn the "H5 front-end performance example testing tutorial"!

First, the beginning: a brief analysis of the loading process of H5 page

As shown in the following figure, there are several screenshots of the process of opening the H5 page on the selected platform.

Figures 1 to 4 can be simply classified, figure 1 is what App is responsible for, mainly initializing the Webview context; the next three figures are a H5 page loading process. Among them, the time-consuming of this phase of App is mainly the time-consuming of Native code, so let's not discuss it here, let's focus on the next few phases. The fourth picture is the * * screen page that users can see directly, which we usually call the first screen.

1) load network request

The main process is that after Webview gets the H5 page url, it calls the loadUrl method and starts to request * resource files on the network. This stage mainly includes the time-consuming of dns parsing, establishing network links and data transmission.

2) html parsing

After Webview gets the html and returns, it needs to parse the tags and contents in the html from top to bottom, identify the outer chain resources, calculate the layout of the page frame, and render it. During this process, the DOM Tree responsible for the page structure and the Render Tree responsible for the page layout display are built, as shown in the following figure:

3) external chain resource loading

This part is mainly from the network to load outside the chain of css, pictures and js, and then re-fill into the html. After that, do the layout layout calculation and page rendering again, and what you see at this time is the page with complete content. As shown in the following figure, the page can not be displayed until the image and css are loaded. Js is also an external chain 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.

Second, case analysis: the problem of white screen

We have already learned about the H5 page loading process, and then if we encounter a white screen, we will naturally ask, how do we know which stage the page is currently in, how long each stage takes, and how long it takes to load the first screen as a whole?

First, take a look at the simulation of the H5 page through PC Chrome. The Performance tool provided by Chrome Devtool can record all events from * * requests to the completion of loading. In this way, you can see in detail what is done in each stage and the specific time-consuming.

Two of the most critical time indicators of the first screen: domContentLoaded (the first screen is visible) and onLoad (the first screen is loaded). In addition to the graphic method, you can also print the global variable window.performance.timing in console, get the timestamp and calculate it.

But what we really need is the real data of the mobile device, which can truly reflect the page performance and user experience. To get the H5 real machine is time-consuming, one way is to report the js code; the other is that for Android devices, you can use remote-debug to remotely debug the real machine page. Just make sure that the webview debug switch is on & connect to PC USB and enable USB debugging, and you can access chrome://inspect in PC Chrome to get debug objects. After that, you can get the data by referring to the method of simulating H5 by PC Chrome.

For traditional pages, the actual analysis shows that most of the time is spent on mobile network requests, so the most direct and effective way is to modify the page directly, that is, to change the situation of loading html, css and other data first, loading all the css, js and background interface data that the first screen depends on in parallel at the back end (such as nodejs), assembling a finished html to be rendered and then returning it to the front end. To achieve the effect of opening in seconds.

Third, case analysis: slow card problem

Sometimes users get stuck in the process of page interaction, such as sliding the list up and down, switching between left and right, or rotation, and so on. This process is nothing more than performing js, requesting resources, calculating a new page layout, and rendering. Through Performance analysis, we will find that slow card is not all that many people think that "the performance of the transfer device is poor", sometimes it is actually a false stutter.

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

In the case of real card, often foot newspaper error accounts for a large proportion, the intuitive performance is that the page is stuck, not slow down. Other problems, such as memory problems, usually show that the page is getting more and more stuck, because the longer it is used, the greater the resource consumption. For example, the page uses more complex canvas animation, more performance-consuming iframe elements, or live streaming, in which case memory leaks are easy to occur.

The following is the memory leak caused by the dom node. The unused commentList list is not released, and it begins to stutter when it grows to tens of thousands in length.

At this point, I believe you have a deeper understanding of the "H5 front-end performance instance testing tutorial". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.