SSR在天猫优品大促会场的探索实践

BBC 发现其网站加载时间每增加一秒，用户便会流失 10%。为提高页面的秒开率，我们不断探索着优化策略，仅仅在浏览器领域下的优化已经满足不了我们的极致要求，开始往服务端方向不断探索。本文将讨论业务接入SSR的几个问题：

1. SSR究竟适合哪些业务？

2. 接入SSR后，性能带来了哪些提升？

3. 业务接入SSR有哪些成本？

SSR适合哪些业务？

SSR是将页面渲染的过程放在了服务端去执行，对于性能较低的低端机或者网络情况不佳的时候，不需要等待js下载执行就可以直接渲染页面。再加上通常我们会在node层去做首屏接口的聚合，对于用户来说，是可以更快得看到完整渲染的首页，没有抖动的渲染过程，有着更好的用户体验。



总的来说，SSR的优劣势是：

优势

1. 有利于首屏渲染

2. 有利于SEO

3. 对于中低端机型，有较大的性能提升

劣势：

1. 页面白屏时间会较长，渲染完成到真正可交互还需要一段时间

2. 服务端压力较大，会大量占用服务端cpu资源

3. 开发要求高，学习成本相对较高

对于以上的优劣势，再结合本次优化的页面具有以下几个特点，决定采用SSR的渲染方案进行优化：

多渠道投放，分享场景多，引流新用户：业务方会和各种渠道合作，将页面外投来获客。作为需要快速留住用户的落地页，对首屏渲染性能会有着较高的要求。

中低端设备占比高：中低端用户占比 60-70%。低端机主要的性能瓶颈在于代码执行和渲染时间长。



结果对比

左csr，右ssr；浏览器访问，高速3G网络下；

jsTracker  SFSP （2022-10-28 00:00:00 —— 2022-11-02 00:00:00）
渲染方式	低端机	中端机	高端机
CSR	1648.02ms	1543.64ms	1257.86ms（-211ms）
SSR	1545.39ms（-103ms）	1531.11ms	1468.47ms

用户平均数据

TMQ首屏时间
渲染方式	低端机（ vivo vivo Y67  ）	高端机（Realme X50）
CSR	2510 ms	1640ms
SSR	1420 ms（-1090ms，-43%）	880ms（-760ms，-46%）

单个机型数据

从用户数据对比上来看，低端机性能有所提升，但是高端机反而有降低。这个是符合预期的，因为对于高端机来说，特别是IOS，端侧的性能反而是优于服务器的，SSR的优势反而得不到发挥。但是在天猫优品大促的场景下，用户低端机的平均数据并没有得到很大提升，我们分析有如下几个原因：

1. 我们的页面是一个新页面，目前比较简单，js大小只有97.1 kB，没能体现出SSR请求资源方面的优越性

2. 在CSR和SSR的场景下，我们都使用了首屏的聚合接口。唯一的差别就是渲染方式的差别，在目前手机性能普遍提升的大环境下，就导致数据差异并不大。



so，从这次实践中，可以得出SSR在一些资源较大，较复杂，首屏接口较多的页面，能发挥出更大的优势。

从tmq的单个机型的性能对比中，我们还是可喜的发现数据有不错的提升。so，在之后，我们可以针对某些低性能机型，进行相应的SSR优化。

SSR选型

ICE3.0和RAX的SSR方案对比：

方案	工程化	SSR能力	优势	劣势
Rax	1、支持一体化，在一个工程中完成页面逻辑和渲染服务的维护，开发、调试、发布更加简单 2、前后端同构，同一份代码既可以进行 CSR 渲染，也可以进行 SSR 渲染 2、低运维成本，无需维护独立 Node 应用，部署即获得 SSR 页面	可降级/自动降级/个性化/自定义日志	稳定、建设时间较久	rax体系难以应用到一些最新react社区能力
ICE 3.0			1、react体系，能力更丰富 2、提供流式渲染能力	现有的业务组件都是rax体系，需要兼容和踩坑

