服务端渲染（SSR)

导读

本文主要是从三个方面学习服务端渲染，内容整理自多个博客。

服务端渲染是什么？什么是服务端渲染？（服务端渲染的运行机制）

为什么使用服务端渲染？服务端渲染解决了什么问题？

什么情况下使用服务端渲染？（服务端渲染的应用实例与使用场景）

一、概念

首先，说到服务端渲染我们要先对渲染这个概念有一个大概的了解

渲染：就是将数据和模版组装成html

客户端渲染（CSR）VS服务端渲染(SSR)

那么，为了更好的理解服务端渲染，我们也很有必要去了解一下客户端渲染。将客户端渲染与服务端渲染同时进行学习理解。

1.客户端渲染

1.1概念

解释一：客户端渲染模式下，服务端把渲染的静态文件给到客户端，客户端拿到服务端发送过来的文件自己跑一遍js，根据JS运行结果，生成相应DOM，然后渲染给用户。

解释二：html 仅仅作为静态文件，客户端在请求时，服务端不做任何处理，直接以原文件的形式返回给客户端客户端，然后根据 html 上的 JavaScript，生成 DOM 插入 html。

延伸：前端渲染的方式起源于JavaScript的兴起，ajax的大热更是让前端渲染更加成熟，前端渲染真正意义上的实现了前后端分离，前端只专注于UI的开发，后端只专注于逻辑的开发，前后端交互只通过约定好的API来交互，后端提供json数据，前端循环json生成DOM插入到页面中去。

1.2.利弊

好处：网络传输数据量小、减少了服务器压力、前后端分离、局部刷新，无需每次请求完整页面、交互好可实现各种效果

坏处：不利于SEO、爬虫看不到完整的程序源码、首屏渲染慢（渲染前需要下载一堆js和css等）

2.服务端渲染

2.1.概念

解释一：服务端在返回 html 之前，在特定的区域，符号里用数据填充，再给客户端，客户端只负责解析 HTML 。

解释二：服务端渲染的模式下，当用户第一次请求页面时，由服务器把需要的组件或页面渲染成 HTML 字符串，然后把它返回给客户端。客户端拿到手的，是可以直接渲染然后呈现给用户的 HTML 内容，不需要为了生成 DOM 内容自己再去跑一遍 JS 代码。使用服务端渲染的网站，可以说是“所见即所得”，页面上呈现的内容，我们在 html 源文件里也能找到。

2.2.利弊

好处:首屏渲染快、利于SEO、可以生成缓存片段，生成静态化文件、节能（对比客户端渲染的耗电）

坏处:用户体验较差、不容易维护，通常前端改了部分html或者css，后端也需要修改。

3.对比

其实前后端的渲染本质是一样的，都是字符串的拼接，将数据渲染进一些固定格式的html代码中形成最终的html展示在用户页面上。因为字符串的拼接必然会损耗一些性能资源。如果在服务器端渲染，那么消耗的就是server端的性能。如果是在客户端渲染，常见的手段，比如是直接生成DOM插入到html 中，或者是使用一些前端的模板引擎等。他们初次渲染的原理大多是将原html中的数据标记（例如{{text}}）替换。

二、为什么使用服务端渲染，它解决的是什么问题

简单总结起来就是两点：

首屏加载快 相比于加载单页应用，我只需要加载当前页面的内容，而不需要像 React 或者 Vue 一样加载全部的 js 文件 SEO 优化 对于单页应用，搜索引擎并不能收录到 ajax 爬取数据之后然后再动态 js 渲染出来的页面。

为了更便于理解，下面几段话摘自掘金小册：

事实上，很多网站是出于效益的考虑才启用服务端渲染，性能倒是在其次。假设 A 网站页面中有一个关键字叫“前端性能优化”，这个关键字是 JS 代码跑过一遍后添加到 HTML 页面中的。那么客户端渲染模式下，我们在搜索引擎搜索这个关键字，是找不到 A 网站的——搜索引擎只会查找现成的内容，不会帮你跑 JS 代码。A 网站的运营方见此情形，感到很头大：搜索引擎搜不出来，用户找不到我们，谁还会用我的网站呢？为了把“现成的内容”拿给搜索引擎看，A 网站不得不启用服务端渲染。但性能在其次，不代表性能不重要。服务端渲染解决了一个非常关键的性能问题——首屏加载速度过慢。在客户端渲染模式下，我们除了加载 HTML，还要等渲染所需的这部分 JS 加载完，之后还得把这部分 JS 在浏览器上再跑一遍。这一切都是发生在用户点击了我们的链接之后的事情，在这个过程结束之前，用户始终见不到我们网页的庐山真面目，也就是说用户一直在等！相比之下，服务端渲染模式下，服务器给到客户端的已经是一个直接可以拿来呈现给用户的网页，中间环节早在服务端就帮我们做掉了，用户岂不“美滋滋”？

三、什么情况下使用服务端渲染？

