服务端渲染相关概念

slide.pptx
随着前端技术栈和工具链的迭代成熟，前端工程化、模块化也已成为了当下的主流技术方案，在这波前端技术浪潮中，涌现了诸如 React、Vue、Angular 等基于客户端渲染的前端框架，这类框架所构建的单页应用（SPA）具有用户体验好、开发效率高、渲染性能好、可维护性高等优点。但也也有一些很大的缺陷，其中主要涉及到以下两点：

• 首屏加载时间过长
• 不利于 SEO

为了解决这两个缺陷，业界借鉴了传统的服务端渲染方案，提出了同构渲染的方式。

这种方式简而言之就是：

• 通过服务端渲染首屏直出，解决 SPA 应用首屏渲染慢以及不利于 SEO 问题
• 通过客户端渲染接管页面内容交互得到更好的用户体验

这种方式我们通常称之为现代化的服务端渲染，也叫同构渲染；

同理，这种方式构建的应用称之为服务端渲染应用或者是同构应用。

为了让大家更好的理解服务端渲染应用，我们这里需要了解一些相关概念：

• 什么是渲染
• 传统的服务端渲染
• 客户端渲染
• 现代化的服务端渲染（也叫同构渲染）

什么是渲染

例如对于我们前端开发者来说最常见的一种场景就是：请求后端接口数据，然后将数据通过模板绑定语法绑定到页面中，最终呈现给用户。

数据：

{
  "message": "Hello World"
}

模板：

<h1>{{ message }}</h1>

渲染（数据 + 模板）结果：

<h1>Hello World</h1>

把（数据 + 模板）拼接到一起的这事儿就是我们这里所指的渲染。

传统的 Web 应用

最早期，Web 页面渲染都是在服务端完成的，即服务端运行过程中将所需的数据结合页面模板渲染为 HTML，响应给客户端浏览器。所以浏览器呈现出来的是直接包含内容的页面。

工作流程： 这种方式的代表性技术有：ASP、PHP、JSP 等，再到后来的一些相对高级一点的服务端框架配合一些模板引擎。

无论如何这种方式对于没有玩儿过后端开发的同学来说可能会比较陌生，所以下面通过我们前端同学比较熟悉的 Node.js 来了解一下这种方式。

见代码目录中的《01-传统的服务端渲染》。

这也就是最早的网页渲染方式，也就是动态网站的核心工作步骤。在这样的一个工作过程中，因为页面中的内容不是固定的，它有一些动态的内容。

在今天看来，这种渲染模式是不合理或者说不先进的。因为在当下这种网页越来越复杂的情况下，这种模式存在很多明显的不足：

• 应用的前后端部分完全耦合在一起，在前后端协同开发方面会有非常大的阻力；
• 前端没有足够的发挥空间，无法充分利用现在前端生态下的一些更优秀的方案；
• 由于内容都是在服务端动态生成的，所以服务端的压力较大；
• 相比目前流行的 SPA 应用来说，用户体验一般；

但是不得不说，在网页应用并不复杂的情况下，这种方式也是可取的。

单页面应用

传统的服务端渲染有很多问题，但是这些问题随着客户端 Ajax 技术的普及得到了有效的解决，Ajax 技术可以使得客户端动态获取数据变为可能，也就是说原本服务端渲染这件事儿也可以拿到客户端做了。

下面是基于客户端渲染的 SPA 应用的基本工作流程。 下面我们以一个 Vue.js 创建的单页面应用为例来了解一下这种方式的渲染过程。

见代码目录中的《02-客户端渲染》。

通过这个示例可以了解到我们就可以把【数据处理】和【页码渲染】这两件事儿分开了，也就是【后端】负责数据处理，【前端】负责页面渲染，这种分离模式极大的提高了开发效率和可维护性。

而且这样一来，【前端】更为独立，也不再受限制于【后端】，它可以选择任意的技术方案或框架来处理页面渲染。

客户端渲染的优势：

• 前后端分离开发
• 更好的用户体验
• 减轻了服务端压力
• …

但是这种模式下，也会存在一些明显的不足，其中最主要的就是：

• 首屏渲染慢：因为 HTML 中没有内容，必须等到 JavaScript 加载并执行完成才能呈现页面内容。
• SEO 问题：同样因为 HTML 中没有内容，所以对于目前的搜索引擎爬虫来说，页面中没有任何有用的信息，自然无法提取关键词，进行索引了。

