Introduction: Let me cross my waist for a while~
Author: Busy fish technology - Chung Chen
background
The performance of the front page of the busy fish often been talking about, every jump, jumping fish will be impressed deeply rooted part of the page jump even need to open four or five, we recently made some systematic optimization of idle fish front page, because the Xianyu's front-end technology stack is relatively diversified, and different stack technology principles are different, and optimization schemes are also different. This article mainly introduces the optimization process of the current Weex page, which Xianyu accounts for relatively heavily.
Xianyu Weex pages are mostly based on front-end rendering, and the opening process is slightly similar to that of web pages, roughly divided into the following stages: 
We will start from loading (navigationStart) to the first painting (drawing) of the pixel content on the screen. time called white screen time (FP) , the "from start to load (navigationStart) to fold content all the rendering is complete," this time is called the first screen time (FSP) , is limited to statistical standards, currently first in the Weex The screen time does not include the picture download and subsequent process.
Before and after optimization
We take Xianyu’s live channel page and player channel page as a reference, and look at the comparison before and after optimization 
through screen recording : through the screen recording and framing method, we have counted the two channel pages under different systems and different models. First screen time: It 
can be seen that the first screen time on mainstream iOS and Android models will exceed 2s before optimization, and it will even take 3-5s for low-end devices. After optimization, the first screen time of each model is significantly reduced. The first screen time of the terminal is controlled within 2s, and the mid-to-high-end terminal is almost open.
Dismantling analysis
Before determining the optimization plan, we disassembled and analyzed the existing Weex page. From the results, the following factors have a greater impact on the first screen time:
- Bundle size: not only affects the bundle loading time, but also affects the time it takes to parse and execute the bundle (especially on low-end machines)
- First screen data request: Page rendering must be returned after the first screen data request is returned, the interface time consumption directly affects the first screen time
- First screen rendering range: the amount of first screen rendering directly affects the rendering time (especially on low-end machines)
Optimization
Based on the above analysis and investigation, we initially set the optimization plan as four layers:
According to the expected optimization effect, the opening process of the Weex page is like this: 
Reflected in the above four-layer structure, it mainly includes the following optimization points:
Bundle offline
Specific implementation is the Weex Bundle resource pack as a unit, the URL prefix for the index by a certain off-line updating policy to the local client, before updating the main strategy after visiting the installation, start the installation ** two types, corresponding to the timing of the update As follows: 
This mechanism has a unified solution support at the container layer, but the package hit rate has not been high (25%-55%), resulting in unsatisfactory final results. After analysis, it is found that the default update strategy (installation after visit) and page return rate Strongly related, Xianyu’s front-end pages are mostly channel shopping guide pages, and the return visit rate is naturally not high, so the package hit rate is correspondingly not high.
This optimization is mainly to expand the update strategy, adding the update strategy of " install at rest ": it will be actively installed during the regular update period. If it is not used after installation, it will be eliminated after a week; if used within a week, Then it enters the regular update and elimination mechanism (elimination is not used for one month).
After the update strategy of "install in idle" was launched, the package hit rate increased significantly (about 90% after stabilization), and the page performance was also significantly improved: 
pages that do not rely on first-screen interface rendering can even reach "straight open":
Data prefetching
The traditional first-screen data request is initiated after the bundle is parsed, and the page is rendered after the first-screen data is returned, which is a typical serial process.
In this optimization, we parallelized this serial process:
- After serializing the configuration of the first screen request, it is configured as a parameter to the URL, and at the same time supports some dynamically replaced parameters (such as latitude and longitude, city, etc.)
- At navigationStart, the client extracts the first screen request configuration, then initiates the request, and stores the result locally with a specific Hash Key (generated through the first screen configuration) as an index;
- When the business layer actually initiates the first screen request, the Hash Key is used for comparison, and the data is retrieved after the hit and returned to the business layer;
The sequence diagram is as follows:
Timing diagram under special circumstances: the 
specific technical details will not be repeated in this article. After the optimization strategy of data prefetching is launched, the first screen time has also been improved to a certain extent, as follows (on the iOS side, due to the parallel implementation of optimization strategies, it was not possible to do a single variable to collect performance data, temporarily to Android side as a reference): 
Bundle offline data prefetching after optimization strategy on the line, part of the page on the approximation of high-end models "straight on":
Progressive first screen
The progressive first screen solves the "last mile" problem, because after applying the "offline package" and "data prefetching" solutions, we found that the first screen time of the page is still limited to a certain extent by the first screen interface The request is time-consuming . The solution is to reduce the waiting time of the white screen on the user side, specifically from the following three aspects:
-
Cache interface data with the index generated by the interface request configuration
- When the user enters for the first time, take the skeleton screen to wait for the business data to load;
- When the user enters for the first time, it will look up the cached data in the local cache according to the index generated by the interface request configuration and complete the first screen rendering. At the same time, the interface request will be sent in parallel. After the new data is returned, the page update will be triggered to complete the final rendering;
-
Low-end machine downgrade scheme
In order to have a better user experience, here we tried a low-end machine downgrade optimization solution. Take the live channel as an example:
- Only optimize the cache data for the first screen Tab
- Reduced the amount of first-screen rendering display data on low-end machines
-
Picture rendering effect optimization
渐进式首屏带来的一个问题是界面更新时的闪动（特别是图片占大篇幅的时候），为了优化此问题，我们将图片从加载到出现的过程改为了渐显过渡，一定程度上消除了图片闪动的生硬感。
Render on demand
The rendered page is a link in the first screen link, and under different technology stacks and different device environments, there will be different proportions of the page first screen time. Class Weex and RN map native components through front-end scripts. The rendering path can be summarized as follows: Render front-end Virtual DOM -> Map to Native instructions -> Transmit instructions to Native side -> Native execute instructions to complete rendering. In the first three steps, heavier business logic or unreasonable code usually leads to longer calculation and communication time, especially on low-end machines. This problem can be effectively solved by rendering on demand.
The main idea of on-demand rendering is to minimize the time-consuming first screen rendering by rendering only the visible view of the first screen. In this optimization, on-demand rendering is mainly performed for the following scenarios:
- In the case of multiple tabs, for non-first screen tab pages with performance requirements, do data preloading and page lazy rendering processing
- For the long list with/without recycling mechanism, only the visible items are rendered on the first screen, and the rest is lazy rendering. It can reduce the time consumption of script calculation and communication with the recovery mechanism list, and reduce the time consumption of full link rendering without the recovery mechanism list.
- Build your own or use lightweight components to replace non-essential heavyweight components, such as xSlider.
After the optimization went live, the first screen performance of the low-end models on the Yutang Plaza page has been improved in some data: the 
comparison of the front-end rendering stage optimization on the low-end machines:
Bundle slimming
**
Bundle size directly affects the Bundle download time on the one hand, and on the other hand, it also affects the rendering performance of the Android side (the time consuming increases by 1-2ms/KB with the volume of the Bundle). Our optimization scheme on the Bundle volume is more conventional, including:
- Analyze dependencies through Webpack Bundle Analyzer to reduce dependencies on different versions of the same npm package
- Abstract common modules to improve code reuse rate
- Refactor the basic tool library to support loading and packaging on demand
to sum up
The performance optimization of Xianyu's front-end has come to an end temporarily. During the optimization process, more general-purpose capabilities have been deposited, such as Bundle offline, data prefetching, progressive first screen, etc. These capabilities will have more room for use in the future, some capabilities It will also become more intelligent. For example, the current data prefetching is initiated at navigationStart. This timing is much earlier than the timing of the traditional page loading, but it can be even more advanced, for example, in the Xianyu client There is a resident TaskSchedule, which is specially used to process data prefetching tasks, and at the same time, it can do intelligent data prefetching according to the user's access habits.
In the context of higher and higher front-end performance requirements, the traditional Web loading process can no longer meet the needs of performance optimization, so various emerging containers + supporting capabilities have emerged. So what should the standard form of the next-generation container look like?
Original link: https://developer.aliyun.com/article/776157?
Copyright statement: The content of this article is contributed spontaneously by Alibaba Cloud real-name registered users. The copyright belongs to the original author. The Alibaba Cloud developer community does not own its copyright and does not assume corresponding legal responsibilities. Please refer to the "Alibaba Cloud Developer Community User Service Agreement" and "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines" for specific rules. If you find that there is suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.