有必要使用服务端渲染（SSR）吗？
yinguangyao opened this issue · comments
前几天在知乎看到了这个问题，刚好前阵子做过，就回答了一下。下面的是原回答。
前言
前阵子有搞了 React 服务端渲染的项目，是否应该用这个主要还是看场景吧。
比较适用于大家常说的 SEO 和首屏渲染这些，一般都是 toc 的业务才会需要用到。
同构
现代框架的服务端渲染和 jsp、php 这些还是有不少区别的。因为 nextjs 和 nuxtjs 这种不仅仅是服务端渲染，它们还是同构框架。
什么是同构呢？就是一份代码既可以跑在浏览器端，也可以跑在服务端。这得益于 NodeJS 在服务端的流行。
传统 jsp、php、django 这些服务端渲染框架都是返回 html 字符串，类似于传统的 MPA 多页面模式。所以切换页面的时候就会刷新，重新请求 css 和 js 文件，用户体验比较差。
而现在流行的前端开发模式都是 SPA 单页面，基于 H5 的 History 来实现切换页面无刷新，这样可以带来更好的用户体验。
所以 nextjs 和 nuxtjs 不仅支持服务端渲染，还支持 SPA，常用的是对首页进行服务端渲染，其他页面依然保持 SPA 的无刷新访问模式。
我们这边就有使用 Django 来编写的页面，维护起来很痛苦。因为无法说清楚哪些是前端负责的，哪些是后端负责的。所以为了维护这个，前端和后端都去要学习 Python 和 Django，大大提高了维护成本。
实际应用场景的话，我们这里有几种场景就比较适合用服务端渲染。
支持 Post 请求
一个是重构的 h5 页面，项目以前是新加坡团队用 Python + Django 写的，所以有些页面是第三方网站 Post 提交表单打开的。
我们重构后的 H5 页面都挂在腾讯云 CDN 上面，不支持用 Post 打开的。为什么不改成 Get 呢？因为这是以前他们协定的，然后银行都是爸爸，他们不会为了我们去改协议的。
页面功能都是比较简单的，所以为了赶上重构的时间线，当时旁边的小伙伴用 Express + EJS 实现了一版，只支持 ES5 的语法。
后续需求经历几次变更，想在原来的页面上加功能都比较麻烦。比如我想实现 JS Bridge，我只能用 microbundle 把现有的 npm 包打成一个 umd 文件，然后用 script 标签引入。
动态渲染标题
前阵子遇到了另一个需求，我需要为多家银行实现同样的 H5 页面，功能基本上都是一样的，但 App 头部需要展示不同银行的名字。
在我们 AirPay App 里面，客户端在打开 webview 的时候会去读取我们 HTML 里面的 title，将其设置为原生头部的标题。
如果我在代码里面使用 document.title 的方式动态设置就不会生效，只能通过 JS Bridge 来动态设置头部。
但这个页面不仅会提供给 AirPay 使用，还会提供給 Shopee 使用，需要兼容两套 JS Bridge，有点儿得不偿失。
但如果使用服务端直出的形式，就可以在服务端直接判断好需要渲染的标题，设置到 HTML 的 title 里面。这就是另一种适合的业务场景了。
所以在之前项目基础上添加了 React 服务端渲染的功能，支持用 React 开发同构应用。这里也没有用 Next，只是自己实现的一套同构。
大致实现思路是用 isomorphic-style-loader 和 universal-router 来处理样式和路由的同构，服务端获取到数据后输出到 window._INITIAL_STATE__ 里面，在浏览器获取这个初始化数据实现数据同构的。
同时也保留了原来的 EJS 模板，都是基于 Express 路由分发的，既可以渲染用 EJS 渲染，也可以用 React 服务端直出。
一期的这个页面是挂在腾讯云 CDN 上面的，二期使用了服务端渲染，可以明显感觉到加载速度变快了很多，毕竟以前还是会展示一个 loading 图。
在进程守护方面，整个部门的 Node 服务都是用大佬写的 Node Agent 来做，也经受住了各种大促的考验。
性能测试
这次测试是用 h5-pay 和 h5-ssr 里面的 mbanking 做的一个对比，打开浏览器隐身模式，disable cache 之后，测试了弱网和正常网速下的比较。
h5-ssr 是我们这边用于服务端渲染的项目，静态资源挂载到了腾讯云的 CDN 上面。h5-pay 是我们这边的一个静态项目，html 和静态资源都挂载到了 CDN 上面。
指标
页面加载速度上面的差距是显而易见的。这里使用了浏览器自带的 Performance API 来做一个对比，具体就是加载完页面后执行 performance.getEntites() 来查看各项指标。
这次主要对比的是 DNS 解析、TCP 连接、请求响应、DOM 解析等等。
DNS 解析
首先我们可以看到 DNS 解析时间，一般是 domainLookupEnd - domainLookupStart，很显然 h5pay 的解析速度很慢，达到了惊人的 94ms，这个域名是我们关联在腾讯云上面的。
反而 SSR 的 DNS 解析只花了 3ms，这里是否可以说明我们自己解析速度远远快过腾讯云的解析速度呢？
TCP 连接
TCP 连接这个两者差距不大，一般是 connectEnd - conntectStart 来查看，SSR 耗时大概 40ms，h5pay 耗时 60ms。
首次请求响应
对比完 DNS 之后，我们再来对比一下首次请求的响应耗时。这个首次请求是指我们在浏览器输入 URL 之后，等浏览器三次握手建立 TCP 连接之后，请求获取我们的 HTML 文件的耗时。
这里使用 responseEnd - requestStart 来比较耗时。需要注意的是，走 SSR 的页面一般都需要在服务端请求接口，获取数据后将数据一起返回给浏览器，所以理论上 SSR 耗时肯定比非 SSR 更多。
这里可以看到差距非常大，h5-ssr 只花了 102 ms，但 h5-pay 耗时居然到了 390ms，不是说好的 SSR 耗时会更多吗！
那么只有一种解释，就是腾讯云 CDN 实在过于垃跨了，请求响应速度实在是太慢了，以至于別人顺便请求了一个接口都只花了100ms，你反而花了快400ms。
DOM 解析
因为 SSR 是已经在服务端渲染好了数据，所以它返回的 DOM 就是全量的。但 h5-pay 不一样，它是单页应用，大部分逻辑都在 JS 里面，反而 HTML 本身很小，只是个空壳。所以这里必然是 h5-pay 解析比 SSR 更快。
我们用 domInteractive - responseEnd 来比较一下，发现 SSR 解析 DOM 耗时达到了 800ms，而 h5-pay 耗时只有 340ms，这是 h5-pay 的一次重大胜利。
整体耗时
最上面的 duration 可以看到整体耗时，SSR 耗时在 1000ms 左右，而 h5-pay 耗时在 5817 ms，当然这个数据不是非常准确的，因为 5817ms 算上了加载完所有的静态资源，而 SSR 只要 DOM 解析完就算加载完成了。
如果是从 DNS 解析到 DOM 渲染耗时来看，h5-pay 更胜一筹，但这个并没有什么用。因为 SSR 这个耗时就已经把整个页面直出了，而 h5-pay 还需要去下载 JS 文件，然后调接口获取数据，再进行一次重绘。
如果只算 H5-PAY 的关键资源加载以及调接口、重绘的耗时，大概在 3s 左右，而走了 SSR 的相同页面仅仅花了 1s，性能差距大概 2倍。
缺点
当然了，服务端渲染也不应该滥用。
比如我们的内部后台管理系统就上了 Nuxt，现在每次本地构建要花10分钟，非常影响开发效率。
Nuxt 功能还是非常强大的，比如会根据路由动态拆分构建文件、鼠标放到 Nuxt-link 路由组件上面就会预加载 JS 文件等等。
但实际上带来的收益几乎为零，因为我们不需要 SEO，也不需要提高首屏加载速度。
几乎组里面每个人都有尝试用各种手段去优化构建，但效果不是很明显。直到最近开始做微前端拆分，才曲线解决这个问题。
除此之外，服务端渲染在写法上也和客户端渲染有一些区别，容易导致 bug。
比如下面在 Vuex 的 state 文件里面的这段代码：
const date = moment().format('YYYY-MM-DD')
export default () => ({
date
})打开页面的时候，时间应该展示的是今天。哪怕页面放置刚好跨天了，打开再刷新也应该是当天时间。
但在 Nuxt 里面，这个展示的日期就是你服务启动那天的日期，不管你怎么刷新，它永远不会变化。
因为 Nuxt 初始化的时候会把这些数据存到 store 里面，后续再怎么刷新，这个文件也不会在服务端重新加载，因为模块会被 Node 缓存起来，所以日期就不会更新。
但在客户端渲染里面，由于页面刷新会导致浏览器端重新加载 JS 文件，这个日期也会重新计算。