BBC 发现其网站加载时间每增加一秒,用户便会流失 10%。为提高页面的秒开率,我们不断探索着优化策略,仅仅在浏览器领域下的优化已经满足不了我们的极致要求,开始往服务端方向不断探索。本文将讨论业务接入SSR的几个问题:
- SSR究竟适合哪些业务?
- 接入SSR后,性能带来了哪些提升?
- 业务接入SSR有哪些成本?
SSR适合哪些业务?
SSR是将页面渲染的过程放在了服务端去执行,对于性能较低的低端机或者网络情况不佳的时候,不需要等待js下载执行就可以直接渲染页面。再加上通常我们会在node层去做首屏接口的聚合,对于用户来说,是可以更快得看到完整渲染的首页,没有抖动的渲染过程,有着更好的用户体验。
总的来说,SSR的优劣势是:
优势
- 有利于首屏渲染
- 有利于SEO
- 对于中低端机型,有较大的性能提升
劣势:
- 页面白屏时间会较长,渲染完成到真正可交互还需要一段时间
- 服务端压力较大,会大量占用服务端cpu资源
- 开发要求高,学习成本相对较高
对于以上的优劣势,再结合本次优化的页面具有以下几个特点,决定采用SSR的渲染方案进行优化:
多渠道投放,分享场景多,引流新用户:业务方会和各种渠道合作,将页面外投来获客。作为需要快速留住用户的落地页,对首屏渲染性能会有着较高的要求。
中低端设备占比高:中低端用户占比 60-70%。低端机主要的性能瓶颈在于代码执行和渲染时间长。
结果对比
,时长00:07
左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的优势反而得不到发挥。但是在天猫优品大促的场景下,用户低端机的平均数据并没有得到很大提升,我们分析有如下几个原因:
- 我们的页面是一个新页面,目前比较简单,js大小只有97.1 kB,没能体现出SSR请求资源方面的优越性
- 在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工程的基本配置。
- pages 目录:和普通 CSR 工程一样,承载着页面的渲染逻辑,开发模式和 CSR 应用一样,只需保持代码同时可在 Node 环境下运行即可。
- 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
- 选择性:结合数据,我们发现中低端机更适合SSR,根据机型来选择不同的渲染方式会更科学,并且也会减少服务器压力。
- 流式渲染:当服务端计算时间过长或者网络环境不好时,用户会看到比较长的白屏时间;可以通过 ER 先返回一段 HTML 流给用户,让用户可见骨架屏,减少白屏时间。
- 静态 SSR 、动态更新:在页面没有个性化要求的时候,可以走静态化SSR,将html缓存到cdn上,来达到性能更优的目标。在个性化要求较高的时候,可以使用静态SSR和动态更新的方案,来优化静态链路。
团队介绍
我们是大淘宝技术创新业务前端团队,目前负责消费电子、家装家居、汽车的线上线下零售新模式的探索,面向淘内淘外,提供商家、门店、消费者最佳用户体验。团队沉淀了一定的XR、3D、2D渲染引擎创新体验技术,同时面向全栈领域团队探索了 Serverless 云端研发模式,在消费者前台,通过端智能等手段提升消费者效率,同样面向工程领域,在跨端、前端工程化、中后台微前端都有一些沉淀。如果你是一位充满想象的终端极客,欢迎你的加入,通过自己的技术想法去改变创新业务的终端表达。目前急需校招生小伙伴,简历请投递至: murong.zr@alibaba-inc.com。
¤ 拓展阅读 ¤