服务端渲染基础

1、概述

随着前端技术栈和工具链的迭代成熟，前端工程化、模块化也已成为了当下的主流技术方案，在这波前端技术浪潮中，涌现了诸如 React、Vue、Angular 等基于客户端渲染的前端框架，这类框架所构建的单页应用（SPA）具有用户体验好、渲染性能好、可维护性高等优点。但也也有一些很大的缺陷，其中主要涉及到以下两点：
（1）首屏加载时间过长
与传统服务端渲染直接获取服务端渲染好的 HTML 不同，单页应用使用 JavaScript 在客户端生成 HTML来呈现内容，用户需要等待客户端 JS 解析执行完成才能看到页面，这就使得首屏加载时间变长，从而影响用户体验。
（2）不利于 SEO
当搜索引擎爬取网站 HTML 文件时，单页应用的 HTML 没有内容，因为他它需要通过客户端 JavaScript解析执行才能生成网页内容，而目前的主流的搜索引擎对于这一部分内容的抓取还不是很好。为了解决这两个缺陷，业界借鉴了传统的服务端直出 HTML 方案，提出在服务器端执行前端框架（React/Vue/Angular）代码生成网页内容，然后将渲染好的网页内容返回给客户端，客户端只需要负责展示就可以了；如下面的顺序图所示：

借鉴了传统的服务端渲染

当然不仅仅如此，为了获得更好的用户体验，同时会在客户端将来自服务端渲染的内容激活为一个 SPA应用，也就是说之后的页面内容交互都是通过客户端渲染处理。如下顺序图所示：

客户端激活为一个SPA应用

这种方式简而言之就是：

通过服务端渲染首屏直出，解决首屏渲染慢以及不利于 SEO 问题。
通过客户端渲染接管页面内容交互得到更好的用户体验。
这种方式我们通常称之为现代化的服务端渲染，也叫同构渲染，所谓的同构指的就是服务端构建渲染 + 客户端构建渲染。同理，这种方式构建的应用称之为服务端渲染应用或者是同构应用。

为了让大家更好的理解服务端渲染应用，这里需要了解一些渲染相关概念，这些概念主要涉及到以下几点：

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

2、什么是渲染

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

什么是渲染

渲染本质其实就是字符串的解析替换，实现方式有很多种；但是我们这里要关注的并不是如何渲染，而是在哪里渲染的问题？

3、传统的服务端渲染

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

传统的服务端渲染工作流程顺序图：

传统的服务端渲染工作流程

在上面的流程中，最重要的就是第四步，即渲染是在服务端进行的。

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

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

首先需要安装一下依赖：

# express用于创建 http 服务
npm i express
# 安装服务端模板引擎依赖
npm i art-template express-art-template

再来分析一下服务端需要完成的事：

基本的 Web 服务
使用模板引擎
渲染一个页面

最后根据分析完成服务端的代码：

/index.js

const express = require('express')
const fs = require('fs')
const template = require('art-template')

const app = express()

app.get('/', (req, res) => {
  // 1. 获取页面模板，第二参数为编码格式，默认读取为 Buffer 二进制流
  const templateStr = fs.readFileSync('./index.html', 'utf-8')

  // 2. 获取数据
  const data = JSON.parse(fs.readFileSync('./data.json', 'utf-8'))

  // 3. 渲染：数据 + 模板 = 最终结果
  const html = template.render(templateStr, data)

  // 4. 把渲染结果发送给客户端
  res.send(html)
})

app.listen(3000, () => console.log('running...'))

/index.html内容：

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>传统的服务端渲染</title>
</head>
<body>
  <h1>传统的服务端渲染</h1>
  <h2>{{ title }}</h2>
  <ul>
    <!-- art-template 模板引擎遍历语法，通过$value获取遍历项 -->
    {{ each posts }}
    <li>{{ $value.title }}</li>
    {{ /each }}
  </ul>
</body>
</html>

/data.json相关数据：

{
  "posts": [
    {
      "id": 1,
      "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
      "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
    },
    {
      "id": 2,
      "title": "qui est esse",
      "body": "est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla"
    },
    {
      "id": 3,
      "title": "ea molestias quasi exercitationem repellat qui ipsa sit aut",
      "body": "et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut ad\nvoluptatem doloribus vel accusantium quis pariatur\nmolestiae porro eius odio et labore et velit aut"
    },
    {
      "id": 4,
      "title": "eum et est occaecati",
      "body": "ullam et saepe reiciendis voluptatem adipisci\nsit amet autem assumenda provident rerum culpa\nquis hic commodi nesciunt rem tenetur doloremque ipsam iure\nquis sunt voluptatem rerum illo velit"
    },
    {
      "id": 5,
      "title": "nesciunt quas odio",
      "body": "repudiandae veniam quaerat sunt sed\nalias aut fugiat sit autem sed est\nvoluptatem omnis possimus esse voluptatibus quis\nest aut tenetur dolor neque"
    }
  ],
  "title": "hello world"
}

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

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

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

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

