Vue SSR 水合性能揭秘：预编译模板 VS 直接模板，谁更快？

2025-04-27 02:28:38

Vue SSR 水合性能：预编译模板 vs. 直接使用模板，哪个更快？

在搞服务端渲染 (SSR) 特别是静态站点生成 (SSG) 时，一个常见的问题冒出来：在客户端水合 (Hydration) 阶段，这两种方式有没有明显的性能差别？

方式一： 使用 @vue/compiler-sfc 里的 compileTemplate 预先编译模板，拿到 render 函数，然后把它传给 createSSRApp。
方式二： 干脆直接把模板字符串 (template) 扔给 createSSRApp。

假设服务端已经吐出了包含 pageContent 的 HTML 结构，我们现在关心的是客户端接手（水合）时的效率。多搞一步预编译，增加的这点复杂度，到底值不值得？或者说，什么场景下用 compileTemplate 才合适？

来看下代码的样子：

方式一：预编译

import { compileTemplate } from '@vue/compiler-sfc';
import { createSSRApp } from 'vue';
// 假设 pageContent 是从文件或别处读取的模板字符串
// 假设 filename 和 id 是必要的上下文信息
const { code } = compileTemplate({
    source: pageContent,
    filename: 'MyComponent.vue', // 示例文件名
    id: 'data-v-xxxxxx',       // 示例 scopeId
    // 其他可能需要的编译选项...
});

// code 大概是 এরকম 样子: 'export function render(_ctx, _cache) { ... }'
// 需要一种方式从这个 code 字符串中提取出 render 函数
// 这通常在构建时完成，比如通过 Node.js 的 vm 模块或者更复杂的构建插件
// 这里简化假设我们已经得到了 renderFunction
// 这是一个 *示意性* 的获取方式，实际中会更复杂或由构建工具处理
let renderFunction;
// 在 Node.js 环境中可能的做法（不推荐在生产环境运行时这么干）
// const script = new vm.Script(code);
// const context = { module: { exports: {} } };
// script.runInNewContext(context);
// renderFunction = context.module.exports.render;

// 在实际应用中，构建工具 (如 Vite/Vue CLI) 会处理 .vue 文件
// 并生成可以直接 import 的包含 render 函数的 JS 模块

const app = createSSRApp({
  render: renderFunction, // 直接使用编译好的 render 函数
  // ... 可能还有其他 data, methods 等
});

app.mount('#app');

方式二：直接使用模板

import { createSSRApp } from 'vue';

// 假设 pageContent 是模板字符串
const app = createSSRApp({
  template: pageContent, // 直接把模板字符串给 Vue
  // ... 可能还有其他 data, methods 等
});

app.mount('#app');

那这两种方式，在客户端水合时，性能上到底有啥不一样？

问题缘起：为何会有这个疑问？

要弄明白这个问题，先得简单了解下 Vue SSR 和水合是怎么回事。

服务端渲染 (SSR): 服务端运行 Vue 应用，把组件渲染成 HTML 字符串，然后发送给浏览器。用户能更快看到内容，对 SEO 也友好。
客户端水合 (Hydration): 浏览器拿到 HTML 内容后，客户端的 JavaScript (Vue) 会接管这些静态的 HTML。它不是重新渲染一遍，而是检查现有的 DOM 结构，跟据组件预期，给它们附加上交互能力（比如事件监听器、动态数据绑定等）。这个过程就像给骨架（HTML）注入灵魂（JavaScript 交互）。

两种方式的核心区别在于：模板是什么时候被编译成渲染函数 (render function) 的？

方式一 (预编译): 编译工作在构建时 (build time) 或者服务端准备阶段就完成了。客户端拿到的是直接可执行的 JavaScript 渲染函数。
方式二 (直接模板): 编译工作发生在客户端 。浏览器加载完 JavaScript 后，Vue 的运行时编译器 (runtime compiler) 需要先解析模板字符串，把它转成渲染函数，然后才能开始水合。

这个时间点差异，直接关系到客户端的负担。

剖析两种方案的差异

咱们细致拆解一下这两种方式的运作机制和优劣。

方案一：预编译 (`compileTemplate`)

原理

这种方式下，你利用了 @vue/compiler-sfc (或者通常是构建工具如 Vite、Vue CLI 背后的机制) 在打包构建阶段就把 .vue 文件或模板字符串转换成了优化过的 JavaScript render 函数。服务端渲染时可以直接用这个 render 函数生成 HTML。发送到客户端的 JavaScript 包里，这个组件对应的部分，只包含这个渲染函数和其他逻辑代码，不包含原始的模板字符串，更重要的是，通常不需要 包含 Vue 的模板编译器。

优势

客户端启动更快: 浏览器执行 JavaScript 时，不需要再花时间去解析和编译模板。直接执行 render 函数通常比先编译再执行要快，减少了初始化的 CPU 开销。这对低端设备或者性能要求高的场景比较重要。
更小的客户端包体积: 如果你的所有组件都预编译了，你可以使用 Vue 的 运行时构建版本 (runtime-only build) ，它不包含模板编译器，体积比包含编译器的完整构建版本 (full build) 小不少 (大约小 30% 左右)。更小的包意味着更快的下载、解析和执行时间。

代码示例

（见上文方式一的代码）
请注意，手动调用 compileTemplate 然后提取 render 函数在实际项目中比较少见，除非你在做一些底层工具或者需要动态处理非 SFC 的模板字符串。常规开发中，构建工具已经帮你把 .vue 文件处理好了。当你写：

// MyComponent.vue
<template>
  <div>{{ message }}</div>
