2020年的双11,阿里需要什么样的渲染方案?

简介:

阿里妹导读:前端技术的"新陈代谢"是有目共睹的,新技术的不断发展也推动着前端应用场景的不断扩大,从 Web 、Weex 到 Node.js 再到 FaaS。我们在发展中看不变的部分,唯有追求更好的用户体验是端技术持续发展中不变的责任。在阿里,双 11 的复杂与广泛是全方面检验一个技术最直接有效的途径,今年的双 11 是全面使用由阿里巴巴开源的 Rax 的一年,本文将介绍 Rax 在用户体验上努力探索的方向。

1. 轻量化

更轻量意味着什么?JS 引擎的解析与编译的时间会将会直接减少。在我们历史的测试中,性能较低的一些 Android 设备上,初始 JS Bundle 的整体时间需要 300ms 或甚至更多,已是影响体验的非常大的一部分时间占比,所以在相同功能的前提下轻量化对业务优化体验是非常有效的手段之一。


图片来源:https://v8.dev/blog/background-compilation

年初我们启动了 Rax 1.0 的计划,能力上支持 Hooks,通过 Hooks 函数组件的写法本身能让业务代码更少,同时全新的 Rax 1.0 相比 Rax 上一个 0.6 的版本的内核代码从 57k 下降到了 17k,更轻量更快。

2. 自适应复合渲染(Adaptive Hydration Rendering)

Rax 的 Hydration 渲染最大的特点是自适应能力。什么是自适应能力?我们对比 React 的 Hydration 机制,我们可以在服务器端先提前生成了 HTML,然后执行 hydrate 在已有的 DOM 结构上绑定事件。过程中如果已有的 DOM 结构与当前 js bundle 输出的结构不一致,React 可以修正文本内容的差异,但不能保证在不匹配的情况下调整属性的差异。而且在 DOM 结构不匹配的时候 React 可能会有渲染两次的问题,此时反而使得渲染变的更慢。

在 Rax Hydration 的方案设计中,我们把兼容性与易用性作为一个重要设计目标,所以 Rax 会尽可能的复用已有节点,对任何有差异的地方进行修正。Rax 的修正大概有几类:文本修正、属性修正、节点修正,节点修正过程中如果遇到已经不存在的节点也会进行删除,保障渲染结果的正确性。

3. 快照渲染(Snapshot Rendering)

快照渲染在终端上不算一个新的概念,比如手淘的首页就有快照的机制,每次进入手淘会首先展示上一次的页面。Rax 快照渲染结合自适应复合渲染,其让快照渲染的体验变的更快更自然。

Rax 快照技术同样也需要有前置的历史状态,使用快照技术时我们可以把任何时候的页面状态存储为快照,然后下一次加载页面时首先从本地存储中加载上一次的页面快照。加载完快照后我们需要更新到最新的状态,在以往的技术方案中,当新页面完成后先置空为了体验设置的当前快照页面,然后再设置最新页面,这个过程有可能会触发页面的闪动。但通过 Rax 自适应复合渲染方式更新快照到最新的状态则可以避免此问题,这也是 Rax Hydration 把兼容性作为一个重要设计目标的带来的好处。

4. 服务端渲染(Server Side Rendering)

SSR 是在当下云+端趋势下我们非常看中的能力。所以 Rax 的服务端渲染在今年做了非常多尝试与突破,比如尝试通过 C++ 去实现一个完整的服务器端渲染,JS 与 C++ 间类型转换的效率导致性能还不如纯 JS 实现的方案,也考虑过能否把部分功能纯字符串操作的能力用 C++ 实现,这些尝试最终都没有符合我们的期望。

最终我们在工程上找到了解决方案,在编译时预先做了计算与字符串拼接,通过从下面的测试数据中了解到 Rax 的 SSR 性能是 React 的 8 倍,甚至已经超过了 xtpl,这也让我们有机会在合适的场景中用 jsx 去替换 xtpl。

-----------compare renderToString----------
React(16.12.0)#renderToString x 1,664 ops/sec ±1.40% (84 runs sampled)
Rax(1.0.13)#renderToString x 13,411 ops/sec ±1.05% (85 runs sampled)
Preact(10.0.5)#renderToString x 1,237 ops/sec ±2.18% (84 runs sampled)
Xtpl(3.4.2)#renderFile x 11,335 ops/sec ±8.17% (69 runs sampled)

The benchmark was run on:
   PLATFORM: darwin 17.5.0
   CPU: Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz
   SYSTEM MEMORY: 16GB
   NODE VERSION: v10.11.0

5. 客户端渲染(Native Side Rendering)

NSR 与 SSR 的工作原理非常接近,最大差别是 NSR 把 SSR 执行的过程放在了客户端上,不需要服务器就可享受到 SSR 的体验。NSR 与 CSR 渲染对比:

6. 个性化渲染

为什么会有个性化渲染?无论 CSR、SSR、NSR、SR 都有其适用的场景,当用户的网络足够好的情况下,可想而至无论哪一种渲染方式体验都还是不错的,但事实情况是怎么样的?我们通过这次双 11 端外体验数据可见一斑,不到 50% 的用户首屏可交互时间在 3s 内,90% 的用户在 0-7s 内,有 10% 的用户都在 7s 后:

