01
Problem background
With the rapid increase in the group's mobile office demand, we have exported more and more H5 pages embedded on the basis of the group's APP. During the docking development process, we found that the opening time of the first screen of APP docking with some H5 pages was very slow, even reaching a waiting time of 8s to 9s. In response to this problem, the technical team constantly explored to try to optimize the waiting time for the first screen of the H5 page to achieve the first screen of the H5 page to reach the second opening. Let's share with you on troubleshooting, process analysis and solutions.
02
Troubleshooting and analysis
Before troubleshooting, find out what happens when the page is opened?
figure 1
As shown in the figure above, you first need to resolve the URL to the corresponding IP address through DNS (domain name resolution system), then establish a TCP network connection with the server determined by the corresponding IP address, and then throw an HTTP request to the server, and the server processes the request. After that, the target data is returned to the client in the HTTP response, and the browser that receives the response data can start the rendering process. After rendering, the page is presented to the user, and it is always waiting to respond to the user's operation. This article analyzes HTTP requests, HTTP responses to page rendering, and does not analyze DNS resolution and TCP connections.
The development of this project is based on the H5 development of the WebView embedded in the APP, so let's first understand the analysis of the WebView. The WebView startup process is roughly divided into the following stages:
Figure 2 ( picture from https://tech.meituan.com/WebViewPerf.html )
Observing Figure 2 we can find that the time-consuming time for the white screen problem occurs between the establishment of a connection to the second rendering page, that is, in the steps of obtaining static resources, parsing static resources, and page rendering. Next, look at the project. Download the packet data, as shown in Figure 3:
image 3
The possible causes caused by the combination of the captured data and the above analysis are:
Static resources such as CSS and JS are too large;
Too many HTTP requests;
The pictures in the homepage column are large and not compressed;
HTTP cache is not used;
Network fluctuations cause unstable speed.
03
solution
Through the above-mentioned investigation and analysis, we have optimized the above problems one by one.
1
HTTP request direction optimization
In the above analysis, the first item of static resource is too large, which requires more download time for each request. The second item, due to the limited number of concurrent browsers, when the number of requests is too large, it will cause blockage in the request process. The following optimization practices are carried out for the above two directions.
There are two main directions for HTTP optimization:
(1) Reduce the number of requests;
(2) Reduce the time spent on a single request.
These two optimization directions correspond to the compression and merging of resources in the front-end development process:
(1) We compress and merge static resources through the front-end development tool (webpack), and conduct multiple subcontracting and combined testing and verification, and finally find the optimal solution to reduce the volume of static resources, and combine static resources Consolidate packages to reduce the number of requests.
(2) At the same time, we also compress static files by Gzip, compressing static resources of 500kb to about 120kb, and compressing the total package from 700kb to about 350kb, reducing the volume by more than half, as shown in Figure 4:
Figure 4
(3) Then observe the capture situation. Compared with static resources such as CSS and JS, the performance improvement of image requests is a critical step, so we also need to optimize for images. First, optimize the business plan to reduce the number of high-definition images to be displayed in the homepage list. At the same time, with the cooperation of back-end developers, we have made many attempts to reduce the size of the pictures as much as possible without reducing too much quality, and use different formats of pictures in different scenarios (JPEG/JPG, PNG, SVG, Base64, Sprite, etc.). Through the above methods, we have reduced the number of pictures and the size of the pictures, so that the performance of the page has been improved.
(4) The above is all about requesting static resources. Next, we will cooperate with back-end developers to use the HTTP caching function. When static resources are not updated, there is no need to repeatedly request server resources. Using HTTP protocol caching can effectively reduce server requests and improve page access speed.
(5) CDN is used in the project so that static resources can be obtained through closer and faster channels.
2
Browser rendering level optimization
After introducing the optimization scheme in the HTTP direction above, we will optimize the browser rendering level. First of all, we understand that the browser kernel can be divided into two parts: rendering engine and JS engine. The rendering engine includes HTML interpreter, CSS interpreter, layout, network, storage, graphics, audio and video, picture decoder and other components. We optimize each component in the following list to make our page Faster during rendering.
(1) HTML interpreter: After lexical analysis of HTML documents, output the DOM tree;
(2) CSS interpreter: parse CSS documents and generate style rules;
(3) Layer layout calculation module: the layout calculates the precise position and size of each object;
(4) View drawing module: draw the image of a specific node, and render the pixels to the screen;
(5) JavaScript engine: compile and execute JavaScript code.
Let's take a look at the entire process of browser rendering:
Figure 5
Based on the above list and process, let's optimize the rendering layer:
(1) In the optimization of HTML, we try to reduce the DOM structure, reduce the level, and simplify the HTML structure as much as possible.
(2) Avoid the use of wildcards in CSS optimization, select only the elements that need to be used, and use inherited attributes to avoid repeated matching and repeated definitions, and use tag selectors less and class selectors instead.
(3) At the same time, optimize the loading sequence of blocked resources and download CSS to the client as soon as possible to shorten the first rendering time. Use async and defer to load JS files to prevent blocking.
(4) In the process of operating the DOM, reflow and redraw are reduced, the parts that need to be modified are cached, and the modification completes a rendering.
(5) Use lazy-load to load lazy, only the static resources and pictures needed in the first screen are loaded at the first screen, and other resources are loaded asynchronously.
(6) Use throttling and anti-shake on the homepage, wrap scroll events, keyboard events, etc. through the callback function corresponding to the event, and cache time information in the form of free variables. Finally, setTimeout is used to control the trigger frequency of the event, and the throttling and anti-shake is implemented in the form of closure to reduce requests or manipulate the DOM.
We optimized the project through the above two levels of HTTP request/response and browser rendering. Through the packet capture results shown in Figure 6 to compare before and after optimization, it can be seen that the optimization has achieved very good results. The size of the request has been reduced by 85%, and the opening time after optimization is about 1.5s, which is several times faster than before optimization, which proves that our optimization enables users to have a better experience.
Figure 6
04
to sum up
In the early stage of project development, we went through technology selection and tried various technology stacks. In order to solve the positioning problem in the long list page, the original jQuery was replaced with a single-page application technology stack Vue that can provide a better user experience. Its modularity allows developers to develop and maintain better. In the development process, through the above-mentioned directions, such as how to request the network, how to render the page, and how the browser handles it, we have optimized performance and achieved very good results. Of course, if you want to have a better user experience, you can also make the page more friendly in more ways. For example, you can use server-side rendering to make our home page only need to parse HTML, reducing many other time-consuming steps, and making the page more accessible. Have a better experience. Pictures can also use WebP format to reduce size and improve quality. The application of PWA allows our pages to be accessed offline like a client. Of course, good optimization needs to have corresponding trade-offs for different projects. I hope that everyone can make the most suitable optimization based on the above content and combined with the projects developed by yourself.