带你秒懂 SSR-服务端渲染

服务端渲染

定义

首先回顾一下 页面渲染的流程

1. 浏览器通过请求得到一个HTML文本
2. 渲染进程解析HTML文本，构建DOM树
3. 解析HTML的同时，如果遇到内联样式或者样式脚本，则下载并构建样式规则（stytle rules），若遇到JavaScript脚本，则会下载执行脚本。
4. DOM树和样式规则构建完成之后，渲染进程将两者合并成渲染树（render tree）
5. 渲染进程开始对渲染树进行布局，生成布局树（layout tree）
6. 渲染进程对布局树进行绘制，生成绘制记录
7. 渲染进程的对布局树进行分层，分别栅格化每一层，并得到合成帧
8. 渲染进程将合成帧信息发送给GPU进程显示到页面中
   

页面的渲染其实就是浏览器将HTML文本转化为页面帧的过程。而如今我们大部分WEB应用都是使用 JavaScript 框架（Vue、React、Angular）进行页面渲染的，也就是说，在执行 JavaScript 脚本的时候，HTML页面已经开始解析并且构建DOM树了，JavaScript 脚本只是动态的改变 DOM 树的结构，使得页面成为希望成为的样子，这种渲染方式叫动态渲染，也可以叫客户端渲染（CSR）。

服务端渲染（SSR）：服务端渲染就是在浏览器请求页面URL的时候，服务端将我们需要的HTML文本组装好，并返回给浏览器，这个HTML文本被浏览器解析之后，不需要经过 JavaScript 脚本的执行，即可直接构建出希望的 DOM 树并展示到页面中。这个服务端组装HTML的过程，叫做服务端渲染。

利弊

CSR：

利：网络传输数据量小、减少了服务器压力、前后端分离、局部刷新，无需每次请求完整页面、交互好可实现各种效果
弊：不利于SEO、爬虫看不到完整的程序源码、首屏渲染慢（渲染前需要下载一堆js和css等）

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

SSR：

利：首屏渲染快、利于SEO、可以生成缓存片段，生成静态化文件、节能（对比客户端渲染的耗电）
弊：用户体验较差、不容易维护，通常前端改了部分html或者css，后端也需要修改。

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

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

为什么使用SSR

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

得益于 React 等前端框架的发展，前后端分离，webpack 等编译工具的流行，以及 ajax 实现页面的局部刷新，使得我们现在的应用程序不再像曾经的应用程序一般需要从服务端获取页面，可以动态的修改局部的页面数据，避免页面频繁跳转影响用户体验等问题。也就是 SPA 越来越成为主流应用程序模型。 但是 SPA 的使用，除了以上提到的优势以外，必然会带来劣势。譬如：

1. 由于需要在页面加载之前就加载所有页面需要的 JavaScript 库，这使得首次打开页面所需要的时间比较久；
2. 需要研发专门针对于 SPA 的 Web 框架（各种具备 SSR 能力的框架，包括 Next.js 等）
3. 搜索引擎爬虫
4. 浏览器历史记录的问题（基于 pushState 的各种 router）

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

SSR怎么做

开箱即用的SSR脚手架

目前前端流行的三种技术栈 React, Vue 和 Angula ，已经孵化出对应的服务端渲染框架，开箱即用

• React: Next.js
• Vue: Nuxt.js
• Angula: Nest.js