我正在参与掘金创作者训练营第4期，点击了解活动详情，一起学习吧！

概述

React、Vue、Angular 等基于客户端渲染的前端框架，这类框架所构建的单页应用（SPA）具有用户体验好、渲染性能好、可维护性高等优点。但也也有一些很大的缺陷，其中主要涉及到以下两点：

1. 首屏加载时间过长

与传统服务端渲染直接获取服务端渲染好的 HTML 不同，单页应用使用 JavaScript 在客户端生成 HTML来呈现内容，用户需要等待客户端 JS 解析执行完成才能看到页面，这就使得首屏加载时间变长，从而影响用户体验。

2.不利于 SEO

当搜索引擎爬取网站 HTML 文件时，单页应用的 HTML 没有内容，因为他它需要通过客户端 JavaScript 解析执行才能生成网页内容，而目前的主流的搜索引擎对于这一部分内容的抓取还不是很好。为了解决这两个缺陷，业界借鉴了传统的服务端直出 HTML 方案，提出在服务器端执行前端框架（React/Vue/Angular）代码生成网页内容，然后将渲染好的网页内容返回给客户端，客户端只需要负责展示就可以了；

这里为了让大家更好的理解服务端渲染应用，我们要从以下这几个小点出发，一点点进行学习

• 渲染是什么？本质是什么？
• 传统的服务端渲染优势在哪？，不足在哪里
• 客户端渲染
• 现代化的服务端渲染（同构渲染）

什么是渲染

1. 浏览器会解析三个东西【1】：

• 一个是HTML/SVG/XHTML，事实上，Webkit有三个C++的类对应这三类文档。解析这三种文件会产生一个DOM Tree。

• CSS，解析CSS会产生CSS规则树。

• Javascript，脚本，主要是通过DOM API和CSSOM API来操作DOM Tree和CSS Rule Tree.

2. 解析完成后，浏览器引擎会通过DOM Tree 和 CSS Rule Tree 来构造 Rendering Tree。注意：Rendering Tree 渲染树并不等同于DOM树，因为一些像Header或display:none的东西就没必要放在渲染树中了。 CSS 的 Rule Tree主要是为了完成匹配并把CSS Rule附加上Rendering Tree上的每个Element。也就是DOM结点。也就是所谓的Frame。然后，计算每个Frame（也就是每个Element）的位置，这又叫layout和reflow过程。

3. 最后通过调用操作系统Native GUI的API绘制。

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

渲染本质其实就是字符串的解析替换，实现方式有很多种

传统的服务端渲染

服务端运行过程中将所需的数据结合页面模板渲染为HTML，响应给客户端浏览器。

实现原理：

1. 客户端发送请求给服务器
2. 服务器查询数据库，使用视图、模板引擎等拼接成html字符串，返回给客户端
3. 客户端渲染html

优缺点【2】

• 缺点
  • 应用的前后端部分完全耦合在一起，前端写完页面样式和结构后，再将页面交给后端套数据，最后再一起联调。
  • 前端的发布过于依赖于后端的同学；
  • 前端没有足够的发挥空间，无法充分利用现在前端生态下的一些更优秀的方案；（能不能让前端又可以摸鱼事情还不用做就更好了）
  • 由于内容都是在服务端动态生成的，所以服务端的压力较大；
  • 相比目前流行的 SPA 应用来说，用户体验一般； 优点
  • 页面渲染速度快
  • 同时 SEO 效果好。

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

客户端渲染

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

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

优缺点

• 优点
  • 节省服务端资源,js动态生成页面,部署简单
  • 局部刷新,无需每次都请求完整的页面,体验更好
  • 前后端分离
• 缺点
  • 首屏渲染慢,渲染前需要下载css和js资源
  • 无法进行SEO 当然主要还是前后端分离了，让前端工作性质上了一个档次！

感谢客户端渲染！

对于客户端渲染的 SPA 应用的问题有没有解决方案呢？

• 服务端渲染，严格来说是现代化的服务端渲染，也叫同构渲染

现代化的服务端渲染

我们在上一小节了解到 SPA 应用有两个非常明显的问题：

• 首屏渲染慢
• 不利于 SEO 但是我们在复习过了服务端渲染之后，就会想到将客户端渲染的工作放到服务端渲染，这个问题不就解决了吗？

那当然不是用老版本的服务端渲染了啦，这就引出了同构渲染，也就是【服务端渲染】 + 【客户端渲染】。

分析优缺点：

• 优点：

  • 首屏渲染速度快
  • 有利于 SEO

• 缺点：

  • 开发成本高。
  • 涉及构建设置和部署的更多要求。
  • server 更加大量占用 CPU 资源 (CPU-intensive – CPU 密集)

相关技术：

• React 生态中的 Next.js

  • 没用过，不知道坑点哈哈哈哈哈

• Vue 生态中的 Nuxt.js

  这就不得不说我在这里遇到的一些坑壁的事情了！

  • 服务端必须是 node.js 或者专门跑个 node.js 来支持；
  • document 对象找不到，在 node 环境不存在；
  • 数据预获取时，组件尚未实例化（无法使用 this ）

• Angular 生态中的 Angular Universal

  • 没用过，不知道坑点哈哈哈哈哈

总结

在对你的应用程序使用服务器端渲染 (SSR) 之前，你应该问的第一个问题是： 是否真的需要它。

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

事实上，很多网站是出于效益的考虑才启用服务端渲染，性能倒是在其次。

• 假设 A 网站页面中有一个关键字叫“前端性能优化”，这个关键字是 JS 代码跑过一遍后添加到 HTML 页面中的。

• 那么客户端渲染模式下，我们在搜索引擎搜索这个关键字，是找不到 A 网站的——搜索引擎只会查找现成的内容，不会帮你跑 JS 代码。
• A网站的运营方见此情形，感到很头大：搜索引擎搜不出来，用户找不到我们，谁还会用我的网站呢？

为了把“现成的内容”拿给搜索引擎看，A 网站不得不启用服务端渲染。

说白了，一切实用性为主，业务为辅，一切为炫技而做的事情说白了，都是要贴近团队、产品的！

• 参考：

  • 【1】在前端开发中，页面渲染指什么
  • 【2】腾讯新闻抢金达人活动node同构直出渲染方案的总结

• 推荐：

  • 【1】传统Web应用案例(采用服务端渲染)
  • 【2】这就是客户端渲染胜利的原因
  • 【3】浅谈服务端渲染和客户端渲染
  • 【4】彻底理解服务端渲染 – SSR原理 #30 强烈推荐！掘友强烈推荐