Discussion on optimization scheme for opening the first screen of mobile H5 within seconds

As the performance of mobile devices continues to improve, the performance experience of web pages has gradually become acceptable. Due to the many advantages of the web development model (cross-platform, dynamic update, reduced size, and instant expansion), more and more embedded web pages appear in APP clients (in order to match the current popular saying, all web pages are referred to as H5 pages below, although they may have nothing to do with H5). Many APPs have changed some functional modules to use H5.

Although the performance of H5 pages has improved, the experience is still very bad if no targeted optimization is done. There are mainly two parts of the experience:

• White screen time when page starts: Opening an H5 page requires a series of processing, and there will be a white screen time, which is a bad experience.
• Responsiveness: Due to the rendering mechanism of WebKit, single thread, historical baggage and other reasons, the performance experience of page refresh/interaction is not as good as native.

This article will not discuss the second point, but only the first point, how to reduce the white screen time. For some functional modules in the APP that use H5, how to speed up their startup speed and make their startup experience close to the native one.

[[200142]]

process

Why does a long white screen appear when you open an H5 page? Because it does a lot of things, probably:

• Initialize webview -> request page -> download data -> parse HTML -> request js/css resources -> dom rendering -> parse JS execution -> JS request data -> parse rendering -> download rendered images
• Some simple pages may not have the step of JS requesting data, but most functional modules should have it. According to the current user information, JS requests relevant data from the background and then renders it, which is a conventional development method.
• Generally, the page can be displayed in its prototype after DOM rendering. Before that, the user sees a white screen. The entire page will not be fully displayed until the rendered image is downloaded. The optimization of the first screen opening in seconds is to reduce the time consumption of this process.

Front-end optimization

There are many optimization points in the process of opening a page, including the front-end and the client. Conventional front-end and back-end performance optimization has been widely practiced in the desktop era. The main ones are:

• Reduce the number of requests: merge resources, reduce the number of HTTP requests, minify/gzip compression, webP, lazyLoad.
• Speed ​​up requests: pre-resolve DNS, reduce the number of domain names, parallel loading, and CDN distribution.
• Cache: HTTP protocol cache request, offline cache manifest, offline data cache localStorage.
• Rendering: JS/CSS optimization, loading order, server-side rendering, pipeline.

The biggest factor affecting the first screen startup speed is the network request, so the focus of optimization is cache. Here we will focus on the front-end cache strategy for requests. Let's break it down into HTML cache, JS/CSS/image resource cache, and json data cache.

HTML and JS/CSS/image resources are all static files. HTTP itself provides caching protocols. Browsers implement these protocols and can cache static files. For details, please refer to here. In general, there are two types of cache:

• Ask if there is an update: According to the If-Modified-Since / ETag and other protocols, the backend is asked whether there is an update. If there is no update, 304 is returned and the browser uses the local cache.
• Use local cache directly: Use the Cache-Control / Expires field in the protocol to determine how long you can use the local cache directly without sending a request for updates.

The most extreme cache strategy that the front-end can do is: HTML files ask the server every time if there is an update, and JS/CSS/Image resource files do not request updates, and directly use local cache. How to update JS/CSS resource files? The common practice is to give each resource file a version number or hash value during the build process. If the resource file is updated, the version number and hash value change, the URL of the resource request will change, and the corresponding HTML page will be updated to request a new resource URL, and the resource will be updated.

The cache of json data can use localStorage to cache the requested data. When displaying ***, you can use local data first and then request an update. This is all controlled by the front-end JS.

These cache strategies can achieve full caching of resource files such as JS/CSS and user data, and can use local cache data directly every time without waiting for network requests. However, this cannot be done for HTML file caching. For HTML files, if the Expires/max-age time is set too long, only the local cache is used for a long time, and the update is not timely. If it is set too short, each time the page is opened, a network request must be sent to ask if there is an update, and then determine whether to use local resources. Generally, the front-end strategy here is to request every time, which will still cause the user to feel a long white screen time in a weak network. Therefore, there is a contradiction between "caching" and "updating" of HTML files.

Client optimization

Then it is the client's turn. In the desktop era, H5 pages could not be optimized more due to the limitations of browsers. Now H5 pages are embedded in client apps, and clients have more permissions, so clients can go beyond the scope of browsers and do more optimization.

HTML Cache

Let's talk about cache first. The client has a more flexible cache strategy. The client can intercept all requests for H5 pages and manage the cache by itself. For the contradiction between "caching" and "updating" of the above HTML files, we can use the following strategy to solve it:

