Author: Yu Hao-fei

The Southeast Asia market with a population of 680 million is experiencing explosive growth. As the leading e-commerce platform in Southeast Asia and an important growth engine of Alibaba’s globalization strategy, Lazada has grown into a leading and fast-growing flagship e-commerce platform in the region, driving the progress of the digital economy infrastructure in Southeast Asia. Lazada currently operates in Six southeast Asian countries including Indonesia, the Philippines, Thailand, Malaysia, Singapore and Vietnam, with employees from 50 different countries and regions around the world, realizing the simultaneous promotion of business in each country and maintaining a strong and sustained growth trend in the number of buyers and merchants.

Data show that more than 800,000 brands and merchants participated in THE day of D11. Lazada’s sales in Vietnam doubled in the first hour compared to last year, and Lazada’s sales in Singapore increased by 10 times compared to normal days! Behind these incremental Numbers, leave the Lazada teams, businesses, brands and customers work together to the wireless technology team insist on data driven, technology can assign, efficient and stable support during the D11 shopping scene, at the same time start the time-consuming, rendering the venue, package volume and main link progress has significant experience.

Last year, we have carried out a large number of basic technical strategies such as layout optimization. In 2021, we will step down the optimization scene to a more detailed field, combined with “page merging and task reprogramming” to optimize the application startup substantially, and carried out “full-link routing dynamic pre-request” for low-end machines. In order to further enhance data reuse, “Shopping cart incremental update” and “Single page first screen prediction”…… are also carried out The link has been optimized for various aspects of basic link core scenarios such as Lazada startup, home page, PDP, Cart, Checkout, etc., which forms the re-upgrade of link-level user experience. The process of quantitative change is bound to lead to qualitative change and ultimately improve the overall business transformation efficiency.

Start task choreography & lazy loading

Application startup inevitable part, as the user to enter the home page of the first body feeling much startup performance to the user to determine whether the user the choice to continue, so start the optimization of the App, we have been continuing to develop at the same time as the business have complex and can optimize the space compression, optimization of the challenges is also very big, have experienced constant exploration.

Application startup phase has dozens of large and small tasks, the scheduling parallel tasks need to be the main thread, the main thread itself also needs to perform some must perform the task, between tasks and logical dependence and rely on lock, so we will task into several groups, group in parallel can achieve maximum concurrent effect, serial dependence problem between groups, A scheduling framework that balances task concurrency and dependencies for synchronous scheduling by the main thread between groups.

Start the task optimization purpose is to let the group task parallel faster, reducing the number of the main thread, can let the main thread scheduling the next set of faster, so each set of the start time is determined by the longest time-consuming tasks within the group, through to choreography of task, make logic dependency and lock rely on a task, as far as possible both in the same group, Based on this principle, we further combed short tasks and locks through systrace and other tools and optimized them accordingly:

  1. The time-consuming tasks are further split to shorten the time-consuming tasks in a single group.
  2. Try to decentralize the following tasks using loadLibrary locks while maintaining dependencies to minimize lock competition;
  3. Time consuming tasks are optimized and tasks that do not need to be used during system startup are initialized after interactivity.

Through the above optimization strategy, the current optimization start time relatively double last year 11 have greatly improved, with further progress of optimization, the start of the subsequent optimization, need more add determination and patience, and constantly introduce new tools, new ideas, combined with the improvement of the online data more accurately, management and optimization.

Start page merge

Based on the arrangement of startup tasks, we can observe that in a complete startup process, the APP will go through the creation of Application, the creation of splash screen page Activity, and finally the home page Activity that the user actually sees. Namely LazadaApplication. The onCreate () – > EnterActivity. The onCreate () – > MainTabActivity. The onCreate ()

If you combine the two pages into one Activity, the user launches the home page. Complete the switch from the above flash screen page to the home page Activity through View conversion inside the Activity, so that the user can reduce the creation of Activity and corresponding Binder calls in this process, so as to display the home page content more quickly

Finally, a new launch process is evolved from three steps to LazadaApplication. The onCreate () – > EnterActivity. The onCreate () two step, inside the EnterActivity, when the task initialization is complete, Through the conversion of contentView, the flash screen page is replaced by the home page content, so as to improve the startup speed and save about 250ms startup time with the help of experimental sampling.

Full-link routing dynamic prerequest

How weak network analysis of directional property for low-end machine, and form a link type rather than a single point of optimization strategy is our new swimmer in 2021, the whole link preloading project is in the global resources on the intelligent dispatching an attempt, by customizing more flexible scheduling policy to achieve the best use of idle resources system, we start the core target of this project is: Flexible pre-task scheduling enables full link turn-on experience in seconds.

  • Navigation preloading uses the time gap in the navigation process to load the resources of the next page in advance. This saves not only 100ms-200ms for page switching, but also 100ms-200ms for page initialization (some pages have been “initialized and synchronized with network loading”).
  • Intelligent scheduling: based on user behavior prediction, load the resources of the next predicted page in advance using the idle time of the current page; Forced scheduling: Without behavior analysis, the system loads resources on the next configuration page in advance using the idle time of the current page.

