Nuxt 支持不同的渲染模式，通用渲染、客户端渲染，还提供了混合渲染以及在 CDN 边缘服务器上渲染应用的可能性。

浏览器和服务器都可以解释 JavaScript 代码，将 Vue.js 组件转换为 HTML 元素。这个步骤称为渲染。Nuxt 支持通用和客户端渲染。我们将介绍这两种方法的优缺点。

默认情况下，Nuxt 使用通用渲染来提供更好的用户体验、性能并优化搜索引擎索引，但您可以在一行配置中切换渲染模式。

通用渲染

这个步骤类似于由 PHP 或 Ruby 应用程序执行的传统服务器端渲染。当浏览器请求启用通用渲染的 URL 时，Nuxt 在服务器环境中运行 JavaScript (Vue.js) 代码，并将完全渲染的 HTML 页面返回给浏览器。如果页面是预先生成的，Nuxt 也可能从缓存中返回完全渲染的 HTML 页面。与客户端渲染不同，用户立即获得应用程序的初始内容。

一旦 HTML 文档被下载，浏览器会解释它，Vue.js 接管文档。曾经在服务器上运行的相同 JavaScript 代码现在在客户端（浏览器）再次运行，启用交互性（因此称为通用渲染），通过将其监听器绑定到 HTML 上。这称为Hydration。当 Hydration 完成后，页面可以享受动态界面和页面过渡等好处。

通用渲染允许 Nuxt 应用程序在保留客户端渲染优势的同时提供快速的页面加载时间。此外，由于内容已经存在于 HTML 文档中，爬虫可以在没有额外开销的情况下对其进行索引。

什么是服务器渲染的，什么是客户端渲染的？

在通用渲染模式下，询问 Vue 文件的哪些部分在服务器和/或客户端上运行是很正常的。

<script setup lang="ts">
const counter = ref(0); // 在服务器和客户端环境中执行

const handleClick = () => {
  counter.value++; // 仅在客户端环境中执行
};
</script>

<template>
  <div>
    <p>Count: {{ counter }}</p>
    <button @click="handleClick">Increment</button>
  </div>
</template>

在初始请求中，counter 引用在服务器中初始化，因为它在 <p> 标签内渲染。handleClick 的内容在这里从未执行。在浏览器中的 Hydration 过程中，counter 引用被重新初始化。handleClick 最终绑定到按钮上；因此可以合理推断 handleClick 的主体将始终在浏览器环境中运行。

中间件 和 页面 在服务器和客户端的 Hydration 过程中运行。插件 可以在服务器或客户端或两者上渲染。组件 也可以被强制仅在客户端上运行。可组合 和 实用工具 的渲染基于其使用的上下文。

服务器端渲染的好处：

• 性能：用户可以立即访问页面的内容，因为浏览器可以比 JavaScript 生成的内容更快地显示静态内容。同时，Nuxt 在 Hydration 过程中保留了 Web 应用程序的交互性。
• 搜索引擎优化：通用渲染将页面的整个 HTML 内容作为经典服务器应用程序传递给浏览器。Web 爬虫可以直接索引页面的内容，这使得通用渲染成为任何希望快速索引的内容的绝佳选择。

服务器端渲染的缺点：

• 开发限制：服务器和浏览器环境不提供相同的 API，编写可以在两者上无缝运行的代码可能很棘手。幸运的是，Nuxt 提供了指南和特定变量来帮助您确定代码的执行位置。
• 成本：需要运行服务器以便动态渲染页面。这增加了与任何传统服务器相同的月度成本。然而，由于通用渲染，浏览器在客户端导航时接管，服务器调用大大减少。通过利用边缘侧渲染可以实现成本降低。

通用渲染非常灵活，几乎可以适应任何用例，特别适合任何内容导向的网站：博客、营销网站、作品集、电子商务网站和市场。

客户端渲染

