Authors: Wei Ju (Wen Shi), Fan Lei (Storage Energy)

In recent years, the digital economy in Southeast Asia continues to develop, and Lazada continues to maintain strong and sustained growth in the number of buyers and merchants. In 2020, more than 40 million consumers, more than 400,000 merchants and brands came to Lazada platform on 11.11, this year, more than 800,000 brands and merchants participated in 11.11, Lazada Vietnam’s first hour sales doubled last year, Lazada Singapore’s first hour sales increased 10 times than usual!

Behind the explosion of a series of business data is the rapid growth of traffic. As the bearer of H5 business, containers also serve more and more H5 businesses: venue, Flash sale, Lazmall, wallet and so on. Therefore, the user experience of H5 pages is facing greater challenges.

In the past year, The Lazada container team has been deeply engaged in H5 container optimization. In the face of the high proportion of online weak network users and the wide distribution of low-end models, we have adopted pre-rendering scheme to optimize the conference page of the Big Promotion, and we have taken the initiative to optimize the daily GCP page and ICMS page with pre-fetching page data. Static resource caching in advance and other solutions, in-depth optimization of H5 page traffic services, ultimately improve user experience and service transformation of H5 services.

Problem analysis

On the day of 2020 D11 promotion, the first screen recording time was 9383ms, and the user experience was very bad. Most users could not bear it and directly quit the page, resulting in serious traffic loss.

First, analyze the complete link of the venue page, including the following stages:

The whole process is heavy with tasks and network overhead, resulting in page rendering being pulled very late, so it is not surprising that the first screen takes a long time.

Then analyze the distribution of online users’ network and user models, as shown in the figure below:

As can be seen from the figure above, mobile network accounts for a high proportion of online market users, while low-end models account for a large proportion, especially for Indonesian users, whose mobile network stability is worse and low-end models account for a prominent proportion. So the optimization of low-end models and weak network users has become our key direction.

Optimization scheme

Monitoring system construction

To do a good job, you need to do a good job. Online users are so far away from us that it’s hard to experience what their real situation is like. Then only from the monitoring, the page loading of each link buried point report, from the detailed data to measure the real experience of users. In this regard, we divide the loading link of H5 page as follows:

Including routing, container creation, page loading, page rendering, user exit and other links, burying each link, reporting the page loading status, time point, time consuming and other information to DP2 and UT, and establishing real-time monitoring:

Route and container initialization monitoring

Page load Monitoring

Monitor the first screen time

Container preheating: space for time

The venue page was built by GCP platform, and the analysis found that each page would execute the same JS, and only a small amount of business JS execution and rendering on each page. After discussion and verification, the common basic JS was abstracted out and isolated from business JS, and these resources were loaded into webView in advance before users opened the page. On the one hand, it reduces the resources that need to be loaded after users click the page. On the other hand, it analyzes and preprocesses public JS and CSS in advance.

After the preheating scheme went online, the first screen time dropped to within 2s, and the BDay preheating hit rate was 36%. Through buried point analysis, it was found that there were the following problems in preheating document loading:

1. When the preheating container is used, the preheating task is not started, mainly in the call end scenario.
2. The preheating is incomplete and takes a long time. The average time is 5000+ms, or the preheating fails.
3. When using the preheating container, the preheating task starts, but there is no front-end callback to complete the preheating, and the process has a live mechanism, once there is no callback for the first time, the preheating webView may not be used, nor will the preheating task restart, unless the process is restarted;
4. If the preheating container is hit, the front end does not call back the first screen, so no new preheating container will be created again and the next startup page cannot be hit;
5. The preheating rule is not matched.

Advance of preheating time

In view of the problem of loading time for preheating documents, we set the preheating time to the home page in advance. After interaction, we start loading the preheating pages as early as possible. Meanwhile, we cache the main document resources locally through ZCache in advance to reduce network transmission.

Warm-up retry mechanism

The start time of preheating can be exchanged on the home page. After the preheating is complete, the front end will notify the client of the completion of the preheating event. When the user opens a Web page, the user will judge whether the preheating is complete and will use it when it is complete. In this case, there may be a warm-up failure and the client does not receive a notification that the warm-up is complete. In addition, after a Web page is opened and the screen is displayed, the front end will call back a first-screen notification, which will trigger the preheating of a new WebView. Through data analysis, it is found that some users did not receive the first-screen notification, so the next page cannot match the preheating.

