应用过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官网文档