By defining a set of standardized resolution scheduling framework to support not only resolution mapping of remote configuration but also remote scheduling of local tasks, the whole link routing request can be realized without service intrusion.

The network request process is accelerated through pre-request, and 110ms is optimized for PDP scenario, 230ms for Cart(from PDP) scenario, 110ms for single page, and 450ms is expected to be saved for user core shopping link.

Shopping cart asynchronous refresh incremental update

Different from page opening scenarios: In the second-brush scenario, there is basically no time consumption for the end-to-end View construction and rendering. Both Android and IOS have mature View reuse mechanisms. The core problem that hinders the second-brush user experience at present lies in the network time-consuming process. There are two reasons for the second-brush network time:

  1. Full updates cause the server to recalculate full page elements in update (Trade based on the Altron middleware protocol);
  2. Full data return causes the data transfer and parsing process to be more time consuming.

Therefore the preliminary solution is: according to the two brush scene server return only need incremental updating of data elements, the client with the aid of the last data locally incremental consolidation update, so that reduces the request from the server time consuming, and at the same time also can reduce the data size to reduce transmission and parsing time-consuming (plus a contrast process takes, of course, the basic can HuLv)

The overall scheme is summarized as follows: with the help of the client’s ability to reuse the last page data, incremental update is carried out for the shopping cart asynchronous operation to reduce the calculation range and packet volume of the server request, and finally achieve the purpose of reducing the network time consumption. In the first phase, we mainly conducted directional optimization for the operation of “reverse selection of commodity stores, increase or decrease of commodity quantity”, and narrowed the calculation scope to “shop elements of selected goods, commodity store elements of operation, and special fixed elements”.

Effect comparison video, please see: Lazada D11 experience upgrade technology practice

Data from Shenzhen, China, online environment

  • By AB experiment, the ServerRt optimization was 57.52%, SKU query volume optimization was 80.69, and QPM optimization was 217.75%

  • The TotalTime of the client’s total data increased by 31.82% from 1100ms->750ms. From the subdivision dimension, it can be observed that the refresh action caused by Item decreased significantly, and the rest was basically stable, which was in line with expectations.

Shopping cart refresh frequency weakened

The Android shopping cart currently triggers a refresh operation each time it is re-entered, combined with shopping cart line performance data: Users have to wait for 1.029.81ms each time they enter the basic, and 64.5% of users can finish loading within 1s, which leads to a problem that “some users who add to the shopping cart may also refresh when they return”, such as this user story: The user sees an interested product in the Cart Just For You module and clicks into the PDP. After browsing the PDP (without any purchase operation), the user returns to the Cart. The Cart rebrush will cause the data that was browsing before to be overwritten. Therefore, we started this project with the main purpose of reducing the refresh frequency of shopping cart while taking into account the normal refresh of shopping cart.

On the Android side, only “refresh when returning to Cart” is open, considering that “there is a large number of Android users in the promotion scene, if the purchase action is directly bound to the Cart refresh behavior, it may cause traffic pressure”. Meanwhile, the Android side provides the ability to “refresh the shopping cart instantly” for use in special scenarios.

Effect comparison video, please see: Lazada D11 experience upgrade technology practice

Data from Shenzhen, China, online environment

  • The refresh request was reduced by 55.45% in the reversion scenario, and the overall refresh request was reduced by 35.28%. It is expected to reduce tens of millions of redundant requests in a single day after the push

Single page first screen prediction

By comparing the data of the same period of the year, we find that compared with 202004, the time of Checkout Render interface fluctuates around 860ms, and the time of 2021 has increased 35% to 1160ms. In view of the increasing network time of Checkout, The client promoted the Checkout first screen rendering cache project. The main purpose was to quickly render the first screen view of the page by reusing parent page data and local cache data to reduce the user’s anxiety during blank loading.

Through the analysis of online data, the paths to Checkout mainly come from PDP.70+% and CARt.20 +%. Combined with these two different paths, reusable data can be divided into two types according to the way of data reuse:

  1. Last hop page data; For example, goods and stores selected by Cart, stores corresponding to PDP, goods and logistics distribution information;
  2. Fixed elements that occur but change data; For example, store logistics distribution (new), total package price, payment method, order flow, order total price, etc.
  3. Historical data that users do not change frequently; Such as address, coupon entry components, etc.

The data can be divided into four categories according to the storage form: last-hop bring in, file cache unencrypted, file cache encrypted (such as address information), and self-built elements (store logistics). Based on this reasoning, most areas of the page can be presented predictably ahead of time based on reusable data, and the page view can be updated when the network data is called back.

Effect comparison video, please see: Lazada D11 experience upgrade technology practice

  • After AB experiment verification, only open the shopping cart to the single page of the optimized path, optimized about 125ms; Only open the optimized path from PDP to single page, which optimized about 390ms; Fully open drum lift 528ms.

Single page merge request