1. Intercept the request on the client side, cache the data after first requesting the HTML file, do not send the request the second time, and use the cached data directly.
2. When to request an update? The client can freely control the strategy of this update request. After using the local cache to open the local page, you can initiate a request to update the cache in the background, which will take effect the next time it is opened; you can also initiate a pre-update request in the background when the APP is started or at a certain time to increase the chance of users accessing the *** code.

This seems to be more advanced. The HTML file is cached using the client's strategy, and the rest of the resources and data follow the front-end caching method mentioned above. In this way, when an H5 page is accessed for the second time, everything from HTML to JS/CSS/Image resources and then to data can be read directly from the local computer without waiting for network requests. At the same time, it can be updated as quickly as possible, solving the caching problem and greatly improving the startup speed of the first screen of the H5 page.

question

The above solution seems to have completely solved the cache problem, but there are still many problems:

• No preloading: The first opening experience is very poor, and all data must be requested from the network.
• Cache is uncontrollable: The access to the cache is controlled by the system webview, and its cache logic cannot be controlled. The problems caused include: i. The cleanup logic is uncontrollable, and the cache space is limited. After caching a few large images, the important HTML/JS/CSS cache may be cleared. ii. Disk IO cannot be controlled, and data cannot be preloaded from the disk to the memory.
• Poor update experience: When background HTML/JS/CSS is updated, it is fully downloaded, the data volume is large, and the download takes a long time in weak network.
• Unable to prevent hijacking: If an HTML page is hijacked by an operator or other third party, the hijacked page will be cached for a long time.

These problems can be solved on the client side, but it is a bit troublesome. Here is a brief description:

1. You can configure a preload list and request it in advance when the app starts or at certain times. This preload list needs to include the pages and resources of the required H5 module. You also need to consider the situation where an H5 module has multiple pages. This list may be very large, and tools are also needed to generate and manage this preload list.
2. The client can take over the cache of all requests, not follow the default cache logic of webview, and implement the cache mechanism by itself, which can be divided into cache priority and cache preloading.
3. Incremental updates can be made for each HTML and resource file, but they are more difficult to implement and manage.
4. Use httpdns + https on the client to prevent hijacking.

The above solution is very cumbersome to implement because there are many HTML and resource files and they are scattered and difficult to manage. There is a better solution to these problems, which is the offline package.

Offline package

Since many problems are caused by the difficulty of decentralized file management, and our usage scenario here is to use H5 to develop functional modules, it is easy to think of packaging and distributing all the relevant pages and resources of each functional module. This compressed package can be called the offline package of the functional module. Using the offline package solution can solve the above problems relatively easily:

1. The entire offline package can be downloaded in advance. It only needs to be configured by business module, not by file. The offline package contains all pages related to the business module and can be preloaded at one time.
2. The offline package core files and page dynamic image resource files are cached separately, which makes it easier to manage the cache. The offline package can also be loaded into the memory as a whole in advance to reduce disk IO time.
3. Offline packages can be easily updated incrementally according to the version.
4. The offline package is sent in the form of a compressed package, and is encrypted and verified, so operators and third parties cannot hijack or tamper with it.

At this point, offline packages are a good solution for developing functional modules using H5. Let me briefly repeat the offline package solution:

1. The backend uses a build tool to package pages and resources related to the same business module into one file, and encrypt/sign the file.
2. According to the configuration table, the client pulls down the offline package at a customized time and performs decompression/decryption/verification and other tasks.
3. According to the configuration table, when a certain service is opened, it is transferred to the entry page for opening the offline package.
4. Intercept network requests. For files that are already in the offline package, directly read the offline package data and return it. Otherwise, follow the HTTP protocol cache logic.
5. When the offline package is updated, the background sends the diff data between the two versions according to the version number, and the client merges and updates incrementally.

More optimizations

The offline package solution has done a good job in caching, and some details can be optimized:

Public resource package

Each package will use the same JS framework and CSS global style. It is too wasteful to duplicate these resources in each offline package. You can create a public resource package to provide these global files.

Preload webview

Whether it is iOS or Android, it takes a lot of time to initialize the local webview. You can initialize the webview in advance. There are two types of preloading:

