SSR服务端渲染

斗转星移，忧伤轮回，过往成空，却绽放在我梦里最光亮的地方。一纸素笺，画满了流年的殇，一方浅墨，诉尽经年的梦。

SSR（服务端渲染）

• Server-Side Rendering(服务器端渲染)，在普通的 SPA 中，一般是将框架及网站页面代码发送到浏览器，然后在浏览器中生成和操作 DOM（这里也是第一次访问 SPA 网站在同等带宽及网络延迟下比传统的在后端生成 HTML 发送到浏览器要更慢的主要原因），但其实也可以将 SPA 应用打包到服务器上，在服务器上渲染出 HTML，发送到浏览器，这样的 HTML 页面还不具备交互能力，所以还需要与 SPA 框架配合，在浏览器上“混合”成可交互的应用程序。

SSR 流程

• 在服务器端渲染为组装好的 HTML 字符串，然后将它们直接发送到浏览器，最后需要将这些静态标记混合在客户端上完全可交互的应用程序。

• 由图可知需要通过 Webpack 打包生成两份 bundle 文件：

1. Client Bundle，给浏览器用。和纯 Vue 前端项目 Bundle 类似
2. Server Bundle，供服务端 SSR 使用，一个 json 文件

• 左侧 Source 部分就是我们所编写的源代码，所有代码有一个公共入口，就是 app.js，紧接着就是服务端的入口（entry-server.js）和客户端的入口（entry-client.js）。当完成所有源代码的编写之后，我们通过 webpack 的构建，打包出两个 bundle，分别是 server bundle 和 client bundle；当用户进行页面访问的时候，先是经过服务端的入口，将 vue 组件组装为 html 字符串，并混入客户端所访问的 html 模板中，最终就完成了整个 ssr 渲染的过程。

• SSR 能够在服务端先进行请求渲染，由于服务端进行请求数据的时延较小，能够快速拿到数据并且返回 HTML 代码。在客户端可以直接渲染数据而不需要花费一些请求数据的时间，这是服务端渲染的好处。返回内容 SSR 会比普通的 SPA 在 HTML 代码中多出首次渲染的结果，这样在初始化的时候直接将页面进行渲染，无需花费时间去请求数据再次渲染。SSR 并不是说只在服务端进行渲染，而是说 SSR 会比普通的客户端渲染多一次在服务端渲染。到浏览器这边，SSR 还是需要进行再次初始化 Vue，并且经过 beforeCreate、created、beforeMount、mounted 生命周期，但是在客户端 VNode 进行 patch 的时候，如果遇到服务端渲染过的节点，那么会跳过，所以在浏览器端渲染的时候可以减少一些工作，从而提高了页面体验。

客户端渲染与服务端渲染的区别

1. 传统的 SPA 模式

• Vue.js 构建的应用程序，默认情况下是有一个 html 模板页，然后通过 webpack 打包生成一堆 js、css 等等资源文件。然后塞到 index.html 中

用户输入 url 访问页面 -> 先得到一个 html 模板页 -> 然后通过异步请求服务端数据 -> 得到服务端的数据 -> 渲染成局部页面 -> 用户

2. SSR 模式

• 用户输入 url 访问页面 -> 服务端接收到请求 -> 将对应请求的数据渲染完一个网页 -> 返回给用户

服务端渲染的优缺点

• SSR 的优点

1. 更快的响应时间，不用等待所有的 JS 都下载完成，浏览器便能显示比较完整的页面了。
2. 更好的 SSR，我们可以将 SEO 的关键信息直接在后台就渲染成 HTML，而保证搜索引擎的爬虫都能爬取到关键数据。

• SSR 的缺点

1. 相对于仅仅需要提供静态文件的服务器，SSR 中使用的渲染程序自然会占用更多的 CPU 和内存资源
2. 一些常用的浏览器 API 可能无法正常使用，比如 window、docment 和 alert 等，如果使用的话需要对运行的环境加以判断
3. 开发调试会有一些麻烦，因为涉及了浏览器及服务器，对于 SPA 的一些组件的生命周期的管理会变得复杂
4. 可能会由于某些因素导致服务器端渲染的结果与浏览器端的结果不一致。

服务端渲染常用框架

• React 的 Next
• Vue.js 的 Nuxt