传统 Web 应用 VS 单页应用

何时使用传统 Web 应用程序：

• 应用程序的客户端要求简单，甚至要求只读。
• 应用程序需在不支持 JavaScript 的浏览器中工作。
• 团队不熟悉 JavaScript 或 TypeScript 开发技术。

何时使用 SPA：

• 应用程序必须公开具有许多功能的丰富用户界面。
• 团队熟悉 JavaScript、TypeScript 等开发。
• 应用程序已为其他（内部或公共）客户端公开 API。

此外，SPA 框架还需要更强的体系结构和安全专业知识。 相较于传统 Web 应用程序，SPA 框架需要进行频繁的更新和使用新框架，因此改动更大。 相较于传统 Web 应用，SPA 应用程序在配置自动化生成和部署过程以及利用部署选项（如容器）方面的难度更大。

使用 SPA 方法改进用户体验时必须权衡这些注意事项。

同构应用

为了解决单页面应用首屏渲染慢以及不利于 SEO 的问题，业界借鉴了传统的服务端直出 HTML 方案，提出在服务器端执行前端框架（React/Vue/Angular）代码生成网页内容，然后将渲染好的网页内容返回给客户端，客户端只需要负责展示就可以了； 当然不仅仅如此，为了获得更好的用户体验以及页面内容交互，同时会在客户端将来自服务端渲染的内容激活为一个 SPA 应用，也就是说之后的页面内容交互都是通过客户端渲染处理。

1. 客户端发起请求
2. 服务端渲染首屏内容 + 生成客户端 SPA 相关资源
3. 服务端将生成的首屏资源发送给客户端
4. 客户端直接展示服务端渲染好的首屏内容
5. 首屏中的 SPA 相关资源执行之后会激活客户端应用
6. 之后客户端所有的交互都由客户端 SPA 处理

这种方式我们通常称之为现代化的服务端渲染，也叫同构渲染；

同理，这种方式构建的应用称之为服务端渲染应用或者是同构应用。

isomorphic web apps（同构应用）：isomorphic/universal，基于 react、vue 框架，客户端渲染和服务器端渲染的结合，在服务器端执行一次，用于实现服务器端渲染（首屏直出），在客户端再执行一次，用于接管页面交互，核心解决 SEO 和首屏渲染慢的问题。

实现原理：

实现同构应用的相关技术：

• React 生态中的 Next.js
• Vue 生态中的 Nuxt.js
• Angular 生态中的 Angular Universal

下面通过基于 Vue.js 生态的 Nuxt.js 体验同构应用。

见代码目录/03-同构渲染。

同构渲染应用的优缺点：

• 优点
  • 首屏渲染速度快
  • 有利于 SEO
  • 现有的技术生态
• 缺点
  • 开发成本高
  • 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境。
  • 更多的服务器端负载。在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic) 下使用，请准备相应的服务器负载，并明智地采用缓存策略

在对你的应用程序使用服务器端渲染 (SSR) 之前，你应该问的第一个问题是，是否真的需要它。这主要取决于内容到达时间 (time-to-content) 对应用程序的重要程度。

• 例如，如果你正在构建一个内部仪表盘，初始加载时的额外几百毫秒并不重要，这种情况下去使用服务器端渲染 (SSR) 将是一个小题大作之举。
• 然而，内容到达时间 (time-to-content) 要求是绝对关键的指标，在这种情况下，服务器端渲染 (SSR) 可以帮助你实现最佳的初始加载性能。

事实上，很多网站是出于效益的考虑才启用服务端渲染，性能倒是在其次。 假设 A 网站页面中有一个关键字叫“前端性能优化”，这个关键字是 JS 代码跑过一遍后添加到 HTML 页面中的。那么客户端渲染模式下，我们在搜索引擎搜索这个关键字，是找不到 A 网站的——搜索引擎只会查找现成的内容，不会帮你跑 JS 代码。A 网站的运营方见此情形，感到很头大：搜索引擎搜不出来，用户找不到我们，谁还会用我的网站呢？为了把“现成的内容”拿给搜索引擎看，A 网站不得不启用服务端渲染。 但性能在其次，不代表性能不重要。

参考链接

• https://www.pianshen.com/article/25451556312/