闲鱼源码页面SSR最佳实践

背景

「让每一个用户在最短的时间内看到页面上重要的内容」一直以来都是前端工程师们精益求精的方向。对于一个H5的源码页面，我们已经有了很多缩短首屏渲染时间的方法，比如数据预取，离线缓存。但在目前看来，由于数据预取和离线缓存都依赖客户端的能力，很多时候会给我们带来一些限制。比如用于增长业务的外投拉新页面，我们并不能知晓第三方APP是否具备这样的能力。再比如使用离线缓存能力，我们受制于命中率高低，以及缓存对APP性能带来的负面影响这样的问题。

服务端渲染，让最重要的内容和用户之前，只需要请求HTML DOC的时间，并且不依赖于客户端的能力，可以大大缩短用户看到页面首屏内容的时间。

方案要点

目前主流前端框架比如React，都已经提供了支持SSR的API，我们可以只用几行代码便将一段原本执行在客户端的绘制UI的逻辑转化为可以在Node层直出HTML的功能。在此基础之上，一个SSR技术方案应该同时做到以下几点要求：

• 页面首屏有效绘制（FMP）时间变短：从webview发出页面url请求，到用户看到首屏有效内容的时间真实变短。
  

• 应用稳定性高，运维成本低：保证由Node应用提供前端页面，尽可能跟已经非常成熟的「CDN缓存前端静态资源 + Java服务提供首屏数据」有相近的稳定性。并且Node服务一旦出现不可用的情况，页面能够自动降级到稳定的CSR（当下H5页面都在用的客户端渲染）模式，而不需要工程师手动执行降级。
  

• 低研发成本：采用SSR以后，前端工程师仍然只需要关心业务功能的实现，而无需为满足稳定性要求增加额外开发成本。

本文将重点介绍闲鱼的SSR方案围绕这三个要点进行了怎样的设计。

技术架构

先来看下闲鱼目前SSR架构整体的设计，再来单独聚焦每一个功能点的实现。