写点什么

Lazada 容器深度优化之旅

  • 2022 年 2 月 09 日
  • 本文字数:4971 字

    阅读完需:约 16 分钟

Lazada 容器深度优化之旅


作者:魏扼(文射)、范磊(蓄能)


近年来东南亚数字经济持续发展,Lazada 在买家和商家数量上继续保持了强劲的持续增长态势。2020 年的 11.11 有超过 4000 万个消费者、超过 40 万的商家和品牌来到 Lazada 平台,今年 11.11 当天有超过 80 万品牌和商家参与,Lazada 越南首小时同比去年销售额翻番,Lazada 新加坡首小时销售额较平日增长 10 倍


一连串业务数据爆涨的背后,是流量的快速增长,容器作为 H5 业务的承载,也服务了越来越多 H5 业务:会场、Flash sale,Lazmall、钱包等等,因此,H5 页面的用户体验受到更大的挑战。


在过去一年里,Lazada 容器团队深耕 H5 容器优化,在面对线上弱网用户占比高,低端机型分布广等情况下,我们采用预渲染方案针对性优化了大促会场页面,首创性运用预热方案优化日常 GCP 页面和 ICMS 页面,同时对页面数据进行预取,静态资源提前缓存等方案,对头部 H5 页面流量业务进行深度优化,最终提升 H5 业务的用户体验及业务转化。

问题分析

2020 D11 大促当日,会场录屏首屏时间 9383ms,用户体验十分糟糕,大部分用户无法忍受而直接退出页面,导致流量流失严重。


先分析我们打开会场页面的完整链路,包括如下阶段:



整个流程任务繁重,网络开销大,导致页面渲染被拉到非常晚,首屏时间长也就不奇怪了。


再分析线上用户的网络和用户机型的分布情况,如下图所示:



从上图可以看到线上大盘用户移动网络占比高,低端机型占比大,特别是印尼用户,移动网络稳定性情况更差,低端机型占比突出。那么针对低端机型以及弱网用户的优化成为我们重点攻坚方向。

优化方案

监控体系建设

工欲善其事必先利其器,线上用户距离我们非常遥远,他们的真实情况是怎样的,我们很难体验到。那么只能从监控着手,对页面加载的各环节进行埋点上报,从详细的数据来衡量用户真实体验情况。对此,我们将 H5 页面的加载环节进行了划分,具体参考如下:



包括路由、容器创建、页面加载、页面渲染、用户退出等环节,对每个环节进行埋点,将页面加载状态,时间点、本环节耗时等信息上报到 DP2 和 UT,并建立实时监控:


路由和容器初始化监控



页面加载监控



首屏时间监控


容器预热:空间换时间

会场页面由 GCP 平台搭建出来的,分析发现每个页面都会执行相同的 js,每个页面只有少量的业务 js 执行和渲染,经过讨论和验证,把公共的基础 js 抽象出来,和业务 js 隔离,在用户打开页面前就将这些资源提前加载到 webview 中,一方面减少用户点击后页面需要加载的资源,一方面提前对公共 js、css 进行了解析和预处理。



预热方案上线后,首屏时间降到 2s 内,BDay 预热命中率 36%,通过埋点分析,发现预热文档加载存在以下问题:


  1. 使用预热容器时, 预热任务未启动, 主要是唤端场景;

  2. 预热未完成,预热耗时较长平均耗时 5000+ms,或者预热失败;

  3. 使用预热容器时, 预热任务启动, 但是前端没有回调预热完成, 而进程存在保活机制, 一旦第一次没有回调, 预热 webview 可能一直不会被使用, 也不会重启预热任务, 除非重启进程;

  4. 命中了预热容器, 前端未回调首屏, 导致不会再次创建新的预热容器, 下次启动页面无法命中;

  5. 未匹配预热规则。

预热时间提前

针对预热文档加载耗时的问题,我们把预热时机提前到首页可交互后,尽可能早地开启预热页面的加载,同时我们将主文档资源通过 ZCache 提前缓存到本地,减少网络传输。

预热重试机制

预热启动时机在首页可交互,预热完成后,前端会通知客户端预热完成事件,用户打开一个 Web 页面时,会判断是否预热完成,完成了才会去使用。这中间可能就会存在预热失败的情况导致客户端没有收到预热完成的通知。另外在打开一个 Web 页面完成上屏之后,前端会回调一个首屏通知,此时会触发预热一个新的 WebView,通过数据分析,发现部分用户没有收到首屏通知,导致下一次打开页面无法命中预热。