According to the test team, in the scenario of entering Checkout through different routes (also in the scenario of single product), users’ body perception time would be different to some extent. After detailed comparison, the difference was nearly 400ms. Therefore, this problem was reported to the end-to-end team for investigation. From the results of end-to-end combing, the main difference between the two paths is the time of the Cart_Submit request, and the Cart jump is triggered after receiving the callback from the server interface. Compare the mtop. Lazada. Carts. Ultron. Submit the totalTime 400 ms, is just two paths of difference.

Through further analysis, Cart – > Checkout path, the client just will return to the service side buyParams parameters through to give the mtop lazada. Buy. Renderorder interface, didn’t do any processing. However, due to the synchronization of the two requests on the end, there is a difference in user experience. Network characteristics of southeast Asia, we have seen from the above mtop. Lazada. Carts. Ultron. Submit ServerRT only need less than 100 ms, transport back and forth but time-consuming deficiency needs 200-300 ms, if only see ServerRT may feel two synchronous request not too much, However, considering the network transmission time, there will be a great difference in the user’s sense of body.

Based on the rear, we provide a collaborative server based on mtop. Lazada. Carts. Ultron. Submit and mtop lazada. Buy. Renderorder merge request interface, without modifying the original interface, on the basis of internal logic, The server encapsulates an upper-layer interface and opens it to the end – side. The initiating node of the request is adjusted to enter the order page, that is, click the order button to directly enter the order page & pass through the Cart selected data and make requests on the order page; After tweaking, the failure scenario hosted by cart.submit will hang directly on the Checkout page.

  • After optimization through AB experimental analysis, route response time (from user click start timing to single page initiating page request)434.48ms->64.33ms increased by 85.19%; total network time (from user click start timing to single page receiving request return data)1308.66ms->965ms increased by 26.26%;

Checkout front request & Early render

Although the performance of the secondary checkout counter native has been greatly improved compared with that of WEEX, it is still slightly inferior to that of rival products. Through the analysis of the existing loading process, we find that the current upstream process of entering the checkout counter is serial, and the segmentation time is as follows:

The core idea of optimization: move forward, serial change parallel. Mtop itself does not depend on the Activity and can be directly placed in the routing layer to start the request. Meanwhile, the rendered process actually contains the loading layout time and the drawing process time (measure+layout+draw). Through local self-test, you can see a layout of the checkout payment list. The inflate normally takes about 20ms and it takes about 100ms for 5 of these layouts to cover 80% of the page (maybe more on low-end machines), so the rendering process can actually be pre-loaded as well.

  • According to AB experimental analysis, the optimized performance improved by 14.29% in 100ms (701.62ms->604.74ms)

Summary and Outlook

  • With the help of AB experimental platform evaluation, compared with the original group PR, it is estimated that 71,203DAB, 7051DNB, will be brought in the optimized group after the extension.
  • Application startup time: compared with last year, the overall startup time of D11 Android is 23% higher, and the overall startup time of iOS is 20% higher;
  • Page rendering time index: compared with last year, D11Android full link time increased by 37%, iOS full link time improved and optimized by 34%;
  • For the time index of page two-swipe scenario, the TotalTime of shopping cart data is increased by 31.82%, and the ServerRt is expected to be optimized by 57.52% after full volume.
  • The index of reducing redundant requests: 55.45% refresh requests are reduced in the shopping cart return scenario, 35.28% refresh requests are reduced as a whole, and tens of millions of redundant requests are expected to be reduced in a single day after the complete push.

The experience optimization program will be a continuous process as the business grows, and Lazada will continue to focus on detailed scenarios, identifying problems, locating problems, solving problems and learning lessons. Tomorrow, we will continue to share in-depth analysis of Lazada container Optimization journey, stay tuned.

Finally, I would like to thank all the partners who participated in the project

We’re hiring!

Resume should be sent to:[email protected]

Founded in 2012, Lazada has more than 80 million active consumers in Southeast Asia in Indonesia, Malaysia, the Philippines, Singapore, Thailand and Vietnam, and has a competitive logistics and payment network in the region. As alibaba southeast Asia flagship electric business platform, the use of alibaba advanced product technology booming overseas mature local electricity capacity and help ali ecological rapid development of overseas business at the same time, we have been based on ali platform extract a set of international link system, link, from wireless mobile terminal to deal from merchants business to big data and recommendations, Create a new end-to-end international e-commerce operating system.

Here you will not only have the opportunity to learn about core platforms such as commodities, transactions, membership and marketing, but also have the opportunity to accept the challenges of highly forward-looking overseas e-commerce business, and need to abstract business and platform stripping for multinational scenarios. The task is novel and challenging. The positions we are recruiting include product, architect, development, testing, front-end and other opportunities. Our business involves all aspects of e-commerce from end to end. As long as you are confident, capable and passionate, you will definitely find new challenges that attract you. Join Lazada and join us to stimulate the Southeast Asian market and create international e-commerce!

Pay attention to [Alibaba mobile technology] wechat public number, every week 3 mobile technology practice & dry goods to give you thinking!