因为项目对时间和稳定性都有比较高的要求，所以最后我们还是选择了Rax体系。在稳定性的保障上，Serverless 平台提供了基础的灰度、回滚、监控的能力，Rax提供了自动降级能力（当SSR链路出错时，会自动降级到CSR）。



目前，我们上线以来，通过监控观测，SSR的降级率保持在4%以下，服务还是很稳定的。

开发成本

会有很多同学关心，如果将原有的rax应用直接切换到SSR一体化应用中来，成本会有多大？

在SSR的工程中，和CSR工程还是比较类似的，增加了apis目录用于承载渲染函数，还有一些FaaS工程的基本配置。

1. pages 目录：和普通 CSR 工程一样，承载着页面的渲染逻辑，开发模式和 CSR 应用一样，只需保持代码同时可在 Node 环境下运行即可。

2. apis 目录：是面向 FaaS 函数的，在 render 目录下，提供了 SSR 渲染函数的入口，其主要工作是调用 Pages 的产物进行渲染。通常，业务开发需要介入的部分是，进行业务数据接口的调用，来准备用于渲染的业务数据。

.
├── build.json
├── f.yml                                    # 函数平台配置
├── jest.config.js
├── midway.config.ts
├── package.json
├── src
│   ├── apis                                 # 函数源码
│   │   ├── configuration.ts
│   │   ├── lambda                           # 接口
│   │   │   ├── index.test.ts
│   │   │   └── index.ts
│   │   ├── render                           # 渲染函数
│   │   │   └── index                                    
│   │   │       └── index.ts
│   │   └── typings
│   │       └── context.d.ts
│   ├── app.json
│   ├── app.ts
│   ├── components/
│   ├── document/
│   ├── pages/                                          
│   └── typings.d.ts
└── tsconfig.json

从CSR到SSR的主要工作就是在于聚合首屏接口，改变一下之前获取数据的方式，同时兼容一下SSR和CSR两种渲染方式，保证稳定性。

在前端的工程中，难免会有方法或者库会使用到浏览器环境才有的变量，如 location、navigator等。为保证 SSR 和 CSR 编码的一致性，需要提供在服务器端模拟浏览器环境的能力。

还需注意的是Server 端的渲染过程是一个同步的操作，其本质是将 JSX 组件渲染为 HTML 字符串。因此，setState、hooks 这类异步更新状态的方法以及组件的 生命周期 方法，在 Server 端不会被执行。

在开发过程中，应尽量避免将用于渲染初始页面的数据通过异步的方式来更新。





总结思考

▐  SSR并不是适合所有业务

要结合业务场景和项目状况来综合考虑性能优化的手段，SSR并不是一个万能神方，还是需要对症下药。



▐  更好的SSR

1. 选择性：结合数据，我们发现中低端机更适合SSR，根据机型来选择不同的渲染方式会更科学，并且也会减少服务器压力。

2. 流式渲染：当服务端计算时间过长或者网络环境不好时，用户会看到比较长的白屏时间；可以通过 ER 先返回一段 HTML 流给用户，让用户可见骨架屏，减少白屏时间。

3. 静态 SSR 、动态更新：在页面没有个性化要求的时候，可以走静态化SSR，将html缓存到cdn上，来达到性能更优的目标。在个性化要求较高的时候，可以使用静态SSR和动态更新的方案，来优化静态链路。

团队介绍

我们是大淘宝技术创新业务前端团队，目前负责消费电子、家装家居、汽车的线上线下零售新模式的探索，面向淘内淘外，提供商家、门店、消费者最佳用户体验。团队沉淀了一定的XR、3D、2D渲染引擎创新体验技术，同时面向全栈领域团队探索了 Serverless 云端研发模式，在消费者前台，通过端智能等手段提升消费者效率，同样面向工程领域，在跨端、前端工程化、中后台微前端都有一些沉淀。如果你是一位充满想象的终端极客，欢迎你的加入，通过自己的技术想法去改变创新业务的终端表达。目前急需校招生小伙伴，简历请投递至: [e-mail]。

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法