Source: Chaos Fuwang
http://www.alloyteam.com/2019/10/h5-performance-optimize/
The boss said that the page opening speed is too slow? The page loading performance is not up to the standard? Let's take a look at the classic solutions of every major factory and team. Is there one suitable for you to explore?
This page will list and summarize the hybrid second opening solutions that are biased to be combined with the client, and the pure front-end solutions will also be partly mentioned.
Commonly used acceleration methods
Speaking of the H5 performance optimization program, it is a common topic. The usual web optimization methods basically revolve around two aspects of resource loading and html rendering. The former is for the first screen, and the latter is for interactive. In terms of resource optimization, our general direction is to focus on smaller resource packages, such as common ones: compression, package reduction, unpacking, dynamic loading of packages and image optimization. The general direction of html rendering is to display content faster, such as distribution through CDN, DNS resolution, http caching, data pre-request, data caching and first-screen optimization killer-straight out, etc.
These programs are required for various front-end interviews, as well as a front-end development, the most important and basic idea when you encounter performance problems and need to solve performance problems. The specific solution that should be used depends on the actual development needs, priority, overall cost, and input-output ratio.
While client technologies such as react-native, weex, and flutter continue to impact traditional hybrids, hybrids are also evolving and accelerating along the way, and are developing in a direction that makes them comparable to native ones. The following is a summary of some of the programs in hybrid development, in no particular order.
Straight out + offline package cache
In order to optimize the first screen, most mainstream pages will be rendered through the server, and html files will be spit out to the front end to solve the problem of long-running chrysanthemums. Different types of mainstream frameworks will have a set of background rendering solutions, such as vue-server-renderer, react-dom/server etc. Straight-out saves the time for front-end rendering and ajax request. Although straight-out can be optimized through various caching strategies, it takes time to load html.
The offline package technology can solve the problem of time required to load the html file itself. The basic idea of offline packages is to intercept URLs uniformly through webview, map resources to local offline packages, check version resources when updating, download and maintain resources in the local cache directory. Such as Tencent's webso and Alloykit's offline package solutions.
The offline package strategy is relatively mature in many large factories. It is relatively transparent to the web and is very intrusive.
VasSonic Client Agent
In hybrid h5, between the time the user clicks to see the page, there is still the time for webview to initialize and request resources, and the process here is serial. For the pursuit of a more extreme experience, there is room for optimization and may. VasSonic is a lightweight hybrid framework developed by Tencent's value-added membership team. It supports the offline package strategy mentioned above. Furthermore, it has made the following optimizations:
Webview initialization and resource request through client proxy in parallel
Streaming interception of requests, rendering while loading
Realize dynamic caching and incremental update.
Simply talk about how it is done. There is nothing to say about the parallel client proxy resource request, that is, before the webview is created, the network connection is established through the client proxy, html is requested, and then cached, waiting for the webview thread to initiate the html resource request. , The client intercepts and returns the cached html to the webview.
How to do dynamic caching and incremental update?
VasSonic divides the content of html into html template and dynamic data. How to distinguish between these two types? It defines a set of html annotation markup rules to divide which is dynamic data and which is template data through tags. Then the http header was expanded and a set of conventions for requesting the backend was customized. When webview initiates an http request, it will carry the id of the page content. After the background processing is judged, the client will be told whether the partial data needs to be updated. If so, the cached html template and the new data will be spliced into new html, and the data will be calculated. In the difference part, call back to the page through js to refresh the layout.
[Picture source network]
The overall idea and effect of VasSonic's solution is very good, especially for most web scenes, usually our templates are rarely changed, most of which are data partial changes, which can achieve a second-time effect through partial refresh. For the first load, concurrent requests and webview creation have brought good performance improvements, and can seamlessly support offline package strategies.
However, VasSonic defines a set of special annotation marks and expands the header. The front and back ends, including the backend, need to be modified, which is very intrusive to the web, and the workload and maintenance cost of access will be very large.
PWA + straight out + preload
Whether it is offline package technology or webview proxy request, it is very intrusive to the front end. As a web standard, PWA can accelerate and optimize loading performance through a pure web solution.
First of all, PWA can cache common pictures, JS, CSS resources through cacheStorage. On the other hand, in the traditional http cache, we generally do not cache HTML. This is because once the page is set to a too long max-age, the user will always see the old one within the browser cache expiration time.
If the HTML page of PWA is used, can it be cached directly? Since PWA can finely control the cache, the answer is yes.
For straight-out HTML, we can cooperate with PWA to cache the files directly out of the background to cacheStorage, and obtain them from the local cache first when the next request is made, and initiate a network request to update the local html file.
However, in hybrid h5 applications, loading resources for the first start is still time-consuming. We can preload a javascript script through the app side to support pre-loading of pages that need PWA cache, and the cache can be completed in advance.
For non-straight-out pages, we still cannot avoid the problem of the browser rendering html time. How should we kill the time here?
Here are two points. The first time you can only rely on pre-loading, so the above-mentioned preloading script on the end is still effective; the second point is not straight out of the page, each page needs to have a unique mark, such as hash. The browser obtains the data and renders the html. The html page can be cached in the cacheStorage through the outerHTML method. The second access is still preferentially obtained locally, and the html request is initiated at the same time. By comparing the difference of the unique identifier, decide whether need to be updated.
A series of PWA solutions replace the offline package strategy. The benefit is that it belongs to the web standard and is suitable for ordinary H5 pages that can support service-worker. In the case of allowing compatibility issues, it is recommended to add.
NSR rendering
GMTC2019 global front-end technology UC team mentioned the 0.3-second "flight" solution. NSR is the front-end version of SSR, which is very enlightening.
The core idea is to enable a JS-Runtime with the help of a browser, render the downloaded html template and prefetched feed stream data in advance, and then set the HTML to the memory-level MemoryCache, so as to achieve the effect of clicking and viewing. .
NSR distributes the SSR rendering process to the end of each user. While reducing the pressure of the background request, it also speeds up the page opening speed, which is the ultimate.
The problem is that data prefetching and pre-rendering bring additional traffic and performance overhead, especially traffic. How to predict user behavior more accurately and increase the hit rate is very important. We are gradually exploring solutions similar to NSR.
Client PWA
In the actual test, and the understanding and communication with the classmates of the browser team, the performance of service-worker in webview was not as good as expected. After a project dropped sw, the overall access speed of the market increased by about 300ms. For hybrid applications, this presents a new idea and challenge. Can a set of basic service-worker api be implemented on customers? So as to achieve compatibility with web standards. This is just a kind of thought and idea, there are a lot of problems to be explored, such as the specific performance status of webview sw, the future support situation, the cost of self-realization, and the final effect and value.
Mini Program
The mini program ecosystem is very mature. Major manufacturers have also launched their own platform mini programs, and domestic manufacturers are also constantly trying to promote the MiniApp w3c standard. No matter from the loading speed or the page fluency, the mini program is higher than the H5 page. The reason is that by standardizing and constraining the development of the architecture, the mini program separates the webview rendering and js execution, and then through the offline package, A series of optimization methods such as page splitting and pre-loading pages give the applet a lot of H5 optimized effects, at the expense of web flexibility. But for hybrid development, it is a very good direction to support this kind of small program environment through the bottom layer of the native client, and then develop a large number of business logic using small program solutions to achieve the effect of iterative speed and performance.
Knot
This article mainly summarizes a large number of reading and combing more than a dozen articles on Miaokai and some recent thoughts and practices in the past few days, and extracts some representative solutions. Regardless of the type of program, the general idea and direction are found to be:
Reduce intermediate links in the entire link. For example, changing serial to parallel, including the internal execution mechanism of small programs.
Preload and execute as much as possible. For example, from data prefetching to page prefetching rendering.
Any conversion has a price. Acceleration is essentially trading more network, memory, and CPU for speed, and space for time.
study Exchange
Follow the public account [Frontend Universe], get good article recommendations every day
Add WeChat, join the group to communicate
"Watching and forwarding" is the greatest support