乐趣区

关于vue.js:Nuxt3实战系列之了解Nuxt3的渲染模式

jiezi

应用过 nuxt2 的人都晓得，nuxt 并不单单是个服务端渲染框架，它也同时具备纯客户端渲染以及动态化渲染的能力。在 nuxt3 上，这三种渲染模式也得以保留，而且还新增了一种 hybird 模式，也就是能够按路由别离设置渲染模式。

1. 纯客户端渲染

开箱即用，一个传统的在浏览器（或客户端）中被渲染的 Vue.js 应用程序。这种模式下，Vue.js 在浏览器下载并解析所有蕴含创立以后界面指令的 JavaScript 代码后，生成 HTML 元素。

尽管这种技术容许建设简单和动静的 UI，并具备平滑的页面过渡，但它有不同的长处和毛病。

长处

  • 开发速度快 ：当齐全在客户端工作时，咱们不用放心代码的服务端兼容问题，例如，通过应用 window 对象等仅实用于浏览器的 API。
  • 部署成本低 ：** 运行服务器会减少基础设施的老本，因为你须要在一个反对 JavaScript 的平台上运行。咱们能够在任何带有 HTML、CSS 和 JavaScript 文件的动态服务器上托管纯客户端的应用程序。

  • 可离线拜访 ：** 因为代码齐全在浏览器中运行，所以它能够在互联网不可用时很好地放弃工作。

    毛病

  • 性能 ：用户必须期待浏览器下载、解析和运行 JavaScript 文件。这取决于下载局部的网络和解析及执行局部的用户设施，这可能须要一些工夫并影响用户的体验。

  • 搜索引擎优化 ：与服务器渲染的 HTML 文档相比，通过客户端渲染提供的内容的索引和更新须要更多的工夫。这与咱们探讨的性能缺点无关，因为搜索引擎爬虫在第一次尝试索引页面时不会期待界面齐全出现。应用纯客户端渲染，你的内容在搜寻后果页中的显示和更新将须要更多工夫。

    利用场景

    对于不须要索引或用户频繁拜访的重度交互网络应用，客户端渲染是一个不错的抉择。它能够利用浏览器缓存来跳过后续拜访的下载阶段，如 SaaS、Admin 管理系统或在线游戏等。

    2. 服务端渲染

    当浏览器申请一个开启了服务端渲染的 URL 时，服务器会向浏览器返回一个齐全渲染的 HTML 页面。不论这个页面是当时生成并缓存的，还是即时渲染的，在某个时刻，Nuxt 曾经在服务器环境中运行了 JavaScript（Vue.js）代码，产生了一个 HTML 文档。用户立刻失去咱们的应用程序的内容，与客户端渲染相同。这一步相似于 PHP 或 Ruby 应用程序所执行的传统服务器端渲染。
    为了不失去客户端渲染办法的益处，例如动静界面和页面转换，一旦 HTML 文档被下载，客户端就会在后盾加载服务器上运行的 javascript 代码。浏览器再次对其进行解释（因而是通用渲染），Vue.js 则管制该文档并实现交互性。
    让动态页面在浏览器中实现交互被称为 “Hydration”。
    服务端渲染使得 Nuxt 应用程序有更短的页面加载工夫，同时保留了客户端渲染的长处。此外，因为内容曾经存在于 HTML 文档中，搜索引擎爬虫能够在没有开销的状况下索引它。

长处

  • 性能： 用户能够立刻拜访页面的内容，因为浏览器显示动态内容的速度比 JavaScript 生成的内容快得多。同时，Nuxt 在客户端从新渲染过程中保留了网络应用的交互性。

  • 搜索引擎优化： 通用渲染将页面的整个 HTML 内容作为一个经典的服务器应用程序提供给浏览器。网络爬虫能够间接对页面内容进行索引，这使得通用渲染成为任何你想疾速索引的内容的最佳抉择。

    毛病

  • 开发限度 ：服务器和浏览器环境不提供雷同的 API，要写出能在两边无缝运行的代码可能很辣手。侥幸的是，Nuxt 提供了指导方针和特定的变量来帮忙你确定一段代码的执行地位。

  • 老本 ：须要启动服务器运行，以便在运行中渲染页面。这就像任何传统的服务器一样减少了每月的老本。然而，因为通用渲染，浏览器接管了客户端的导航，服务器的调用大大减少。

    利用场景

    通用渲染的用处十分宽泛，简直能够适宜任何应用状况，特地适宜任何面向内容的网站：博客、商城、电子商务网站等。
    客户端渲染和服务端渲染是在浏览器中显示界面的不同策略。
    默认状况下，Nuxt 应用通用渲染（服务端渲染）来提供更好的用户体验和性能，并优化搜索引擎的索引，但你能够在一行配置中切换渲染模式。