通过服务端渲染的概念以及它的两个特点：首屏加载速度快、SEO优化。我们知道，服务端渲染其实就是由浏览器做的一些事情，我们放到了服务端去做，那么对于掘金、简书、CSDN、知乎等网站的搭建，这种在网上一搜搜出一堆东西的网站，SEO做的很好，应该多少都用到服务端渲染了吧？当然，做服务端渲染成本是高昂的。 vue全家桶或者react全家桶，都是推荐通过服务端渲染来实现路由的。服务端渲染并非完全之策（服务器稀少而宝贵），关于首屏渲染体验以及SEO的优化方案很多，在不使用服务端渲染这个操作下，我们最好的处理方式就是找寻替代优化方案。

关于在server端还是在browser端渲染的选择，更多的是要看业务场景。

===============================================

貌似几年之前从服务端生成html(如servlet)慢慢开始前后端分离，把一些渲染计算的步骤抛向前端来减轻服务端的压力。但是为啥现在又开始流行在服务端渲染html了呢？如vue全家桶或者react全家桶，都是推荐通过服务端渲染来实现路由的。单纯的是因为Virtual DOM的强大还是别的什么原因？

1.方应杭

这要从大概八年前说起，事情是这样的

1 一开始，html 就是后端渲染的。不过后端发现页面中的 js 好麻烦（虽然简单，但是坑多），于是让公司招聘专门写 js 的人，也就是前端
2 前端名义上是程序员，实际上就是在切图（CSS）和做特效(JS)，所以所有程序员中前端工资最低，职位也最低。所以前后端的鄙视链就出现了。
3 nodejs 和前端 mvc 的兴起让前端变得复杂起来，前端发现翻身的机会，于是全力支持这两种技术，造成本不该做成 spa 的网站也成了 spa。慢慢地前后端分离运动从大公司开始兴起，目的就是前端脱离后端的指指点点，独立发展。（表面上是为了「代码分离」，实际上是为了「人员分离」，也就是「前后端分家」，前端不再附属于后端团队）
4 spa 之后发现 seo 问题很大，而且首屏渲染速度贼慢，但是自己选的路再难走也要走下去，于是用 nodejs 在服务端渲染这一条路被看成是一条出路
5 其实这是第二个翻身的机会，如果 nodejs 服务器渲染成为主流，其实就相当于前端把后端的大部分工作给抢了，工资压过普通后端指日可待
6 然而结果是 nodejs 服务端渲染始终是小众，因为后端也没那么脆弱，java php rails 十多年沉淀的技术岂是你说推翻就推翻的，已经运行多年的项目又岂是容你随便用 nodejs 重写的，另一方面 golang 等技术的兴起也给 nodejs 不少压力。最终只有少部分前端特别强势的团队成功用上了 Node.js 做渲染（比如阿里的一些团队），大部分公司依然是用 PHP 渲染 HTML。
7 于是 nodejs 退一步说好好好我不抢你们的工作，我只做中间层（大部分工作就是渲染页面和调用后台接口），绝不越雷池。后端说算你识相。现在 nodejs 主要搞什么微服务，也是为了抢后端还没注意的市场。

你要看一门技术的发展主要应该看背后的人是谁，应用场景是哪些，最后才是技术细节。

nodejs 的火在中国早就烧过了，以后估计不会大火了，作为前端了解一下还是不错的，但是如果你是后端的话，看不看都无所谓，nodejs 跟其他后端开发框架差异并不大，单线程异步既是优点也是缺点，你就把它当做一种范式研究就好。

我是一个坚定的『前后端分家』反对者，前后代码可以分离，但是人员绝对不应该分离。前后端撕逼的事情在大公司天天都在发生，全都是因为前后是两个团队，利益不同。实际上前端推 nodejs 渲染就是在试图重新让前后端合成一体。

但是前端不能明说这件事，因为如果要把前后端部门合并，拆掉的肯定是前端部门。

合，则相当于自断前程。
不合，则永远没法解决seo和首屏加载慢的问题。
所以前端真的挺矛盾的。

JS 也有一个矛盾的地方，凡是浏览器上的框架（Vue React）都说自己能适应「复杂」场景，凡是 Node.js 上的框架（express fastify koa）都说自己是「轻量级」框架。

为啥？因为浏览器是 JS 的主战场，而且无敌手。而服务器上，JS 的经验积累还是太少了，搞企业级服务，Node.js 是敌不过 Java、PHP 的，没办法，发展得太晚了。所以目前只能搞「轻量级」咯。egg.js 号称是企业级 Node.js 框架，用过的人来评我就不评了。

有些大佬提出「大前端」的概念，意思是前端也要会后端，但是我们心还是前端的。

这不就是把以前的『前后端一个人做』换了个说法嘛。

反正你现在让后端去学前端，后端肯定是不愿意躺这浑水的。只能前端自己想办法咯。

想来想去就只有 Node.js 中间层做 HTML 渲染了。

当初是你要分开，分开就分开。
现在又要用kpi，把我唤回来。
但是后端kpi跟你前端kpi是不同的呀，所以没戏。

这些话也就我这种不在大厂的人敢说，在大厂的人根本不敢说，毕竟跟后端低头不见抬头见的。

