作者:闲鱼技术——凌均
背景
「让每一个用户在最短的时间内看到页面上重要的内容」一直以来都是前端工程师们精益求精的方向。对于一个H5的源码页面,我们已经有了很多缩短首屏渲染时间的方法,比如数据预取,离线缓存。但在目前看来,由于数据预取和离线缓存都依赖客户端的能力,很多时候会给我们带来一些限制。比如用于增长业务的外投拉新页面,我们并不能知晓第三方APP是否具备这样的能力。再比如使用离线缓存能力,我们受制于命中率高低,以及缓存对APP性能带来的负面影响这样的问题。
服务端渲染,让最重要的内容和用户之前,只需要请求HTML DOC的时间,并且不依赖于客户端的能力,可以大大缩短用户看到页面首屏内容的时间。
方案要点
目前主流前端框架比如React,都已经提供了支持SSR的API,我们可以只用几行代码便将一段原本执行在客户端的绘制UI的逻辑转化为可以在Node层直出HTML的功能。在此基础之上,一个SSR技术方案应该同时做到以下几点要求:
页面首屏有效绘制(FMP)时间变短:从webview发出页面url请求,到用户看到首屏有效内容的时间真实变短。
应用稳定性高,运维成本低:保证由Node应用提供前端页面,尽可能跟已经非常成熟的「CDN缓存前端静态资源 + Java服务提供首屏数据」有相近的稳定性。并且Node服务一旦出现不可用的情况,页面能够自动降级到稳定的CSR(当下H5页面都在用的客户端渲染)模式,而不需要工程师手动执行降级。
低研发成本:采用SSR以后,前端工程师仍然只需要关心业务功能的实现,而无需为满足稳定性要求增加额外开发成本。
本文将重点介绍闲鱼的SSR方案围绕这三个要点进行了怎样的设计。
技术架构
先来看下闲鱼目前SSR架构整体的设计,再来单独聚焦每一个功能点的实现。
如图,架构设计分别考虑了用户正常访问的SSR链路(红色结点),以及SSR应用不可用时自动降级到的CSR链路(蓝色结点)。用CSR链路作为SSR失败时的降级兜底方案,是保证SSR方案稳定性的关键点。
SSR链路
基于serverless的node应用
随着阿里Serverless生态建设的不断完善,前端同学开发Node应用,已经不需要像面对传统Node应用一样,花费太多时间来运维Node应用。我们可以凭借「函