export default defineNuxtConfig({
  ssr: false
  // ...other setting
})

3. 预渲染

应用 nuxi generate 命令来构建应用程序。对于每一个页面，Nuxt 应用爬虫来生成相应的 HTML 和有效载荷文件。构建的文件将在.output/public 目录下生成。
你能够手动指定 Nitro 在构建过程中获取和预渲染的路线。

defineNuxtConfig({
  nitro: {
    prerender: {routes: ['/user/1', '/user/2']
    }
  }
})

预渲染能够解决纯动态渲染的毛病，即能保障用户拜访时页面加载比拟迅速，也能让搜索引擎爬虫对页面内容进行索引。不过预渲染针对动静路由在解决上会比拟辣手。

4. 混合渲染（Nuxt3 新增）

在大多数状况下，Nuxt 2 中执行的通用渲染提供了良好的用户和开发者体验。然而，Nuxt 3 通过引入混合渲染和 cdn 渲染，使通用渲染更进一步。
混合渲染容许应用路由规定为每条路由制订不同的渲染规定，并决定服务器应如何回应给定 URL 上的新申请。
以前 Nuxt 应用程序和服务器的每个路由 / 页面都必须应用雷同的渲染模式，客户端或服务端。然而在各种状况下，有些页面能够在构建时生成，而有些页面应该在客户端渲染。例如，想想一个带有治理局部的内容网站。每一个内容页面应该次要是动态的，并且只生成一次，然而治理局部须要注册，并且体现得更像一个动静应用程序。
从 rc.12 开始的 Nuxt 3 带有公共测试版的路由规定和混合渲染反对。应用路由规定，你能够为一组 nuxt 路由定义规定，扭转渲染模式，或依据路由指定一个缓存策略! Nuxt 服务器将主动注册相应的中间件，并应用 nitro 缓存层将路由与缓存处理程序打包。只有有可能，路由规定将被主动利用到部署平台的本地规定（目前反对 Netlify 和 Vercel）。

  • redirect – 定义服务器端的重定向。
  • ssr – 禁用服务器端对你的应用程序的局部进行渲染，并使其成为 SPA 专用，应用 ssr: false。
  • cors – 用 cors: true 主动增加 cors 头文件 – 你能够用 headers 笼罩自定义输入。
  • headers – 在你的网站上增加特定的题目。
  • static – static 反对繁多（按需）构建；
  • swr – swr 反对动态构建，继续一个可配置的 TTL。(目前在 Netlify 上能够实现齐全增量的动态生成，Vercel 行将推出）。

示例如下：

export default defineNuxtConfig({
  routeRules: {
    // Static page generated on-demand, revalidates in background
    '/blog/**': {swr: true},
    // Static page generated on-demand once
    '/articles/**': {static: true},
    // Set custom headers matching paths
    '/_nuxt/**': {headers: { 'cache-control': 's-maxage=0'} },
    // Render these routes with SPA
    '/admin/**': {ssr: false},
    // Add cors headers
    '/api/v1/**': {cors: true},
    // Add redirect headers
    '/old-page': {redirect: '/new-page'},
    '/old-page2': {redirect: { to: '/new-page', statusCode: 302} }
  }
})

5. 在 CDN Edge Workers 上渲染（Nuxt3 新增）

传统模式下，服务器端渲染只能应用 Node.js。Nuxt 3 通过在 CDN Edge Workers 间接渲染代码，升高了提早和老本，将其晋升到另一个档次。
Nitro 是反对 Nuxt 3 的新服务器引擎。它提供了对 Node.js、Deno、Workers 等的跨平台反对。Nitro 的设计是与平台无关的，容许在边缘渲染 Nuxt 应用程序，更靠近你的用户，容许复制和进一步优化。

更多信息可查看 nuxt3 官网文档

退出移动版