</template>
<script>
export default {
  data() { return { message: 'Hello from pre-compiled!' } }
}
</script>

构建工具会自动编译 <template> 部分，生成类似 render 函数的东西，打包进你的应用代码里。客户端 createSSRApp 导入这个组件时，拿到的就是已经包含 render 函数的对象。

方案二：直接使用模板 (`template` 选项)

原理

当你把模板字符串直接通过 template 选项传给 createSSRApp 时，Vue 需要在客户端拥有解析这个字符串的能力。这意味着你的应用必须打包完整构建版本 (runtime + compiler) 的 Vue。在应用初始化时，Vue 的编译器会介入，解析 template 字符串，动态生成 render 函数，然后再用这个 render 函数去进行水合操作。

优势

设置简单: 对于某些场景，比如模板是从 CMS 拉取的、或者是在运行时动态生成的，无法在构建时预编译，那么这种方式就很直接方便。
灵活性: 在一些特殊场景，需要在运行时动态定义和编译组件模板。

代码示例

（见上文方式二的代码）

劣势

客户端启动开销增大: 浏览器需要执行模板编译这个额外的步骤，增加了 JavaScript 的初始化时间。
更大的客户端包体积: 必须引入 Vue 的完整构建版本，增加了下载负担。

性能影响：关键在于水合阶段

回到最初的问题：对水合阶段 的性能影响。

严格来说，“水合” 本身是指 Vue 接管已有 DOM 并附加事件监听等交互的过程。而模板编译发生在水合之前的应用初始化阶段。

所以，两种方式的主要性能差异体现在应用启动和初始化的总时间 上，这间接影响了用户感受到页面可交互的时间：

方案一 (预编译): 启动快。由于没有客户端编译步骤，JavaScript 初始化负担轻。并且因为可以使用 runtime-only 构建，JS 包更小，下载和解析也更快。水合过程本身（DOM 对比和附加行为）理论上和方案二是一样的，但它能更早开始 。
方案二 (直接模板): 启动慢。需要先执行模板编译，这个过程消耗 CPU 时间。同时需要加载更大的 Vue 构建版本。

结论是：方式一 (预编译) 在客户端性能上通常明显优于方式二 (直接模板)。 这个差异在首次访问、网络较差或设备性能不高的情况下更为显著。减少了客户端的工作量，页面能更快变得可交互。

如何选择：场景决定方案

知道了性能差异，选择哪个就看你的具体需求了：

强烈推荐预编译 (方案一) 的场景:

追求性能的应用: 这是标准做法，能带来最快的客户端启动速度和最小的包体积。
静态站点生成 (SSG): SSG 的核心思想就是尽可能在构建时完成工作，预编译模板完美契合。
所有使用 .vue 单文件组件 (SFC) 的项目: 现代 Vue 构建工具 (Vite, Vue CLI) 默认就会对 SFC 进行预编译。你其实已经在用这种方式了，不需要特别做什么。
希望减小客户端负担和包体积的项目。

可以考虑直接模板 (方案二) 的场景:

模板在运行时动态生成且无法预知: 比如模板内容是从数据库或 API 获取，并且在构建时无法获得。注意这种情况下的安全风险，确保模板来源可靠。
快速原型或简单场景: 如果项目非常小，或者性能不是首要考虑因素，直接用 template 选项可能更省事。
一些特殊的库或框架集成: 极少数情况下，可能需要运行时编译。

大部分情况下，尤其是做 SSR/SSG，选择预编译是最佳实践。构建工具使得这一切变得非常透明，开发者甚至感觉不到编译的存在。

实践建议与进阶技巧

拥抱构建工具: 使用 Vite 或 Vue CLI 这类现代构建工具。它们默认配置就支持 .vue 文件的预编译，并能智能地打包 runtime-only 的 Vue 版本，自动帮你实现方案一的优势。你只需要正常写 .vue 文件即可。
检查 Vue 构建版本: 确保你的项目配置（比如 vue.config.js 或 vite.config.js）没有强制使用完整构建版本 (通常带有 compiler 字样或 runtimeCompiler: true 之类的设置)，除非你确实需要运行时编译。默认设置通常是正确的（使用 runtime-only）。
手动处理非 SFC 模板: 如果你确实有动态从字符串创建组件的需求，并且想获得预编译的好处，可以考虑：
- 在服务端 接收模板字符串，使用 compileTemplate 生成 render 函数代码，然后将这段代码发送给客户端执行。这比直接发送模板让客户端编译要好。
- 这需要更复杂的设置，通常用在平台型应用或底层库开发中。
关注整体性能:
- 代码拆分 (Code Splitting): 对路由和大型组件进行代码拆分，即使用预编译，也能有效减小初始加载包体积，按需加载代码。
- 服务端渲染性能: 优化服务端生成 HTML 的速度同样重要，比如使用缓存策略。
- 静态资源优化: 图片、CSS 等资源的优化也不可忽视。
用数据说话: 性能差异理论上存在，但具体影响多大，最好在你的目标设备和网络环境下进行测试。使用 Chrome DevTools 的 Performance 标签页，分析页面加载过程中的 JavaScript 执行时间，看看是否存在编译瓶颈。

总的来说，对于 Vue SSR/SSG 项目，利用构建工具的预编译能力是标准且高效的做法。它能有效提升客户端的启动性能，减小包体积，是优化用户体验的关键一步。手动调用 compileTemplate 的场景相对较少，多半是构建工具在幕后为你代劳了。除非有特殊需求，否则坚持使用 .vue 文件和标准构建流程，就能自动获得预编译带来的好处。