In view of the above situation, we put forward the preheating retry mechanism to improve the preheating hit ratio. There are mainly two scenarios of preheating and retry. The first is preheating and retry when the home page is idle. The default timeout period is 10s. When the timeout period expires, the system checks whether the preheating is complete. If the preheating is not complete, a new preheating is triggered. The specific process is as follows:

Warm-up link matching

Through the analysis of online data, it is found that the preheating hit rate of some GCP pages is 0. The reason is that it is necessary to match the Web page link and the preheated main document link, and the host and path of the Web page link should be exactly the same as the host and path of the preheated main document. However, due to various reasons, The host and path may be different from that of the preheated main file, causing the preheated file to fail to be hit. In this case, regular matching rules are delivered through Orange configuration. As long as the page link matches the rules, it can use the preheating container instead of just matching the single preheating main document link. Meanwhile, the configuration unified the GCP page and ICMS page.

Examples of matching rules:

prehot_regex={"id":[{"url":"https://pages.lazada.co.id/wow/gcp/route/lazada/id/upr_1000345_lazada/channel/id/upr-router/ id_upr?lzd_open_type=pre_hot&at_iframe=1","type":"gcp","prehot_regex":"^https://((pages)|(www)|(pre-wormhole)).lazada.co .id/wow/gcp/route/lazada/id/upr_1000345_lazada/channel/id/upr-router/id_upr"}],"my":[{"url":"https://pages.lazada.com.my /wow/gcp/route/lazada/my/upr_1000345_lazada/channel/my/upr-router/my?lzd_open_type=pre_hot&at_iframe=1","type":"gcp","pr ehot_regex":"^https://((pages)|(www)|(pre-wormhole)).lazada.com.my/wow/gcp/route/lazada/my/upr_1000345_lazada/channel/my /upr-router/my"}],"sg":[{"url":"https://pages.lazada.sg/wow/gcp/route/lazada/sg/upr_1000345_lazada/channel/sg/upr-router /sg?lzd_open_type=pre_hot&at_iframe=1","type":"gcp","prehot_regex":"^https://((pages)|(www)|(pre-wormhole)).lazada.sg/wo w/gcp/route/lazada/sg/upr_1000345_lazada/channel/sg/upr-router/sg"}],"ph":[{"url":"https://pages.lazada.com.ph/wow/gcp/r oute/lazada/ph/upr_1000345_lazada/channel/ph/upr-router/render?lzd_open_type=pre_hot&at_iframe=1","type":"gcp","prehot_r egex":"^https://((pages)|(www)|(pre-wormhole)).lazada.com.ph/wow/gcp/route/lazada/ph/upr_1000345_lazada/channel/ph/upr-r outer/render"}],"th":[{"url":"https://pages.lazada.co.th/wow/gcp/route/lazada/th/upr_1000345_lazada/channel/th/upr-route r/th?lzd_open_type=pre_hot&at_iframe=1","type":"gcp","prehot_regex":"^https://((pages)|(www)|(pre-wormhole)).lazada.co.t h/wow/gcp/route/lazada/th/upr_1000345_lazada/channel/th/upr-router/th"}],"vn":[{"url":"https://pages.lazada.vn/wow/gcp/r oute/lazada/vn/upr_1000345_lazada/channel/vn/upr-router/vn?lzd_open_type=pre_hot&at_iframe=1","type":"gcp","prehot_regex ":"^https://((pages)|(www)|(pre-wormhole)).lazada.vn/wow/gcp/route/lazada/vn/upr_1000345_lazada/channel/vn/upr-router/vn "}}]Copy the code

Through a series of optimization, our market GCP page and Flash sale page preheating hit rate increased to about 60%, the main venue preheating hit rate close to 70%.

Container prerendering: The ultimate user experience

In order to further improve the user experience to the extreme, achieve real straight out effect, we aimed at promoting the venue for a pre-rendered front movement, through the module and the front page of communication interaction, container terminal and the events of the front-end communication report, shielding, flow control, etc., pre-rendered venue page ahead of time, screen in real time transient meeting, In this case, the time for customizing the first screen tends to 0.

Before and after the optimization of screen recording effect, please click to view: Lazada container in-depth optimization tour

In the screen recording, the page before optimization is the page during last year’s Double Twelve, and after optimization, the page during BDay is used. The page structure has changed, but the load of resources is the same. From the view of screen recording effect, the experience after optimization, whether preheating or pre-rendering, has a qualitative improvement compared with that before optimization.

