background
With the continuous innovation of Internet technology and the rapid development of the television industry, watching online videos through television has gradually become an important entertainment method for the public. As one of the applications with the highest user activity on TV devices, the Kiwi App provides a wealth of content playback services for users. In addition, it also provides membership operations, special events and other services that require extremely high online efficiency. user. In order to meet the latter's demands, we investigated the current mainstream dynamic and cross-end technologies: H5, Flutter and React Native, and finally chose the H5 solution from the perspective of development efficiency, labor cost, dynamic capabilities and performance. Currently, the H5 page is responsible for It handles a large number of cashier, operational activities, special topics and other businesses in the Kiwi App. However, the main difficulty we face is that the H5 page takes too long to load on TV devices. How to improve the user experience of H5 pages on TV devices is an issue we urgently need to solve.
Challenges faced
Challenge 1: The replacement cycle of TV equipment is long and the system fragmentation problem is serious. Currently, equipment with TV system below 5.0 accounts for about 30%, which is a very high proportion. The first thing that optimization faces is the span of versions, and compatibility with lower versions is the primary consideration. The following figure shows the proportion of TV system versions:
Challenge 2: The performance of TV equipment is low. TV equipment is mainly divided into three types: TV, box and projector. The configuration of the above equipment is seriously lower than the mainstream mobile phone configuration of the same period. In our performance level classification, the CPU is 4 A device with a core A53 architecture and more than 1.5G of memory can be classified as a high-performance device. Among low-performance devices, there are still many devices with A7 architecture processors or 512M of memory.
Challenge 3: App versions are seriously fragmented. Due to the complexity of the current cooperation situation in the TV industry, there are many channels; traditional TV manufacturers pursue stability and are more cautious about upgrades; there are many cheap devices on sale, and they are close to no maintenance after sale; The complexity of the cooperation model leads to a lot of customization and difficulty in upgrading, which poses great challenges to optimization and launch at the SDK level.
Optimization process
1. Preparation
Before optimization, the most important work is to unify the performance caliber and formulate statistical indicators. At the caliber level, we did not take the conventional front-end page loading time, but adopted a scenario that is more in line with the user's real experience: from the time the user clicks the button to the time it is visible to the real user. Although this will increase the overall time consumption of our statistical indicators, after evaluation, this indicator is more conducive to the direction of our subsequent optimization work. The indicator caliber is explained as follows
1) The time it takes for the page to be visible: starting from the client click -> client page jump -> web container initialization -> the front-end DOM rendering is completed and visible.
2 ) The total interactive time: the page visible time + the total time that can respond to the user's remote control button.
3) Native page time-consuming: client page jump time-consuming.
4) Webview initialization: The initialization of the web container is time-consuming.
5) It takes time to call h5: It takes time to execute the first line of code from loadUrl to h5.
6) The time it takes to load h5: The time it takes for h5 to start executing the first line of code until it is visible on the page.
7) It takes time for h5 to be interactive: it takes time for h5 page to be visible and the page to be responsive.
After the statistical standards are unified, we will deliver the above time points at the webSDK level, collect online data, and carry out targeted optimization based on the issues fed back by the indicators. Without optimization, the loading speed of H5 is about 5.5 seconds on average, and the user experience is very poor. Through online data analysis, H5 loading time takes up a large proportion of the overall. Optimizing H5 loading time is an issue we urgently need to solve.
2. H5 loading time optimization
H5 loading time mainly depends on the optimization of the front-end part. Due to the limited length of the article, the conventional H5 page optimization work will not be described in detail, such as:
3) Business logic optimization
4) DOM structure optimization
5) Async routing loading in different modes under the same address
3. SSR optimization
In addition to the above optimization, SSR (server-side pre-rendering) technology has come into our sight. SSR is a technology that optimizes web application performance and SEO. By generating initial HTML on the server side, it improves page loading speed and search engine performance. Optimization and user experience. By choosing the appropriate framework, creating routes, writing components, server configuration and data acquisition, developers can implement server-side rendering, thereby providing users with a better web application experience and ensuring faster rendering of the first screen.
这种降低端上处理压力的方式，非常适合TV端设备性能较差的场景。SSR虽然也有自己的缺点，如虽然可以提高页面整体加载速度，但不利于页面的渐进加载。经过反复实验和线上数据，我们仍然认为SSR的收益整体是正向的，并研发上线。实验证明，SSR方案显著提升了H5页面加载速度。
The H5 page loading process optimized through SSR is shown in the figure below:
经过前端上述方案优化后，各个版本的加载速度都得到了显著提升。H5渲染部分的耗时从平均4秒减少至1.5s以下，总耗时减少至3.5秒左右。此时，单纯从前端角度继续优化遇到了瓶颈，投入产出比也较低，需要从客户端整体角度上继续思考优化手段。
4. Resource offline caching
CDN will deploy some key H5 resources (such as css, js, png, ttf, etc.), many of which are unchanged during the front-end version cycle and are large, and the client will pre-download them at the appropriate time. When rendering the page, we can use the shouldInterceptRequest callback of the WebView kernel to intercept the loading request of the online H5 URL. If the resource is not found in the offline cache, it will be loaded through the online network; if the resource is found in the offline cache, it will be loaded directly. Read resources from local disk and return to WebView. This method can greatly improve the speed of loading resources.
The general flow chart of the offline caching solution is as follows:
At the same time, during the process, we found that the Android native request library HttpUrlConnection on lower versions is still in the http1.0 stage and cannot enjoy the optimization of http2.0 (such as channel reuse), which makes the request during preloading time-consuming. higher. There are currently a large number of low-version devices on the TV side with versions below 5.0, so we chose to switch to the network library independently developed by the TV side. This network library supports http2.0, thus improving the request performance of low-version devices. In addition, we see that there is a certain system scheduling time from the time the user clicks to the opening of the H5 page. This time can also be used for optimization, that is, the parallel loading mentioned below.
5. Parallel loading
In addition to the above-mentioned solutions for caching JS/CSS and other resources in advance, caching HTML pages in advance is also a common optimization method in the industry. Before the page is SSR, this caching mechanism has not achieved good results because the performance bottleneck is not in downloading HTML data. After the page SSR, this method has entered our field of vision again. After the rendering data has been generated, such a caching mechanism can theoretically play a greater role.
But at the same time, we encountered other difficulties. Since personalized algorithms have been widely used in business, the method of caching pages in advance and keeping the content unchanged for a certain period of time has formed a conflict with the business requirement of keeping page data refreshed in real time. conflict. This requires us to find optimized technical solutions that are more suitable for business scenarios.
The Android system will consume system time when doing Activity page jump switching. This time consumption is inversely proportional to the device performance. We intercept the user's click on the web page while page jump switching to start the task in advance and load the SSR of the H5 page in parallel. data. Then, a unique token is generated based on the URL and cookie parameters. When it comes time to actually render the WebView, redirect the URL to the cache. At the same time, multi-thread lock synchronization and timeout mechanisms are used to further improve the loading speed of H5.
The general flow chart of the parallel loading solution is as follows:
After completing these optimizations, our loading speed continued to be optimized from 3.5 seconds to about 2.8 seconds, an increase of about 23%. After a series of optimization measures mentioned above, our H5 loading time has been reduced from the initial average of 5.5 seconds to about 2.8 seconds. However, compared with pure native (Native) pages, there is still a large gap in loading speed, and we need to continue to look for more effective optimization methods. In order to further improve the user experience, we have made various technical attempts, and through active communication and cooperation with other technical teams, we have new ideas.
6. Container preheating
When the APP is started and the main thread is idle, we can preheat the WebView engine and build a WebView cache pool, so that the preheated container can be reused and the WebView loading speed can be improved. This optimization strategy is mainly aimed at medium-to-high-performance devices and low-performance devices with large memory. When the device is idle, we preheat the WebView container and add the preheated container to the cache pool.
In our subsequent use, we obtain the preheated WebView container directly from the WebView cache pool. This saves time creating web containers and jscore.
7. Page pre-rendering
H5 on the TV side has many real-time business scenario restrictions, especially operational activities that are very time-sensitive, which puts certain restrictions on our optimization. However, we have found some scenarios that can be customized and optimized. For example, when non-member users watch member-only content, there is usually a 6-minute free trial time. After the trial time is over, they will automatically jump to H5. This type of scenario provides us with natural advantages for pre-rendering. In similar scenarios, pre-rendering is automatically triggered when the countdown starts, allowing H5 content to be loaded in advance and achieving the instant opening effect of H5. As shown in the GIF below, the upper picture is the loading process without optimization, and you can see the obvious black screen and loading process; the lower picture is the result of pre-rendering optimization, achieving true second-to-second launch.
After completing the above optimization measures and comparing the data of the same period last year, we can see from the online data that the loading time has been further reduced, from the initial average of 5.5 seconds in non-SSR scenarios and 3.5 seconds in SSR scenarios to the current average of 2 seconds. It has significantly improved the user experience.
Achievements
We conducted AB experiments on the optimization on the end. The test data after breaking up and averaging showed that our optimization measures increased the conversion rate of the order generation page by about 21% on average, and the conversion rate of payment success rate also increased by 2.4% on average.
Experiments have proven that improving the loading speed and user experience of key business pages has a very direct positive impact on business, which also provides us with sufficient confidence and motivation to continue to promote optimization in the future.
future plan
In the future, we hope to find more ways to further reduce performance indicators, control the average page time to less than 2 seconds, and control degradation.
In addition, we have noticed that the average data does not fully reflect the actual user experience. Some tail users still face poor user experience. We will continue to analyze the actual situation encountered by users after the 90th percentile and carry out targeted optimization. . At the same time, we will continue to carry out customized optimization for important business scenarios such as the checkout counter to further improve the loading speed of key businesses, thereby continuously improving user experience and business conversion.
Maybe you also want to see
This article is shared from the WeChat public account - iQIYI Technology Product Team (iQIYI-TP).
If there is any infringement, please contact [email protected] for deletion.
This article participates in the " OSC Source Creation Plan ". You who are reading are welcome to join and share together.
