关于服务端渲染（SSR）的问题总结

" 自从有了SSR，客户就会乐哈哈 "

01 前言

近几年服务端渲染的的技术却火了起来，关于历史上的问题我也不知道，所以就查阅一些资料来了解一下为什么会出现服务端渲染。从字面上的意思就是，服务端就可以渲染而不用浏览器渲染（CSR）。我们都知道请求服务器之后，会返回html代码，然后浏览器跑一遍JS和HTML等，形成DOM树渲染页面。而服务端渲染就免去了这一步骤，浏览器拿到返回的数据后直接渲染。

02 历史原因

关于历史原因，查看了两位阿里的博客。

其实一开始html代码就是由后端渲染的，但是后端程序员发现其中含有一些javascript代码，与他们自己写的不太一样而且难以维护。所以索性找几个人把代码分离出来专职维护，这就是前端的概念。相对于后端来说前端是没有什么技术含量的，只是切图和写js代码。

但是近几年来，前端的项目越来越庞大，涉及到很多方面的内容，特别是前端框架vue和react出来之后。所以写之前js的那些人员就开始探索前端的方面，逐渐形成前端开发的概念。这一方面就是前端代码变得越来越多，后端变得臃肿，所以后端就只返回数据给你，别的就不愿意去弄了。（前端卑微，任人鱼肉）

但是后来人们对网站体验的要求高了，产品经理就出来说你们的网站太卡了，用户体验不好。总归SSR出现的原因就是有两点：

• 首屏渲染慢
• 不利于搜索引擎（SEO）

首屏渲染慢

我们都知道当我们请求网页的html代码的时候，服务器原封不动地返回而且不带数据（生气），我们还要手动去请求一下通过各种方式渲染在页面上，放在现在也是慢了更何况是以前的时候。如果一旦遇到网络不好的时候，可能就会出现白屏持续一段时间等页面渲染，客户极有可能会烦躁。这就就是客户端渲染（CSR）。

但是如果采用服务端渲染就不会这样了，浏览器做的工作就是直接渲染，通俗一点来说就是你给我啥我就画啥，不用去构图设计等繁琐的操作（对应DOM解析和js解析）。而且这时候客户可以很快就看到页面长什么样，觉得这个网站不错，很流畅。

不利于搜索引擎

如果是采用客户端渲染的话，搜索引擎是找不到我们文章或者网站的内容的，那么如果你是一个主打社交或者广告的网站，那么这一方面就很重要了，一定要使用SSR渲染，这样网站才有流量和访问量，性能却在其次。

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

03 应用场景

针对上述两种情况，网站流量如果是比较大的话，首屏的加载一定要做好，因为这样可以给客户留下一个好的印象，只有用户体验好了别人才会愿意用你的产品。像一般的官网，或者电商网站等都可以使用SSR。

但是SSR利用的是服务器的资源，服务器资源是很昂贵的，所以并不是每个网站都适合做服务端渲染。vue全家桶或者react全家桶，都是推荐通过服务端渲染来实现路由的。

其实如果不使用SSR，之前我写过前端性能优化的文章，可以让首屏减少网络请求或者压缩请求等方式提高加载速度，并非一定要使用SSR，只是在有条件的情况之下可以使用SSR来提高加载速度。

04 小结

其实SSR的出现也是一个必然的局面，因为近年来Node.js的出现，使得JavaScript语言可以在服务端运行。前端工程师都愿意去使用js来实现SSR，更何况前端框架Vue都是用SSR来实现路由的。

作为一种解决方案，前端也应该去了解一下是怎么操作的，毕竟现在也说“大前端”的时代，每个人都是web开发者，就更应该去实践一下，顺便以后帮后端分担一下压力。

参考文章：

• 服务端渲染（SSR）
• 为什么现在又流行服务器端渲染html