开箱即用，传统的 Vue.js 应用程序在浏览器（或客户端）中渲染。然后，Vue.js 在浏览器下载并解析所有包含创建当前界面的指令的 JavaScript 代码后生成 HTML 元素。

客户端渲染的好处：

• 开发速度：当完全在客户端工作时，我们不必担心代码的服务器兼容性，例如使用 window 对象等仅限浏览器的 API。
• 更便宜：运行服务器会增加基础设施成本，因为您需要在支持 JavaScript 的平台上运行。我们可以在任何带有 HTML、CSS 和 JavaScript 文件的静态服务器上托管仅限客户端的应用程序。
• 离线：因为代码完全在浏览器中运行，所以即使在互联网不可用时也可以很好地继续工作。

客户端渲染的缺点：

• 性能：用户必须等待浏览器下载、解析和运行 JavaScript 文件。根据下载部分的网络和用户设备的解析和执行，这可能需要一些时间并影响用户体验。
• 搜索引擎优化：通过客户端渲染传递的内容的索引和更新比服务器渲染的 HTML 文档需要更多时间。这与我们讨论的性能缺点有关，因为搜索引擎爬虫不会在第一次尝试索引页面时等待界面完全渲染。使用纯客户端渲染，您的内容将在搜索结果页面中显示和更新需要更多时间。

客户端渲染是一个很好的选择，适用于不需要索引或用户经常访问的高度交互的Web 应用程序。它可以利用浏览器缓存在后续访问中跳过下载阶段，例如 SaaS、后台应用程序或在线游戏。

您可以在 nuxt.config.ts 中启用仅客户端渲染：

export default defineNuxtConfig({
  ssr: false
})

部署静态客户端渲染应用

如果您使用 nuxt generate 或 nuxt build --prerender 命令将应用部署到静态托管，则默认情况下，Nuxt 会将每个页面渲染为单独的静态 HTML 文件。

如果您仅使用纯客户端渲染，这可能是不必要的。您可能只需要一个 index.html 文件，加上 200.html 和 404.html 备用文件，您可以告诉静态 Web 主机为所有请求提供这些文件。

为了实现这一点，我们可以更改路由的预渲染方式。只需将其添加到 nuxt.config.ts 中的钩子中：

export default defineNuxtConfig({
  hooks: {
    'prerender:routes' ({ routes }) {
      routes.clear() // 不生成任何路由（除默认值外）
    }
  },
})

这将生成三个文件：

• index.html
• 200.html
• 404.html

200.html 和 404.html 可能对您使用的托管提供商有用。

跳过客户端备用生成

在预渲染客户端渲染的应用时，Nuxt 默认会生成 index.html、200.html 和 404.html 文件。但是，如果您需要防止在构建中生成任何（或所有）这些文件，可以使用 Nitro 的 'prerender:generate' 钩子。

export default defineNuxtConfig({
  ssr: false,
  nitro: {
    hooks: {
      'prerender:generate'(route) {
        const routesToSkip = ['/index.html', '/200.html', '/404.html']
        if (routesToSkip.includes(route.route)) {
          route.skip = true
        }
      }
    }
  }
})

混合渲染

混合渲染允许使用路由规则为每个路由设置不同的缓存规则，并决定服务器应如何响应给定 URL 的新请求。

以前，Nuxt 应用程序和服务器的每个路由/页面必须使用相同的渲染模式，通用或客户端。在各种情况下，一些页面可以在构建时生成，而其他页面应该在客户端渲染。例如，想象一个带有管理部分的内容网站。每个内容页面应该主要是静态的并且只生成一次，但管理部分需要注册并表现得更像一个动态应用程序。

Nuxt 包含路由规则和混合渲染支持。使用路由规则，您可以为一组 nuxt 路由定义规则，更改渲染模式或根据路由分配缓存策略！

Nuxt 服务器将自动注册相应的中间件，并使用 Nitro 缓存层 包装带有缓存处理程序的路由。

