Vue.js 框架源码与进阶 - 服务端渲染基础

最新推荐文章于 2025-03-21 14:13:00 发布

每天内卷一点点

最新推荐文章于 2025-03-21 14:13:00 发布

阅读量841

点赞数 2

分类专栏： Vue.js 框架源码与进阶文章标签： vue.js javascript 前端

本文链接：https://blog.youkuaiyun.com/weixin_41071974/article/details/125697745

版权

Vue.js 框架源码与进阶专栏收录该内容

16 篇文章

订阅专栏

本文详细探讨了服务端渲染（SSR）与客户端渲染（CSR）的优缺点，包括首屏加载速度、SEO优化及用户体验。针对现代Web应用的需求，提出了同构渲染（Isomorphic Rendering）作为解决方案，结合SSR与CSR的优势，实现快速首屏渲染和良好的SEO。文章通过Node.js和Nuxt.js的例子介绍了服务端渲染的实现，并讨论了同构渲染的挑战与适用场景。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、概述

随着前端技术栈和工具链的迭代成熟，前端工程化、模块化也已成为了当下的主流技术方案，在这波前端技术浪潮中，涌现了诸如 React、Vue、Angular 等基于客户端渲染的前端框架，这类框架所构建的单页应用（SPA）具有用户体验好、渲染性能好、可维护性高等优点

但也也有一些很大的缺陷，其中主要涉及到以下两点：

首屏加载时间过长

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

不利于 SEO

当搜索引擎爬取网站 HTML 文件时，单页应用的 HTML 没有内容，因为他它需要通过客户端 JavaScript 解析执行才能生成网页内容，而目前的主流的搜索引擎对于这一部分内容的抓取还不是很好

为了解决这两个缺陷，业界借鉴了传统的服务端直出 HTML 方案，提出在服务器端执行前端框架（React/Vue/Angular）代码生成网页内容，然后将渲染好的网页内容返回给客户端，客户端只需要负责展示就可以了

在这里插入图片描述
当然不仅仅如此，为了获得更好的用户体验，同时会在客户端将来自服务端渲染的内容激活为一个 SPA 应用，也就是说之后的页面内容交互都是通过客户端渲染处理

在这里插入图片描述
这种方式简而言之就是：

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

这种方式我们通常称之为现代化的服务端渲染，也叫同构渲染，所谓的同构指的就是服务端构建渲染 + 客户端构建渲染。同理，这种方式构建的应用称之为服务端渲染应用或者是同构应用

二、什么是渲染

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

例如对于我们前端开发者来说最常见的一种场景就是：请求后端接口数据，然后将数据通过模板绑定语法绑定到页面中，最终呈现给用户。这个过程就是我们这里所指的渲染
渲染本质其实就是字符串的解析替换，实现方式有很多种。但是我们这里要关注的并不是如何渲染，而是在哪里渲染的问题

在这里插入图片描述

三、传统的服务端渲染

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

工作流程：
在这里插入图片描述

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

下面通过 Node.js 来了解一下这种方式：

安装依赖：

# 创建 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')
// 创建一个 express 实例
const app = express()

