SSR 介绍
什么是SSR
服务端拼接生成HTML内容，浏览器直接显示服务端返回的HTML，完成渲染之后再加载客户端JS。
对比CSR
CSR是客户端渲染，区别于SSR，不依赖服务端。
SSR和CSR之间，还可以根据实施的差异分成5种方案，下图是以前收藏的一张5种对比图
- SSR：完全由服务端即时渲染，适合HTML是动态的场景
- SSG：由服务端预先渲染，适合HTML是静态的场景
- SSR with hydration：当使用了Virtual DOM框架时，就需要将服务端渲染的DOM与框架进行水合，由框架接管后续渲染，是当前的流行方案
- CSR with prerendering：骨架屏，不需要服务端，既可以是临时使用后续替换的占位元素，也可以是待水合的Virtual DOM框架结构。它和SSG的区别是，客户端接管后会继续CSR
- CSR：HTML基本没有内容，只负责加载JS、CSS，是最简单方便维护的方案
SSR、SSG、SSR with hydration 是进一步细分，但它们离不开服务端，都属于服务端渲染。
优点
- SEO友好
搜索引擎优化，方便搜索引擎爬虫根据HTML就能提取页面内容。但是现代爬虫也会自我优化，一定程度上支持CSR。另一方面，即使CSR也可以通过骨架屏来部分满足爬虫需求。
如果SEO对网站很重要，而且主要的SEO信息要通过异步接口获取的，那么SSR是必要的。 - FCP快
优化网页性能指标，快速呈现内容给用户。尤其是内容是动态的，SSR不像CSR要等接口返回才填充数据。 - 可访问性好
SSR不依赖客户端环境，在禁用了JS的设备上也能渲染页面。
缺点
- 服务器成本
依赖服务端，有服务器成本，对于大流量应用有不小的开支。考虑成本，SSR能不用就不用。 - TTI慢 尽管页面很快显示出来，但直到JS运行前页面都无法交互。SSR不会降低TTI（可交互时间），反而因为SSR相比CSR多了更多HTML内容，会增加网络传输大小，水合过程也有JS计算成本。
- 开发维护成本
SSR在CSR的基础上，增加了生成HTML的开发维护成本。
这里有几种选型方案：- 同构（服务端、客户端共用一套代码渲染，在客户端水合）
- 异构（服务端、客户端各自渲染，相互独立，重合内容复用或替换）
什么时候用SSR
通常使用SSR是弊大于利的。但业务优先，SSR作为备选方案，是否使用取决于业务需要。
- 适合可见内容取决于用户身份的应用
此时HTML完全是动态的，SSR可以不向用户返回无用的HTML内容。
CSR则需要一次接口身份判断再按需加载内容。 - 适合强内容，弱交互的应用
发挥SSR的优缺点。 - 高性能指标、多后端的应用
FCP快。SSR本身也能作为一种BFF（Back for front）应用，聚合接口数据后展示。
如果没有高性能指标要求，那么单独的BFF应用更佳。