export default defineNuxtConfig({
  routeRules: {
    // 首页在构建时预渲染
    '/': { prerender: true },
    // 产品页面按需生成，在后台重新验证，缓存直到 API 响应更改
    '/products': { swr: true },
    // 产品页面按需生成，在后台重新验证，缓存 1 小时（3600 秒）
    '/products/**': { swr: 3600 },
    // 博客文章页面按需生成，在后台重新验证，在 CDN 上缓存 1 小时（3600 秒）
    '/blog': { isr: 3600 },
    // 博客文章页面按需生成一次，直到下次部署，在 CDN 上缓存
    '/blog/**': { isr: true },
    // 管理仪表板仅在客户端渲染
    '/admin/**': { ssr: false },
    // 在 API 路由上添加 cors 头
    '/api/**': { cors: true },
    // 重定向旧版 URL
    '/old-page': { redirect: '/new-page' }
  }
})

路由规则

您可以使用的不同属性如下：

• redirect: string - 定义服务器端重定向。
• ssr: boolean - 禁用应用程序部分的服务器端渲染，使其仅在浏览器中渲染，使用 ssr: false
• cors: boolean - 自动添加 cors 头，使用 cors: true - 您可以通过覆盖 headers 自定义输出
• headers: object - 为网站的部分添加特定头，例如您的资产
• swr: number | boolean - 向服务器响应添加缓存头，并在服务器或反向代理上缓存，具有可配置的 TTL（生存时间）。Nitro 的 node-server 预设能够缓存完整响应。当 TTL 过期时，将发送缓存的响应，同时在后台重新生成页面。如果使用 true，则添加 stale-while-revalidate 头而没有 MaxAge。
• isr: number | boolean - 行为与 swr 相同，只是我们能够在支持此功能的平台（目前是 Netlify 或 Vercel）上将响应添加到 CDN 缓存中。如果使用 true，内容将在 CDN 内部的下次部署之前持久化。
• prerender: boolean - 在构建时预渲染路由，并将其作为静态资产包含在构建中
• noScripts: boolean - 禁用网站部分的 Nuxt 脚本和 JS 资源提示的渲染。
• appMiddleware: string | string[] | Record<string, boolean> - 允许您定义中间件，应该或不应该在应用程序的 Vue 应用程序部分（即不是 Nitro 路由）内的页面路径上运行

在可能的情况下，路由规则将自动应用于部署平台的本机规则，以获得最佳性能（目前支持 Netlify 和 Vercel）。

示例：

边缘侧渲染

边缘侧渲染（ESR）是 Nuxt 引入的一个强大功能，允许通过内容分发网络（CDN）的边缘服务器更接近用户地渲染 Nuxt 应用程序。通过利用 ESR，您可以确保提高性能和减少延迟，从而提供增强的用户体验。

使用 ESR，渲染过程被推到网络的“边缘”——CDN 的边缘服务器。请注意，ESR 更像是一个部署目标，而不是实际的渲染模式。

当请求页面时，不是一直到原始服务器，而是由最近的边缘服务器拦截。该服务器生成页面的 HTML 并将其发送回用户。此过程最大限度地减少了数据必须传输的物理距离，减少延迟并更快地加载页面。

边缘侧渲染得益于 Nitro，这是为 Nuxt 提供动力的服务器引擎。它为 Node.js、Deno、Cloudflare Workers 等提供跨平台支持。

您可以利用 ESR 的当前平台有：

• Cloudflare Pages，使用 git 集成和 nuxt build 命令实现零配置
• Vercel Edge Functions，使用 nuxt build 命令和 NITRO_PRESET=vercel-edge 环境变量
• Netlify Edge Functions，使用 nuxt build 命令和 NITRO_PRESET=netlify-edge 环境变量

请注意，使用路由规则进行边缘侧渲染时可以使用混合渲染。

您可以探索在上述某些平台上部署的开源示例：