Home > Article > Web Front-end > Example analysis: HTML5 front-end performance test (graphics and text)
The content of this article is about case analysis: HTML5 front-end performance test (pictures and texts), which has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.
H5 page publishing is flexible, lightweight, and cross-platform. It has many application scenarios in business. But at the same time, compared with the App, the performance of H5 is always inferior. For example, a white screen often appears when the page is opened, and interactive scenarios such as sliding lists are not as smooth as Native pages. In view of these problems such as white screen and slow lag, from what aspects should we carry out test analysis and data comparison? Next, the author will share some practical experience in H5 front-end testing and provide some inspiration. I hope everyone can talk about it and explore more valuable topics together.
As shown in the figure below, 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 the App is responsible for, mainly initializing the Webview context; the following three pictures are It is the process of loading an H5 page. Among them, the time consuming in this stage of App is mainly the time consuming in Native code. We will not discuss it here. We will focus on the following stages. The fourth picture is the first screen that users intuitively see, which we usually call first screen.
1) Load network request
This process is mainly after Webview gets the H5 page url, Call the loadUrl method to start requesting the first resource file on the network. This stage mainly includes the time spent on DNS resolution, establishing network links, and data transmission.
2) HTML parsing
After Webview gets the html and returns it, it needs to parse the tags and content in the html from top to bottom, identify external link resources, and calculate the page frame The layout is drawn and rendered. In this process, the DOM Tree responsible for the page structure and the Render Tree responsible for the page layout display will be constructed, as shown in the following figure:
# #3) External link resource loading
This part mainly loads the css, pictures and js of external links from the Internet, and then repopulates them into HTML. Afterwards, the layout calculation and page rendering are performed again. At this time, what you see is the page with complete content. As shown in the figure below, the page needs to wait for the images and css to be loaded before it can be displayed. js is also an external link resource, but generally speaking, as long as it is loaded at the bottom of html, it will not block the rendering and display of the page.
The two most critical first-screen time-consuming indicators:
domContentLoaded (the first-screen page is visible) and OnLoad (first screen loading completed) time-consuming, in addition to the method shown in the diagram, you can also get the timestamp and calculate it by printing the global variable window.performance.timing in the console.
But what we actually need is real data from mobile devices, so that we can truly reflect page performance and user experience. If you want to get the H5 real device time consumption, one way is to report it with js code; the other is for Android devices, you can use remote-debug to remotely debug the real device page. You only need to ensure that the webview debugging switch is turned on & connected to PC USB and USB debugging is enabled, you can access chrome://inspect in PC Chrome to obtain the debugging object. Then refer to the method of simulating H5 on PC Chrome to get the data.
For traditional pages, actual analysis found that most of the time is spent on mobile network requests, so the most direct and effective way is to directly modify the page, that is, to load HTML first, then load CSS and other data In this case, first load all the css, js and background interface data that the first screen depends on in parallel on the back end (such as nodejs), assemble a completed html that will eventually be presented, and then return it to the front end to achieve seconds opening Effect.
Sometimes users will encounter slowdowns during page interaction, such as sliding lists up and down, switching left and right, or wheeling. Broadcast and so on. This process is nothing more than executing js, requesting resources, calculating new page layout, and rendering. Through Performance analysis, you will find that slow lags are not all caused by "poor performance of the transfer equipment" as many people think. Sometimes they are actually false lags.
For example, the following problem is that the hot zone is too small:
In the case of real lag, script errors often account for a large proportion. The intuitive manifestation is that the page is stuck, not slowed down. Other problems, such as memory problems, usually manifest as the page becoming more and more stuck, because the longer it is used, the greater the resource consumption. For example, if the page uses more complex canvas animations, more performance-consuming iframe elements, or live streaming media, memory leaks are prone to occur in this case.
The following is a memory leak caused by the dom node. The unused commentList list is not released. It accumulates more and more and starts to freeze when the length reaches tens of thousands.
first screen speed (which not only improves user experience, but also improves business conversion rate), followed by fluency, traffic and CPU, etc., are also important considerations in certain scenarios.
Related recommendations:
Dry information|Mobile H5 front-end performance optimization_html/css_WEB-ITnose
Front-end performance】High-performance scroll and page rendering optimization_html/css_WEB-ITnose
The above is the detailed content of Example analysis: HTML5 front-end performance test (graphics and text). For more information, please follow other related articles on the PHP Chinese website!