针对上述情况,我们提出了预热重试机制来提升预热的命中率。主要是两种预热重试的场景, 第一种是首页闲时预热重试; 第二种是打开页面后预热重试,定义超时时间,默认为 10s,超时时间到了之后会检查是否完成预热,没有完成预热则会触发一次新的预热,最多重试次数为 3 次。具体流程如下图:


预热链接匹配

通过分析线上数据,发现某些 GCP 页面预热命中率为 0,原因是命中预热需要匹配 Web 页面的链接与预热的主文档链接,需要 Web 页面链接的 host 和 path 与预热主文档的 host 和 path 要完全一致,但是由于种种原因,线上会存在 host 和 path 与预热主文档的不一样,导致无法命中预热。针对这种情况,通过 Orange 配置下发正则匹配规则,页面链接只要匹配上了规则就可以使用预热容器,而不只是匹配单一的预热主文档链接,同时配置统一整合了 GCP 页面和 ICMS 页面。


匹配规则示例:


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","prehot_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/wow/gcp/route/lazada/sg/upr_1000345_lazada/channel/sg/upr-router/sg"}],"ph":[{"url":"https://pages.lazada.com.ph/wow/gcp/route/lazada/ph/upr_1000345_lazada/channel/ph/upr-router/render?lzd_open_type=pre_hot&at_iframe=1","type":"gcp","prehot_regex":"^https://((pages)|(www)|(pre-wormhole)).lazada.com.ph/wow/gcp/route/lazada/ph/upr_1000345_lazada/channel/ph/upr-router/render"}],"th":[{"url":"https://pages.lazada.co.th/wow/gcp/route/lazada/th/upr_1000345_lazada/channel/th/upr-router/th?lzd_open_type=pre_hot&at_iframe=1","type":"gcp","prehot_regex":"^https://((pages)|(www)|(pre-wormhole)).lazada.co.th/wow/gcp/route/lazada/th/upr_1000345_lazada/channel/th/upr-router/th"}],"vn":[{"url":"https://pages.lazada.vn/wow/gcp/route/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"}]}
复制代码


通过一系列优化,我们大盘 GCP 页面和 Flash sale 页面预热命中率提升到 60%左右,主会场预热命中率接近 70%。

容器预渲染:极致用户体验

为了进一步极致的提升用户体验,达到真正的直出效果,我们针对大促会场做了一个预渲染的前置动作,通过和首页模块的通信交互,容器端和前端的事件通信、上报屏蔽、流量控制等,提前预渲染会场页,在真正上屏的时候瞬开会场,此时整体会场自定义首屏时间就是趋于 0。



优化前后录屏效果,请点击查看:Lazada 容器深度优化之旅


录屏中优化前的是去年双十二期间页面,优化后使用的是 BDay 期间的页面,页面结构有变化,但加载的资源量级相当,从录屏效果看,优化后的体验,无论是预热还是预渲染比优化前都有质的提升。


对于预渲染,我们已经在后台完成了页面的加载和渲染操作,理论上应该是只需要合成上屏即可,但是录屏中有看到白屏过程,通过视频分帧可以看到,进场动画的时候确实是白屏状态:



通过实验,对比其他页面(如https://www.baidu.com) 命中预渲染的效果,发现它并没有白屏的过程。这中间的区别在于,会场页面上获取预渲染容器的同时,会发送一个上屏事件给前端,前端再去做一些软刷新等任务,这个软刷新任务会有业务 js 执行,导致阻塞了内核渲染流程,我们将上屏通知异步延迟后,中间白屏时间就少很多,录屏效果请点击查看:Lazada 容器深度优化之旅


在 7.7 大促期间对会场页面做测试,对比从点击到首屏的耗时,数据如下:



延迟上屏通知情况下的录屏耗时优化了 12%,用户体感会有较大提升。

SSR:唤端性能提升利器

预热/预渲染可极致优化用户从首页进入会场的体验问题,但是线上还存 20%-40%用户是通过唤端冷却直接进入到会场落地页,这种情况下,是没有足够时间来进行预热和预渲染的,所以提升唤端页面加载速度是一个亟需解决的问题。


从前端角度来分析,页面加载分为几个步骤:主文档加载、核心 js 加载、数据请求、页面渲染、上屏展示、图片请求展示,这几个步骤都是串行的,涉及到大量资源文件的网络传输和 js 解析执行。通过和前端同学讨论, SSR 是一个潜在的优化方案,将数据在服务端就召回并解析渲染成静态 HTML,那就只需要下载一个主文档就能进行上屏展示,加上图片请求展示,就只需要两轮数据交互,从客户端角度看,减少了 3 个数据交互环节,大大降低了数据传输量和连接请求次数。


会场 SSR 方案



SSR 与非 SSR 对比视频,点击查看:Lazada 容器深度优化之旅


SSR 渲染优势:


1、降低首屏资源数量和传输量级;


2、减少客户端解析执行业务 js 时间开销;


3、在客户端内采用 MTOP 方式请求,避开了安全保镖的问题和个性化推荐的问题。


在相同环境下(同手机、同页面、同 App、同网络环境)进行测试,发现端内打开页面场景使用 SSR 能够优化 15.2%的首屏时间,唤端场景使用 SSR 能够优化 28.1%的首屏时间。具体测试数据如下:


实测数据:



标准化

首屏时间标准化

一方面对齐集团的可交互首屏时间:前端完成渲染时间,部分业务域采用 UC T2 时间,优势是全部业务统一,缺点是非 UC 内核无法采集,一方面增加更接近用户体验的满屏首屏时间:首屏资源全部加载完成,包括 js、css 以及图片资源。

用户体感可量化——白屏检测

首屏时间可衡量大部分正常加载完页面的用户的体验,但还是有很多用户在首屏完成前就退出了页面,或者页面加载发生错误,这类 case 不能体现在首屏时间内。所以客户端增加了统一白屏检测能力,利用动态配置检查当前页面元素内容,用户离开页面时(包括切后台、退出、跳下一页),页面上是否真实存在内容监控用户可见的白屏状态。

预渲染和预热容器标准化

建立一套前端和客户端的标准对接协议,客户端通过配置平台按照配置,以及当前 app 内存水位加载对应的 ROCKET 容器,容器后台预加载主文档,业务资源,同时监控后台异常曝光等数据。前端对上报进行拦截,双端约定标准的渲染交互 jsapi,以及上屏更新通知等,客户端负责统一的内存卡口和渲染时机。

总结和展望

经过一年时间的深度优化,在 Android 平台,2021 D11 会场首屏时间比 2020 D11 提升 50%,IOS 首屏时间进入秒开时代;印尼机房真机录屏数据显示,预热场景下主会场首屏时间比竞品 Shopee 快 1 倍,非预热场景会场也比竞品 Shopee 快 24.8%。



展望未来,我们将继续从机型系统,内存分配,以及 Webview 内核的特性等多维度最大粒度的利用性能优化容器,最小的影响 app 的运行稳定性,同时深度优化 WebView 内核里图片等资源的加载失败和耗时等一些列问题,打造一个稳定且极致体验的 H5 容器。

我们招聘啦!

简历投至方式:haofei.yu@lazada.com


Lazada 创立于 2012 年,在东南亚印度尼西亚、马来西亚、菲律宾、新加坡、泰国和越南六国拥有超过 8000 万活跃消费者,且拥有该地区竞争力优势明显的物流和支付网络。 作为阿里巴巴东南亚旗舰电商平台,在利用阿里巴巴先进成熟的产品技术快速提升海外本地电商能力并帮助阿里生态迅速发展海外业务的同时,我们基于阿里已有平台抽取出一套国际化的全链路系统,从无线手机端到交易链路,从商家业务到大数据和推荐,打造全新的端到端国际电商操作系统。



在这里你不仅有机会了解商品、交易、会员、营销等核心平台,而且有机会接受极具前瞻性的海外电商业务的挑战,并且需要针对多国场景进行业务抽象和平台剥离,任务的新颖性和挑战性都是前所未有的。我们在招的岗位包含产品、架构师、开发、测试、前端等多种机会,业务涉及电商端到端的所有环节,只要你自信,有能力、有激情,一定可以找到吸引自己的新挑战。加入 Lazada,和我们一起激荡东南亚市场,共创国际化电商!


关注【阿里巴巴移动技术】微信公众号,每周 3 篇移动技术实践 &干货给你思考!

发布于: 刚刚阅读数: 2
用户头像

还未添加个人签名 2018.07.07 加入

阿里巴巴移动&终端技术官方账号。

评论

发布
暂无评论
Lazada 容器深度优化之旅