Writing in the front

This article was first published on wechat: CoyPan as expected

Performance optimization is an inevitable topic in front-end development. This paper will record a client H5 page first screen performance optimization project.

background

Information flow App is one of the most popular products at present, such as today’s headlines. My team is also working on such an information flow App. The App Feed stream is implemented by the client Native. When the user clicks on an article in the Feed stream, it goes to the bottom page of the article. Most of the underlying pages of the article are implemented by Native, but the data of some articles are unstructured and Native cannot handle them well, so H5 pages are used to carry on these articles. The entire business scenario is simple, as shown in the following diagram:

There is no doubt that the H5 page will greatly affect the user experience of the App. Therefore, the performance of the first screen of H5 page is very important, and we should strive to be able to open in seconds.

Before optimization

Before optimization, the loading process of H5 bottom page is as follows:

The loading process shown above is a very common page loading process. There are at least four HTTP requests in this process. Each time HTTP slows down page rendering time. If it is a separate H5 page, there is no problem, but the page is in the client, is to strive to do second open.

Optimization scheme investigation

ssr

Server rendering. Server-side rendering is to complete the data request and page structure generation on the server side. When users visit the page URL, the interface spit out complete HTML with data content, and the speed of the first screen will be naturally improved. But there are a few problems:

1. The current unstructured article data is a large STRING of HTML, and servers are not very good at handling large strings of HTML.

2. Even if SSR is implemented, there will always be an Http request when the user accesses the H5 underlying page link, and the first screen speed will still be affected by network environment and other factors.

The offline package

A complete offline package solution is to package and upload H5 pages and related resources according to the service module configuration. Then the client predownloads, decompresses, and checks the offline package at a specific time, and then uses the local files in the offline package at a specific time. Offline packages are a good solution, but there is one problem with offline packages: they are too heavy.

Lightweight solution

Solution overview

After weighing various factors, we adopted the following solution:

  1. The front-end produces two HTML template files, one for the previous logic and one for the pre-loaded logic, when the development goes live and packaged. Preloaded HTML has been written as a string to the background configuration service. Upload the js and CSS files to the CDN, and upload the CDN address to the background for saving.
  2. When users access the client, the background delivers preloaded data through the preloading interface. The client saves the HTML template string with data locally and downloads a static file for saving.
  3. When the user accesses the H5 underlying page, the client directly loads the local HTML template string, intercepts the static resource request of the WebView, and directly uses the JS and CSS files downloaded in advance.

To sum up, the background provides a preloading interface to prepare Html, article data, JS, CSS and so on required by the H5 underlying page. When the user clicks into the underlying page, the client directly uses local resources to render the page.

Solution added

  • HTML preloaded template related

    IOS and Android have different ways of intercepting static resource requests from webViews, so you need to perform separate logic for iOS and Android in preloading HTML templates. I did this with the help of the WebPack Plugin and the Golang template engine in the background. The general code is as follows:

    
        
<html>
<head>.<script>
        var __articleContent__ = JSON.stringify({{.articleContent}});
    </script>
    {{if eq .ostype "ios"}}
        <link rel="stylesheet" type="text/css" href="./**CSSURL**/"/>
    {{else}}
        <link rel="stylesheet" type="text/css" href="/**CSSURL**/"/>
    {{end}}
</head>
<body>.<main></main>
    {{if eq .ostype "ios"}}
        <script src="./**JSURL**/"></script>
    {{else}}
        <script src="/**JSURL**/"></script>
    {{end}}
    ...
</body>
</html>
Copy the code

  • Checksum and fault tolerance

    After obtaining static resources from the preloading interface, the client performs version verification and resource integrity verification to determine whether to use the preloaded resources. If the resource requested by HTML does not match the preloaded resource, it will go to the network to obtain the resource. When preloading goes wrong, the client will follow the same old logic: the link to the underlying page of the H5 article.

Project summary
  • Data is directly written to HTML, eliminating the overhead of H5 page request interface pulling data.
  • Static resources such as JS and CSS can be preloaded directly from the local PC when needed, saving the cost of obtaining static resources from the network on H5 pages.
  • Lightweight solution, the whole process is controllable, H5 page on-line and update process is simple.

Write in the back

This paper summarizes the performance optimization scheme of H5 page first screen in App in specific scenarios. The final line after the detailed data is no longer given, can only say: the naked eye visible fast. The whole program was initiated by the front end. During the implementation of the program, I also learned a lot, not only in technology. As expected.