Author: Idle fish technology – Song Chen
background
Idle fish the performance of the front page is often people chanting, * * * * all jump, will jump fish impression, partial page jump even need to open four or five, we recently done on the front page of idle fish systematic optimization, due to the diverse idle fish front-end technology stack, different stack technology principle of each are not identical, optimization is also different, This paper mainly introduces the optimization process of Weex page which is heavy with idle fish.
Weex page more than the previous rendering, the opening process and the Web page slightly similar, roughly divided into the following stages:
We call the time “between the start of loading (navigationStart) and the first time the screen paints the pixel content”White screen time (FP)NavigationStart (navigationStart) and the first screen is completely renderedFirst Screen Time (FSP)Due to the statistical coverage, the first screen time of Weex does not include the image download and subsequent process.
Before and after optimization
We take xianyu’s live channel page and player channel page as a reference to see the comparison before and after optimization through screen recording:
By recording screen and dividing frames, we have counted the first screen duration of these two channel pages in different systems and models:
It can be seen that before optimization, the first screen time on mainstream iOS and Android models is more than 2s, and even 3-5s on low-end phones. After optimization, the first screen time of all models is significantly reduced, the first screen time of low-end phones is controlled within 2s, and the first screen time of middle and high-end phones is almost straight open.
Disassembly analysis
Before determining the optimization scheme, we disassembled and analyzed the existing Weex pages. According to the results, the following factors have a great impact on the first screen time:
- Bundle volume: not only affects the loading time of the Bundle, but also affects the parsing time of the Bundle (especially on low-end devices).
- First screen data request: The page must be rendered after the first screen data request is returned. The interface time directly affects the first screen time
- First screen rendering range: The amount of first screen rendering directly affects the rendering time (especially for low-end phones)
Optimization scheme
Based on the above analysis and investigation, we initially set the optimization plan as four layers:
According to the expected optimization effect, the Weex page opening process is as follows:
Reflected in the above four-layer structure, mainly includes the following optimization points:
Bundle offline
六四运动
The Weex Bundle is offline to the client based on the resource package unit and the URL prefix index. The previous update policies are as followsInstall after access and start installationThe corresponding update timing is as follows:
The mechanism on the container floor have a unified plan, but the package has been shooting is not high (25% 55%), lead to the result, after analysis found that the default update policy (access after installation) associated with page return rate is strong, the front end of the page are mostly idle fish guide channel page, return rate is not high, natural so package corresponding to the shooting is not high.
This optimization mainly extends the update strategy by adding”When installing“Update policy: will be installed during the periodic update period, if not used after installation, will be eliminated one week later; If used within a week, it will enter the regular update elimination mechanism (not used for a month elimination).
After the update strategy of “install at leisure” went online, the packet hit ratio was greatly improved (about 90% after stabilization), and the page performance was also significantly improved:
Pages that don’t rely on the first screen interface can even be “straight” :
Data prefetching
Traditionally, the first screen data request is initiated after the Bundle is resolved, and the page is rendered after the first screen data is returned, which is a typical serial process. In this optimization, we parallelize the serial process:
- Serialized the configuration of the first screen request as a parameter configuration to the URL, while supporting some dynamic replacement parameters (such as latitude and longitude, city and other parameters);
- In navigationStart, the client extracts the first screen request configuration, then initiates the request, and stores the result locally with a specific Hash Key (generated by the first screen configuration) as an index.
- When the service layer initiates the first screen request, it compares the data with the Hash Key. After the match, the data is extracted and returned to the service layer.
The sequence diagram is as follows:
Sequence diagram in special case:
The specific technical details will not be repeated in this paper. After the data prefetch optimization strategy is launched, the first screen time is also improved to a certain extent, as follows (on iOS, performance data collection of a single variable cannot be achieved due to the concurrent launch of all optimization strategies, so Android is used for reference temporarily) :
After the optimization strategy of **Bundle offline and data prefetch is launched, some pages are close to “straight open” on mid – and high-end models:
Progressive front screen
Progressive first screen is to solve the “last mile” problem, because in the “offline” and “data prefetch”, we found: page first screen time to a certain extent, or restricted to the first screen interface request time consuming, the scheme is to reduce the user side white during the waiting time, the concrete from the following three aspects:
- The interface data is cached with indexes generated by the interface request configuration
- When the user enters for the first time, the skeleton screen occupies the space to wait for service data loading.
- When the user does not enter for the first time, it will search the cache data in the local cache according to the index generated by interface request configuration, and complete the first screen rendering. Meanwhile, it will send interface request in parallel. After the new data is returned, page update will be triggered to complete the final rendering.
-
Low-end machine downgrade scheme
In order to better user experience, we have tried the low-end machine downgrade optimization scheme. Take live channels for example:
- Cache data placeholder optimization for first screen Tab only
- Reduce the first screen rendering display data amount on low-end machines
-
Image rendering effect optimization
One of the problems with the progressive first screen is the flash of the interface update (especially when images take up a lot of space). In order to optimize this problem, we changed the image from loading to appearing process to fading transition, to eliminate the stiffness of image flash to some extent.
On-demand rendering
As a link in the first screen link, the rendering page will have different proportions in the first screen time under different technology stacks and different device environments. Weex and RN can map the technical scheme of Native components through front-end scripts. The rendering path can be summarized as follows: Virtual DOM of the front-end rendering -> mapping to Native instructions -> transferring instructions to Native side -> Native execution instructions to complete rendering. In the first three steps, heavy business logic or unreasonable code usually leads to long computation and communication time, especially on low-end machines. This problem can be effectively solved by rendering on demand. The main idea of rendering on demand is to minimize the first screen rendering time by rendering only the first screen visible view. In this optimization, on-demand rendering is mainly done for the following scenes:
- In the case of multiple tabs, data preloading and page lazy rendering are performed for non-first screen Tab pages that have performance requirements
- Render only visible items on the first screen of a long list with/without recycling mechanism, and the rest of the rendering process is lazy. This reduces the script calculation and communication time with the recycle mechanism list, and reduces the full-link rendering time without the recycle mechanism list.
- Build or replace non-essential heavyweight components with lightweight components, such as xSlider.
After the optimization went online, the first screen performance of low-end models of Fishpond Plaza page has been improved in some data:
Comparison of optimized front-end rendering stages on low-end machines:
Bundle thin body
** The Bundle volume directly affects the Bundle download time on the one hand, and also affects the rendering performance on Android (the elapsed time increases with the Bundle volume by 1-2ms/KB). Our optimization plan for the Bundle volume is relatively conventional, including:
- Use Webpack Bundle Analyzer to analyze dependencies and reduce dependencies of different versions of NPM packages
- Abstract common modules to improve code reuse
- Refactoring the base tool class library to support loading and packaging on demand
conclusion
The performance optimization of the idle fish front end has come to an end for the time being. In the process of optimization, many general capabilities have been accumulated, such as Bundle offline, data prefetch, progressive first screen, etc. These capabilities will have more room to play in the future, and some capabilities will also become more intelligent. In navigationStart, you can set a TaskSchedule that handles the prefetch Task. At the same time, intelligent data prefetch can be performed based on users’ access habits. Under the background of increasingly high front-end performance requirements, the traditional Web loading process can no longer meet the needs of performance optimization, so a variety of new containers + supporting capabilities appear, so what should the standard form of the next generation of containers be?