渲染模式 · Nuxt 概念

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

浏览器和服务器都可以解释 JavaScript 代码，将 Vue.js 组件转换为 HTML 元素。此步骤称为 **渲染**。Nuxt 支持 **通用** 和 **客户端** 渲染。这两种方法都有利弊，我们将在下面介绍。

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

通用渲染

当浏览器请求启用通用（服务器端 + 客户端）渲染的 URL 时，服务器会将完全渲染的 HTML 页面返回给浏览器。无论页面是预先生成并缓存还是动态渲染，在某个时刻，Nuxt 都会在服务器环境中运行 JavaScript（Vue.js）代码，生成一个 HTML 文档。与客户端渲染相反，用户会立即获得应用程序的内容。此步骤类似于 PHP 或 Ruby 应用程序执行的传统 **服务器端渲染**。

为了不失去客户端渲染方法的优势，例如动态界面和页面过渡，客户端（浏览器）会在 HTML 文档下载后加载在服务器上运行的 JavaScript 代码。浏览器会再次解释它（因此是 **通用渲染**），Vue.js 会接管文档并启用交互性。

在浏览器中使静态页面具有交互性称为“水合”。

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

Users can access the static content when the HTML document is loaded. Hydration then allows page's interactivity

服务器端渲染的优势

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

服务器端渲染的缺点

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

通用渲染非常通用，几乎可以适应任何用例，尤其适用于任何以内容为中心的网站：博客、营销网站、投资组合、电子商务网站和市场。

有关编写无水合不匹配的 Vue 代码的更多示例，请参阅 Vue 文档。

当导入依赖于浏览器 API 并具有副作用的库时，请确保导入它的组件仅在客户端调用。捆绑器不会对包含副作用的模块的导入进行树状抖动。

客户端渲染

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

Users have to wait for the browser to download, parse and execute the JavaScript before seeing the page's content

客户端渲染的优势

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

客户端渲染的缺点

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

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

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

nuxt.config.ts

export default defineNuxtConfig({
  ssr: false
})

如果您确实使用 ssr: false，您还应该在 ~/app/spa-loading-template.html 中放置一个 HTML 文件，其中包含一些您想用来渲染加载屏幕的 HTML，该屏幕将在您的应用程序被水合之前渲染。

在 SPA 加载模板中了解更多信息。

混合渲染

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

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

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

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

nuxt.config.ts

export default defineNuxtConfig
({
  routeRules
: {
    // Homepage pre-rendered at build time
    '/': { prerender
: true },
    // Products page generated on demand, revalidates in background, cached until API response changes
    '/products': { swr
: true },
    // Product page generated on demand, revalidates in background, cached for 1 hour (3600 seconds)
    '/products/**': { swr
: 3600 },
    // Blog posts page generated on demand, revalidates in background, cached on CDN for 1 hour (3600 seconds)
    '/blog': { isr
: 3600 },
    // Blog post page generated on demand once until next deployment, cached on CDN
    '/blog/**': { isr
: true },
    // Admin dashboard renders only on client-side
    '/admin/**': { ssr
: false },
    // Add cors headers on API routes
    '/api/**': { cors
: true },
    // Redirects legacy urls
    '/old-page': { redirect
: '/new-page' }
  }
})

路由规则

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

redirect: string - 定义服务器端重定向。
ssr: boolean - 禁用应用程序部分的服务器端渲染，并使用 ssr: false 使其成为 SPA 应用程序。
cors: boolean - 使用 cors: true 自动添加 cors 标头 - 您可以通过覆盖 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 - 在构建时预渲染路由，并将它们包含在构建中作为静态资产
experimentalNoScripts: boolean - 禁用对网站部分的 Nuxt 脚本和 JS 资源提示的渲染。
appMiddleware: string | string[] | Record<string, boolean> - 允许您定义应该或不应该为 Vue 应用程序部分（即，不是您的 Nitro 路由）中的页面路径运行的中间件

只要有可能，路由规则将自动应用于部署平台的本机规则，以实现最佳性能（目前支持 Netlify 和 Vercel）。

请注意，使用 nuxt generate 时，混合渲染不可用。

示例

Nuxt Vercel ISR

在 Vercel 上部署的具有混合渲染的 Nuxt 应用程序示例。

边缘端渲染

边缘端渲染 (ESR) 是 Nuxt 3 中引入的一项强大功能，它允许通过内容交付网络 (CDN) 的边缘服务器更靠近用户渲染您的 Nuxt 应用程序。通过利用 ESR，您可以确保提高性能和降低延迟，从而提供增强的用户体验。

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

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

边缘端渲染得益于 Nitro，它是为 Nuxt 3 提供动力的服务器引擎。它为 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 环境变量

请注意，在使用边缘端渲染和路由规则时，可以使用 **混合渲染**。

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

Nuxt Todos Edge

一个带有用户身份验证、SSR 和 SQLite 的待办事项应用程序。

Atinotes

基于 CloudFlare KV 的具有通用渲染的可编辑网站。

Vue.js 开发

Nuxt 使用 Vue.js 并添加了组件自动导入、基于文件的路由和可组合项等功能，以实现 SSR 友好的使用方式。

服务器引擎

Nuxt 3 由一个新的服务器引擎提供支持：Nitro。