4、客户端渲染

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

下面的顺序图展示了基于客户端渲染的 SPA 应用的基本工作流程：

基于客户端渲染的 SPA 应用的基本工作流程

注意第二步中空白的HTML不是什么都没有，只是没有实质内容，但会存在一些引导性js脚本。

其中最重要的一点是服务端只负责进行数据的处理，页面的渲染则交给客户端即前后端分离。

可以了解到，我们把【数据处理】和【页面渲染】这两件事儿分开了，也就是【后端】负责数据处理，【前端】负责页面渲染，这种分离模式极大的提高了开发效率和可维护性。而且这样一来，【前端】更为独立，也不再受限制于【后端】，它可以选择任意的技术方案或框架来处理页面渲染。

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

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

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

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

5、现代化的服务端渲染

现代化的服务端渲染，即同构渲染，也就是【服务端渲染】 + 【客户端渲染】。可能听起来有点晕，这个概念我们待会儿就会了解到。

现代化的服务端渲染/同构渲染的渲染顺序图：

现代化的服务端渲染/同构渲染的渲染顺序图

6、通过 Nuxt 体验同构渲染

首先创建一个叫ssr的文件夹并初始化npm：

mkdir ssr
cd ssr
npm init -y

然后安装nuxt：

npm install nuxt

接着安装axios：

npm install axios

最后修改一下package.json：

{
  "name": "ssr",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "dev": "nuxi dev"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

之后就可以使用npm run dev去运行nuxt了。

接着创建ssr/pages/index.vue：

<script setup>
import axios from 'axios'
// 获取数据，注意这里的端口号是 nuxt 运行时的端口号。
const { data } = await axios({
      method: 'GET',
      url: 'http://localhost:3000/data.json'
    })
console.log(data)
</script>

<template>
  <div id="app">
    <h2>{{ data.title }}</h2>
    <ul>
      <li
        v-for="item in data.posts"
        :key="item.id"
      >{{ item.title }}</li>
    </ul>
  </div>
</template>

<style>
</style>

创建ssr/pages/about.vue：

<template>
  <div>
    <h1>About</h1>
  </div>
</template>

<script>
export default {
  name: 'AboutPage'
}
</script>

<style>
</style>

创建ssr/layouts/default.vue作为layouts：

<template>
  <div>
    <!-- 路由出口 -->
    <ul>
      <li>
        <!-- 类似于 router-link，用于单页面应用导航 -->
        <nuxt-link to="/">Home</nuxt-link>
      </li>
      <li>
        <nuxt-link to="/about">About</nuxt-link>
      </li>
    </ul>

    <!-- 子页面出口 -->
    <nuxt />
  </div>
</template>

<script>
export default {

}
</script>

<style>
</style>

创建ssr/public/data.json

{
  "posts": [
    {
      "id": 1,
      "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
      "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
    },
    {
      "id": 2,
      "title": "qui est esse",
      "body": "est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla"
    },
    {
      "id": 3,
      "title": "ea molestias quasi exercitationem repellat qui ipsa sit aut",
      "body": "et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut ad\nvoluptatem doloribus vel accusantium quis pariatur\nmolestiae porro eius odio et labore et velit aut"
    },
    {
      "id": 4,
      "title": "eum et est occaecati",
      "body": "ullam et saepe reiciendis voluptatem adipisci\nsit amet autem assumenda provident rerum culpa\nquis hic commodi nesciunt rem tenetur doloremque ipsam iure\nquis sunt voluptatem rerum illo velit"
    },
    {
      "id": 5,
      "title": "nesciunt quas odio",
      "body": "repudiandae veniam quaerat sunt sed\nalias aut fugiat sit autem sed est\nvoluptatem omnis possimus esse voluptatibus quis\nest aut tenetur dolor neque"
    }
  ],
  "title": "hello world"
}

注意其中的文件夹与文件名都是固定的，详情参看：nuxt.com/docs/guide/… 。

之后运行npm run dev即可通过nuxt来体验一下什么是同构渲染的应用了。

接下来我们分析一下同构渲染的优缺点：

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

同构渲染示意图：

同构渲染示意图

相关技术：

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

实现原理：

同构渲染实现原理

7、同构渲染的问题

同构渲染也存在一些问题：

开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数 (lifecycle hook) 中使用；一些外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应用程序中运行；不能在服务端渲染期间操作 DOM...
涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序(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 网站不得不启用服务端渲染。但性能在其次，不代表性能不重要。

一文带你了解什么是服务端渲染（SSR）