最后告诉你一个小秘密。由于阿里 nodejs 用得还算多，却招不到人，所以从功利的角度出发，也许你学 nodejs 比学 java 更容易进阿里，毕竟阿里的 java 大神多如云，nodejs 大神却不多。

你说是吧。

但是从另外一个角度考虑，SEO 不友好的页面我是支持的。

如果你的页面是对 SEO 不友好的，那么百度的重要性就会被削弱。现在是移动互联网时代，大家在手机上几乎不用百度，都是直接点 App 点微信公众号的，SEO 不友好问题不大。首屏速度随着 5G 网络的普及也不会是问题了。

只要能让百度利益受损，我觉得 SPA 这事还是值得做的。服务端渲染还是直接免了吧，大家都不做 SEO 让百度倒闭就最好咯~（只是我的幻想而已，不要当真，我是百度的脑残黑，黑百度从来不需要理由）

感谢你看我说了这么多，不过说到最后，我也没给出啥结论，只是把我观察到的告诉你了。

你要不要学、要不要用服务器渲染HTML，都是需要你自己思考的事情。

还是那句话，我不喜欢说中庸的观点，我喜欢跟你说一个极端的观点，然后会有人用另一个极端的观点反驳我，他说服不了我，我也说服不了他，但是最终，你会得出自己的观点。

2.张强张耳朵

SSR的好处无非就2点

首屏渲染
SEO
然而这2点从来都很重要，可为啥之前有段时间不流行SSR呢？

往早了说，因为JS慢，网络慢，客户端本身也很慢，所以为了让功能可用且保证基本的流畅，前端就纯展示好了，交互非常少，渲染的活就交给server吧，因为当时前端很薄，所以很多前端的活都是后端兼的（那时候好像不怎么区分前后端，大家都是web开发工程师，按现在的说法叫全栈工程师）。

再后来，js快了，网络快了，客户端本身性能也高了，所以我们可以往客户端堆各种复杂的功能逻辑和交互，需求和工作量double后你让一个web开发工程师干2个人的活感觉身体要被掏空，所以一部分人选择了js专精，成为了专职前端。

对于前端，特别是互联网公司的前端来说，那UI的变更迭代的频率不知道要比业务逻辑本身高到哪里去了，产品动不动就要改UI改交互，这时候本身疲于需求变更的前端还要去求后端哥哥帮你上线新html模板，后端哥哥本身并不关心你html的dom怎么编排，还得每次都要人肉配合你改，真是苦不堪言+一脸嫌弃。

刚好这个时候智能手机火了，SEO感觉并不怎么重要，3G网络好像也还行，除了首次加载慢之外其他时间的渲染体验慢的并不明显，那么好了，还要啥SSR，大家都CSR好了，对于本身工作超饱和还找不到人的前端来说能按时写完功能，后端哥哥按约定完整交付接口不扯皮就已经不错了。任何应用都是最先保证功能的上线，优化什么的都是后话。从此，前后端开始分离。

再往后node有了，理论上来说，可以做到SSR和CSR都由前端维护，但对于历史悠久底子薄的JS生态圈来说，同构技术依然还是匮乏的，CSR和SSR分别维护两套代码怎么想都很恶心，干脆就还是继续CSR好了，直到以REACT为代表的渲染库出现，才使得前端步入同构时代，这时候SSR的成本比以前低了一倍，自然前端们又要开始跃跃欲试提出了新的KPI指标。也就是为什么现在又开始流行服务端渲染的原因。

其实整个历史的进程可以总结为以下脉络：

硬件/带宽/JS引擎的提速–>前端逻辑变的复杂–>前后端分工–>前后端分离–>html姓”前”–>如何渲染html要跟随前端技术栈的发展节拍–>等待前端相关技术成熟–>又流行SSR

3.nekocode

「又流行」感觉像是开历史的倒车，但其实并不是。以前是 Back-end（或者说 Full-stack）工程师负责 SSR，但是现在是 Front-end 工程师负责 SSR 了啊。在目前这个知识爆炸的年代，前后端的职能目前已经被分割得很开，大家都不愿意去淌对方那摊混水，而 Rendering 这事从语义上出发就属于 Front-end 的范畴，让 Back-end 去做这事，其实很多人是不愿意的。

回到问题本身，SSR 的「又流行」其实是 Front-end 社区工具栈不断进化的体现，也是历史的必然啊。几年前，SPA/CSR 概念的大热，让很多 Front-end 把他们当做万金油了。其实大家都知道 CSR 有着 SEO 的问题，而且页面渲染速度肯定比不上 SSR，但苦于社区中没有解决这个问题的工具栈，所以大家都对这个问题视而不见了。

而随着 Front-end 社区造轮子大潮的兴起，出现了一个很关键的历史转折点 —— Node.js 的出现。Node.js 赋予了 Front-end 在服务端执行 Js 的能力，有了这个环境和土壤，Front-end 工程师们终于可以考虑如何用 Js 来实现 SSR 了，于是 React 和 Vue 等主流框架后面开始支持 SSR 也就成了必然。

所以之前并不是不流行，而是因为前后端职能的分离，Back-end 不愿意做这事了，Front-end 没有条件去做。现在有条件了，自然又开始流行了。