无论低端机还是弱网络用户,都是我们需要重点关注的,而且逻辑上即是低端机又是弱网络的重合率可能很高。因此在不同的场景下选择合适的渲染方案变的非常有必要。比如在网络不佳并且在端内选择 NSR 方式渲染,网络不佳但在端外选择 SSR 方式渲染,设备性能不佳无论在端内还是端外选择 SSR, 所以我们认为未来的渲染方式都应是个性化的,不应是所有人都是一样的策略。

期望 2020 年的双 11 通过我们的努力让更多人的体验在 3s 内,更少的人在 7s 后,不再平均。

原文发布时间:2019-12-16
作者:元彦
本文来自阿里云合作伙伴“ 阿里技术”,了解相关信息可以关注“ 阿里技术”。

目录
相关文章
|
移动开发 前端开发 IDE
手淘双11最新实践:PopLayer弹层领域研发模式升级
近年来,各大APP内的弹层需求逐渐增多,以手机淘宝为例,日常的弹层上线频率为单端每月50次左右,而在大促期间可以达到240次以上。在手淘内,各类弹层业务都会通过PopLayer中间件的能力进行投放。但业务往往会遇到开发弹层难、慢、稳定性差的种种困难。对比于往年业务研发成本较高的现状,PopLayer在今年提出了【低研发搭投模式】来解决这类问题,形成一套快速搭建+可视化+多端多场景通用的解决方案,在日常与大促期间得到了广泛应用:
|
移动开发 缓存 前端开发
天猫汽车商详页的SSR改造实践
由于汽车业务的特殊性,天猫汽车基于 Rax 多页应用自建了商品详情的 H5 页面。自定义商详承载了众多业务能力和投放场景。随着业务的发展和页面承载内容的增多,开始出现白屏时间太长等体验问题。
541 0
天猫汽车商详页的SSR改造实践
|
移动开发 JavaScript 前端开发
面试题:渲染十万条数据解决方案
虚拟列表是最主流的解决方案,不渲染所有的数据,只渲染可视区域中的数据。
318 0
面试题:渲染十万条数据解决方案
|
测试技术 视频直播 双11
干货分享:细说双 11 直播背后的压测保障技术
阿里云 PTS 站在双 11 巨人的肩膀上,是阿里全链路压测的延伸。PTS 通过伸缩弹性,轻松发起用户百万级别的流量,免去机器、人力成本;PTS 对流量的控制,能够实时脉冲,精准控制; 是应对视频直播快速攀升的流量脉冲的优秀方案。
2593 3
干货分享:细说双 11 直播背后的压测保障技术
|
人工智能 搜索推荐
解决方案应用实例 |搭载“业务+数据”双中台,贝泰妮实现高速奔跑
贝泰妮联合阿里云,通过建立技术中台和数据中台、升级现有的信息管理系统和会员管理系统、引入新的管理模块,进一步加强内部管理能力和产业链上下游的控制能力,实现产供销、人财物的全链路数据化管理,从而实现业务上的前后台高效运营和管理上的内外部掌控,实现优化资源配置,做到精准营销,进一步提升公司的市场竞争力。
363 0
解决方案应用实例 |搭载“业务+数据”双中台,贝泰妮实现高速奔跑
|
Web App开发 设计模式 缓存
支撑双 11 星秀猫 5 亿用户的互动引擎 Eva.js 正式开源!
阿里巴巴历时2年自研开发的互动游戏引擎Eva.js正式开源,致力于让前端工程师更低成本的开发互动游戏,并已经在淘宝、天猫、支付宝、优酷、考拉、菜鸟、盒马等业务场景中使用。
支撑双 11 星秀猫 5 亿用户的互动引擎 Eva.js 正式开源!
|
双11 测试技术 数据库
深度 | 双11解决方案应用全揭秘
随着“ 双十一“全民购物狂欢节的到来,很多企业和电商公司也将迎来流量和营业额的高峰。但是,纵观往期双十一的交易数据,我们不难发现,双十一为商家带来流量曝光和推广的同时,高峰流量也对企业数据库处理等能力提出了更高的要求。企业本身如果不能保障流畅运行和企业内沟通效率,将会对企业造成巨大的经济损失。
4030 0
深度 | 双11解决方案应用全揭秘
|
移动开发 前端开发 IDE
手淘双11最新实践:PopLayer弹层领域业务研发模式升级
背景 近年来,各大APP内的弹层需求逐渐增多,以手机淘宝为例,日常的弹层上线频率为单端每月50次左右,而在大促期间可以达到240次以上。在手淘内,各类弹层业务都会通过PopLayer中间件的能力进行管理。但业务往往会遇到开发弹层难、慢、稳定性差的种种困难。对比于往年业务研发成本较高的现状,PopLayer在今年提出了【低研发搭建模式】来解决这类问题,形成一套快速搭建+可视化+多端多场景通用的解决
1395 0
手淘双11最新实践:PopLayer弹层领域业务研发模式升级
|
缓存 前端开发 JavaScript
双十一会场体验 SSR 优化 - 走向更复杂的渲染架构
今年(2020)我们在不改变现有架构,不改变业务的前提下,在会场上使用了 SSR 技术,将秒开率提高到了新的高度(82.6%);也观察到在用户体验得到优化的同时,业务指标如 UV 点击率等也有小幅的增长(视不同业务场景有不同的提升,最大可达 5%),带来了不错的业务价值。
双十一会场体验 SSR 优化 - 走向更复杂的渲染架构