1. ***Preloading: The first initialization of webview in a process is different from the second initialization. The first initialization will be much slower than the second one. The reason is expected to be that after the webview is first initialized, even if the webview has been released, some global services or resource objects shared by multiple webviews have not been released. These objects do not need to be generated again during the second initialization, making it faster. We can pre-initialize a webview when the APP starts and then release it, so that when the user actually goes to the H5 module to load the webview, it will be faster.
2. Webview pool: You can reuse two or more webviews instead of creating a new webview every time you open H5. However, this method needs to solve the problem of clearing the previous page when the page jumps. In addition, if there is a memory leak in JS on an H5 page, it will affect other pages and cannot be released during the APP operation.

Preloading Data

Ideally, when the offline package is opened for the first time, all HTML/JS/CSS are cached locally without waiting for network requests. However, user data on the page still needs to be pulled in real time. An optimization can be made here to request data in parallel while the webview is initialized. It takes some time for the webview to be initialized, and there are no network requests during this period. Parallel requests at this time can save a lot of time.

In terms of specific implementation, you can first indicate in the configuration table the URL that needs to be preloaded for a certain offline package. The client initiates a request while the webview is initialized. The request is managed by a manager. When the request is completed, the result is cached. Then, after the webview is initialized, it starts to request the URL that has just been preloaded. The client intercepts the request and transfers it to the request manager mentioned above. If the preloading is completed, the content is returned directly. If not, it waits.

Fallback

What should be done if a user accesses an offline package module but the offline package has not been downloaded, or the configuration table detects that a new version is available but the local version is an old version? Several solutions:

• The simple solution is that if the local offline package does not exist or is not the latest one, it will be blocked synchronously and wait for the latest offline package to be downloaded. This will give users a worse experience when opening the package because the offline package is relatively large.
• Alternatively, if there is an old package locally, the user will directly use the old package this time. If there is no synchronization blocking and waiting, this will lead to untimely updates and failure to ensure that users use the latest version.
• You can also make an online version of the offline package. The files in the offline package have a corresponding access address on the server. When there is no offline package locally, you can directly access the corresponding online address, just like opening an online page traditionally. This experience is better than waiting for the entire offline package to be downloaded, and it can also ensure that users can access the latest version.
• The third Fallback method also brings the benefit of a backup plan. When the offline package fails in some unexpected situations, the online version can be accessed directly without affecting the functionality. In addition, when the public resource package is not updated in time and the version does not correspond, the online version can also be accessed directly. This is a good backup plan.

The above solutions and strategies can also be used together, depending on business needs.

Using the Client Interface

If the network and storage interfaces use webkit's ajax and localStorage, there will be many limitations and it will be difficult to optimize. These interfaces can be provided to JS on the client side. The client can make more detailed optimizations on network requests, such as DNS pre-resolution/IP direct connection/long connection/parallel request, etc. Storage can also use client interfaces to perform targeted optimizations such as read-write concurrency/user isolation, etc.

Server-side rendering

In early web pages, JS was only responsible for interaction, and all content was directly in HTML. In modern H5 pages, many contents have relied on JS logic to decide what to render. For example, waiting for JS to request JSON data, then splicing it into HTML to generate DOM and rendering it on the page, so the rendering and display of the page has to wait for this entire process, which is time-consuming. Reducing this time consumption is also within the scope of white screen optimization.

The optimization method can be to reduce the JS rendering logic artificially, or it can be more thorough, returning to the original state, where all content is determined by the HTML returned by the server, without waiting for the JS logic, which is called server-side rendering. Whether to do this optimization depends on the business situation. After all, this will bring negative effects such as changes in development mode/increased traffic/increased server-side overhead. Some pages of mobile QQ use server-side rendering, which is called dynamic direct output, see the article.

***

From front-end optimization, to client caching, to offline packages, to more detailed optimizations, by achieving the above points, the H5 page startup experience can be almost comparable to the native experience.

In summary, the general optimization ideas are: cache/preload/parallel, cache all network requests, try to load all content before the user opens it, and do things in parallel instead of serially. Some of the optimization methods here require a complete set of tools and process support, which needs to be weighed against development efficiency and optimized according to actual needs.

In addition, the above discussion is about the optimization solution for opening H5 pages in seconds for functional modules. In addition to functional modules on client APP, some other H5 pages such as marketing activities/external access may not be applicable to some optimization points. It depends on the actual situation and needs. In addition, WeChat applet belongs to the category of functional modules, which is almost the same routine.

Here we discuss the optimization of the H5 page first screen startup time. After the above optimization, basically the only time-consuming issue is the startup/rendering mechanism of the webview itself. This issue, together with the subsequent response smoothness issue, belongs to another optimization scope, which is a solution like RN/Weex. We will discuss it again when there is a chance.