01 引言

随着前端系统的越发复杂，前端的性能也受到越来越多的重视。Google 也不断在推进新的性能相关指标，从原先的 Performance API 中的指标逐步演进成用户性能体验相关的指标。

对于用户而言，First Paint、First Meaningful Paint 和 TTI 这几个指标可以直接影响到用户体验。关于前端性能优化有非常多的最佳实践可以参考，这篇文章会重点介绍前端渲染的方案及其优劣。

02 CSR vs SSR

CSR：Client Side Rendering

浏览器(Client)渲染顾名思义就是所有的页面渲染、逻辑处理、页面路由、接口请求均是在浏览器中发生。其实，现代主流的前端框架均是这种渲染方式，这种渲染方式的好处在于实现了前后端架构分离，利于前后端职责分离，并且能够首次渲染迅速有效减少白屏时间。同时，CSR可以通过在打包编译阶段进行预渲染或者骨架屏生成，可以进一步提升首次渲染的用户体验。

但是由于和服务端会有多次交互（获取静态资源、获取数据），同时依赖浏览器进行渲染，在移动设备尤其是低配设备上，首屏时间和完全可交互时间是比较长的。

SSR：Server Side Rendering

服务端渲染则是在服务端完成页面的渲染，在服务端完成页面模板、数据填充、页面渲染，然后将完整的 HTML 内容返回给到浏览器。由于所有的渲染工作都在服务端完成，因此网站的首屏时间和 TTI都会表现比较好。

但是，渲染需要在服务端完成，并不能很好进行前后端职责分离，而且白屏时间也会比较长，同时，对于服务端的负载要求也会比较高。

基于 Hydration 的 SSR 和 CSR 融合

SSR 和 CSR 均有各自的优点和缺点，因此，业界提出前后端渲染同构的方案来整合SSR和CSR。

整个页面的加载和刷新是通过服务端渲染来实现，在渲染生成的 HTML 中内嵌 JavaScript 和数据内容。通过这样的实现，可以达到和 SSR 相同的首屏时间，并且基于 Hybration，可以生成前端的虚拟Dom，避免前端触发二次渲染。

SSR 和 CSR 的页面渲染体验对比：

SSR 和 CSR 不同阶段优劣对比：

Serverless SSR

前端使用 SSR 进行渲染同构有一个非常明显的缺点：服务资源消耗和运维。通常情况下，同构 SSR 会采用 Node 服务，需要固定的服务器资源，并且服务器的运维对于前端同学也提出了很高的要求。

随着 Serverless 技术的出现，这些问题似乎得到了很好的解决。Serverless 基于触发器调用云端部署的函数，然后调用后端服务。

对于前端同学而言，仅仅只需要实现云端函数的实现，对于服务器的运维管理完全不用关心，同时服务器会实现自动弹性伸缩，有效节省了机器资源。

当然，Serverless 并不是万能的，服务器的冷启动目前依旧还是一个非常大的问题。

SSR 在性能收益上是完胜 CSR，配合 Serverless，SSR 的开发成本仅仅比 CSR 有略微的提高，因此，从收益成本来看，Serverless SSR 已经有了较大的优势，可能会成为未来的趋势。

03 NSR

UC 浏览器在新闻 feed 流页面加载中采用了 NSR（Native Side Rendering），首先在列表页中加载离线页面模板，通过 Ajax 预加载页面数据，通过 Native 渲染生成 Html 数据并且缓存在客户端。

NSR 本质是分布式 SSR，将服务器的渲染工作放在了一个个独立的移动设备中，实现了页面的预加载，同时又不会增加额外的服务器压力。

04 ESR

ESR – Edge Side Rendering，方案的核心思想是，借助边缘计算的能力，将静态内容与动态内容以流式的方式，先后返回给用户。cdn 节点相比于 server，距离用户更近，有着更短的网络延时。在 cdn 节点上，将可缓存的页面静态部分，先快速返回给用户，同时在 cdn 节点上发起动态部分内容请求，并将动态内容在静态部分的响应流后，继续返回给用户。

目前在 alicdn 上对主搜页面做了一个 demo （https://edge-routine.m.alibaba.com/）, 下面是在不同网络（通过 charles 的 network throttle 配置限速）情况下，与原始页面的加载对比：

不限速（wifi）