有必要使用服务器端渲染(SSR)吗？

亦凉 2022-09-10 05:07 214阅读 0赞

> 前几天在知乎看到了这个问题，刚好前阵子做过，就回答了一下。下面的是原回答。  
>

# 大厂技术 高级前端 Node进阶    #

点击上方 程序员成长指北，关注公众号

回复1，加入高级Node交流群

## 前言    ##

前阵子有搞了 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 来做，也经受住了各种大促的考验。

## 缺点 ##

当然了，服务端渲染也不应该滥用。

比如我们的内部后台管理系统就上了 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 文件，这个日期也会重新计算。

Node 社群

我组建了一个氛围特别好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你对Node.js学习感兴趣的话（后续有计划也可以），我们可以一起进行Node.js相关的交流、学习、共建。下方加 考拉 好友回复「Node」即可。

![ef253fa153e55b2172a49ce081e32587.png][]

**“分享、点赞、在看” 支持一波** ![1dae77f58c6079abd9d35d958d42590d.png][]

[ef253fa153e55b2172a49ce081e32587.png]: /images/20220829/eb3d20e307f04128833cf756b31c799d.png
[1dae77f58c6079abd9d35d958d42590d.png]: /images/20220829/b9f67706b06e42a1bb507e50b006a9ea.png

有必要使用服务器端渲染(SSR)吗？

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关深入浅出的讲解Nuxt框架的使用+SSR（服务器端渲染）

相关 [Nuxt.js]服务器端渲染（SSR）解决了什么问题

相关 Vue.js 服务端渲染（SSR）

相关有必要使用服务器端渲染(SSR)吗？

相关 SSR服务端渲染轻便型

相关 SSR（服务端渲染）

相关浅谈服务端渲染(SSR)

相关 Vue 服务端渲染（SSR）

相关七、SSR（服务端渲染）

相关浅谈服务端渲染(SSR)