// 添加一个路由，当其以get请求网站根路径时触发
app.get('/', (req, res) => {
  // 1. 获取页面模版
  // readFile 是一个异步方法，readFileSync 是一个同步方法
  // 默认得到的是二进制数据，为了得到字符串可以指定 utf-8 编码
  const templateStr = fs.readFileSync('./index.html', 'utf-8')

  // 2. 得到数据
  // 默认得到的是字符串类型，使用JSON.parse()转换成数据对象
  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">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>传统的服务端渲染</title>
</head>
<body>
  <h1>传统的服务端渲染示例</h1>
  <h2>{{ title }}</h2>
  <ul>
    {{ each posts }}
    <li>{{ $value.title }}</li>
    {{ /each }}
  </ul>   
</body>
</html>

nodemon index.js

在这里插入图片描述

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

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

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

四、客户端渲染

4.1 概述

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

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

在这里插入图片描述

首先，客户端发起请求，请求网页地址，服务端返回一个空白的 HTML 页面，客户端拿到页面以后加载执行里面的脚本代码（如果有动态数据会发起 AJAX 请求），服务端收到请求之后进行查库相关操作，拿到数据后服务端把数据直接返回给客户端，客户端拿到数据再来渲染动态的页面内容展示给用户，其中，服务端只需要负责数据的处理

【后端】负责数据处理，【前端】负责页面渲染，这种分离模式极大的提高了开发效率和可维护性
这样一来，【前端】更为独立，也不再受限制于【后端】，它可以选择任意的技术方案或框架来处理页面渲染
但是这种模式下，也会存在一些明显的不足，其中最主要的就是：
- 首屏渲染慢
- SEO 问题

4.2 为什么客户端渲染首屏渲染慢

因为 HTML 中没有内容，必须等到 JavaScript 加载并执行完成才能呈现页面内容

传统的服务端渲染是页面直出，不用再去执行 js ，也不用再去发请求
而客户端渲染最起码要经历三次 http 请求周期：第一次是页面的请求，第二次是 js 对应的请求，第三次是动态数据请求

4.3 为什么客户端渲染不利于 SEO

同样因为 HTML 中没有内容，所以对于目前的搜索引擎爬虫来说，页面中没有任何有用的信息，自然无法提取关键词，进行索引了

SEO 全称：Search Engine Optimizers（搜索引擎优化）

利用搜索引擎的规则提高网站在有关搜索引擎内的自然排名。目的是：为网站提供生态式的自我营销解决方案，让其在行业内占据领先地位，获得品牌收益；SEO 包含站外 SEO 和站内 SEO 两方面；为了从搜索引擎中获得更多的免费流量，从网站结构、内容建设方案、用户互动传播、页面等角度进行合理规划，还会使搜索引擎中显示的网站相关信息对用户来说更具有吸引力

// 搜索引擎是怎么获取网页内容的？
const http = require('http')

// 通过程序获取指定的网页内容
// 服务端
// http.get('http://localhost:3000/', res => {
// 客户端
http.get('http://localhost:8080/', res => {
  let data = ''
  res.on('data', chunk => {
    data += chunk
  })
  res.on('end', () => {
    console.log(data)
  })
})

拿到数据后，对于搜索引擎就要去分析：根据权重进行收录，如果发现新的链接就会进入另一个页面再去收录，才有可能通过打开搜索引擎搜索到你的页面
相较于服务端，客户端需要经过解析执行 js 才能渲染出来所谓的网页内容。而搜索引擎的程序不是浏览器，而是一个普通的程序，它拿到的都是网页的 html 字符串，不会像浏览器一样再去加载解析 js、发请求拿数据、再来渲染页面，它分析 body 会发现没有内容

五、现代化的服务端渲染（同构渲染）

5.1 概述

服务端渲染，严格来说是现代化的服务端渲染，也叫同构渲染（后端渲染 + 前端渲染），本质上确实是需要使用到传统的服务端渲染，但是严格来讲应该叫现代化的服务端渲染，也叫同构渲染，也就是【服务端渲染】 + 【客户端渲染】

基本流程：

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

在这里插入图片描述
执行流程：

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

5.2 如何实现同构渲染

使用 Vue、React 等框架的官方解决方案
- 优点：有助于理解原理
- 缺点：需要搭建环境，比较麻烦
使用第三方解决方案
- React 生态中的 Next.js
- Vue 生态中的 Nuxt.js
- Angular 生态中的 Angular Universal

5.3 通过 Nuxt 体验同构渲染

Nuxt.js 是一个基于 Vue.js 生态开发的一个第三方服务端渲染框架，通过它我们可以轻松构建现代化的服务端渲染应用

在这里插入图片描述

安装依赖

npm init -y

npm i nuxt

package.json

"scripts": {
  ...
  "dev": "nuxt"
}

pages/index.vue

<template>
  <div>
    <h1>Home</h1>
  </div>
</template>

<script>
export default {

}
</script>
<style>
</style>

启动项目

npm run dev

这里并没有配置路由，页面就渲染出来了。原因是 Nuxt 会根据 pages 目录来自动生成路由配置

接下来来体验同构渲染

npm i axios

pages/index.vue

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

<script>
import axios from 'axios'

export default {
  name: 'Home',
  components: {},
  // Nuxt 中特殊提供的一个钩子函数
  // 专门用于获取页面服务端渲染的数据 
  async asyncData () {
    const { data } = await axios({
      method: 'GET',
      url: '/data.json'
    })
   
    // 这里返回的数据会和 data() {} 中的数据合并到一起给页面使用
    // return data
    return {
      title: data.title,
      posts: data.posts
    }
  } 
}
</script>

<style>
</style>

static/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": "测试用例"
}

运行结果（服务端已经渲染好了）

在这里插入图片描述

接下来还有一个问题：这个内容是服务端渲染出来的，它还是以前那个单页面应用程序（SPA）吗？
- 依然是，首屏渲染是通过服务端渲染出来的，之后的交互都是客户端渲染，还是刚刚的项目，来加两个链接看看是客户端渲染还是服务端渲染
- 此时通过链接跳转页面并不会引起页面刷新，因此可以整明其还是单页面程序，即客户端渲染

pages/about.vue

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

<script>
export default {

}
</script>

<style>
</style>

layouts/default.vue（固定名称，不可更改）

<!-- 这个模板会作为所有页面的父模板 -->
<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>

在这里插入图片描述

5.4 同构渲染问题

开发条件有限
- 浏览器特定的代码，只能在某些生命周期钩子函数 (lifecycle hook) 中使用；
- 一些外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应用程序中运行
- 不能在服务端渲染期间操作 DOM
- 默写代码操作需要区分运行环境
- …
涉及构建设置和部署的更多要求
- 与可以部署在任何静态文件服务器上的完全静态单页面应用程序(SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境

在这里插入图片描述

更多的服务器端负载
- 在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic)下使用，请准备相应的服务器负载，并明智地采用缓存策略

5.5 服务端渲染使用建议

在对你的应用程序使用服务器端渲染 (SSR) 之前，你应该问的第一个问题是，是否真的需要它
- 这主要取决于内容到达时间 (time-to-content) 对应用程序的重要程度。例如，如果你正在构建一个内部仪表盘，初始加载时的额外几百毫秒并不重要，这种情况下去使用服务器端渲染 (SSR) 将是一个小题大作之举
- 然而，内容到达时间 (time-to-content) 要求是绝对关键的指标，在这种情况下，服务器端渲染(SSR) 可以帮助你实现最佳的初始加载性能
事实上，很多网站是出于效益的考虑才启用服务端渲染，性能倒是在其次
- 假设 A 网站页面中有一个关键字叫“前端性能优化”，这个关键字是 JS 代码跑过一遍后添加到 HTML 页面中的。那么客户端渲染模式下，我们在搜索引擎搜索这个关键字，是找不到 A 网站的——搜索引擎只会查找现成的内容，不会帮你跑 JS 代码。A 网站的运营方见此情形，感到很头大：搜索引擎搜不出来，用户找不到我们，谁还会用我的网站呢？为了把“现成的内容”拿给搜索引擎看，A 网站不得不启用服务端渲染。但性能在其次，不代表性能不重要