For pre-rendering, we have completed the page loading and rendering operations in the background. Theoretically, we only need to synthesize the top screen, but there is a white screen in the recording process. It can be seen through the video frame division that when the animation enters the scene, there is indeed a white screen:

Through experiments, comparing other pages (such as www.baidu.com) to hit the pre-rendered effect, it is found that it does not have a white screen process. This difference is that in the middle of the page for pre-rendered container at the same time, the venue will send a screen events to the front, on the front and try to do some soft tasks, such as the soft refresh will have business js task execution, lead to block the kernel rendering process, we will inform the asynchronous deferred on the screen after the middle white during the time there is a lot less, record the effect of screen, please click to view: Lazada container depth optimization journey

Test the venue page during 7.7 promotion period, compare the time from click to the first screen, and the data is as follows:

In the case of delayed on-screen notification, the screen recording time is optimized by 12%, and the user’s motion perception will be greatly improved.

SSR: Call end performance enhancement tool

Preheating/pre-rendering can optimize the user’s experience of entering the venue from the home page to the extreme, but there are still 20%-40% users who directly enter the venue landing page through the call terminal cooling. In this case, there is not enough time for preheating and pre-rendering, so improving the loading speed of the call terminal page is an urgent problem to be solved.

From the perspective of front-end analysis, page loading is divided into several steps: main document loading, core JS loading, data request, page rendering, screen display, image request display, these steps are serial, involving a large number of resource file network transmission and JS parsing execution. From what has been discussed and front-end classmate, SSR is a potential optimization scheme, the data on the server will recall and parses the rendering into static HTML, then only need to download a master document to have on screen display, photos and request, just two rounds of data interaction, from a client perspective, reduced the three data interactive link, Greatly reduce the amount of data transmission and connection request times.

Site SSR program

For a video comparing SSR and non-SSR, check out Lazada’s Deep Optimization journey for Containers

SSR rendering advantages:

1. Reduce the number of resources on the first screen and the transmission magnitude;

2. Reduce the time cost of client parsing and executing business JS;

3. MTOP requests are made in the client, avoiding the problems of security guards and personalized recommendations.

In the same environment (same mobile phone, same page, same App, same network environment), it is found that SSR can optimize 15.2% of the first screen time in the scene of opening the page in the end, and 28.1% of the first screen time in the scene of calling the end. Specific test data are as follows:

Measured data:

standardized

First screen time standardization

First screen time: on the one hand alignment group interactive front end complete rendering time, part of the business domain by UC T2 time, advantage is that all business is unified, faults is a kernel to UC acquisition, on the one hand, increase the full screen is closer to the user experience first screen time: the first screen resources all loaded, including js, CSS, and image resources.

Quantifiable user body sense — white screen detection

The first screen time can be used to measure the experience of most users who normally finish loading the page. However, there are still many users who quit the page before the first screen is completed, or errors occur in page loading. Such cases cannot be reflected in the first screen time. Therefore, the client adds the unified white screen detection capability, which uses dynamic configuration to check the content of current page elements. When a user leaves the page (including cutting background, exiting, and jumping to the next page), the white screen status can be monitored.

Standardization of prerendered and preheated containers

Establish a standard connection protocol between the front-end and the client. The client loads the corresponding ROCKET container according to the configuration and the current APP memory level through the configuration platform. The container background preloads the main document and business resources, and monitors the background abnormal exposure and other data. The front end intercepts the report, the two ends agree on the standard rendering interaction JSAPI, and the on-screen update notification, etc., and the client is responsible for the unified memory card port and rendering timing.

Summary and Outlook

After one year of in-depth optimization, the first screen time of 2021 D11 conference is 50% higher than that of 2020 D11 on Android platform, and the first screen time of IOS enters the second open era. According to the screen recording data of the real machine in the Computer room of Indonesia, the first screen time of the main venue in the preheated scene is 1 times faster than that of the competing Shopee, and 24.8% faster than that of the competing Shopee in the non-preheated scene.

Looking forward to the future, we will continue to optimize the container from the model system, memory allocation, Webview kernel characteristics and other multi-dimensional and maximum granularity to minimize the impact on the operation stability of app. At the same time, we will deeply optimize some problems such as loading failure and time consumption of images and other resources in Webview kernel. Create a stable H5 container with an ultimate experience.

We’re hiring!

Resume should be sent to:[email protected]