渲染模式
Nuxt 支援不同的渲染模式,通用渲染、客戶端渲染,但也提供混合渲染,以及在CDN 邊緣伺服器上渲染應用程式的可能性。
瀏覽器和伺服器都可以解析 JavaScript 程式碼,將 Vue.js 元件轉換為 HTML 元素。這個步驟稱為渲染。Nuxt 支援通用和客戶端渲染。這兩種方法都有其優點和缺點,我們將在接下來的內容中說明。
預設情況下,Nuxt 使用通用渲染來提供更好的使用者體驗、效能和優化搜尋引擎索引,但您可以在一行配置中切換渲染模式。
通用渲染
此步驟類似於 PHP 或 Ruby 應用程式執行的傳統伺服器端渲染。當瀏覽器請求啟用通用渲染的 URL 時,Nuxt 會在伺服器環境中執行 JavaScript (Vue.js) 程式碼,並將完全渲染的 HTML 頁面傳回給瀏覽器。如果頁面是預先產生的,Nuxt 也可能會從快取傳回完全渲染的 HTML 頁面。與客戶端渲染相反,使用者可以立即取得應用程式的完整初始內容。
下載 HTML 文件後,瀏覽器會解析此文件,而 Vue.js 會接管該文件。先前在伺服器上執行的相同 JavaScript 程式碼現在會在背景中再次在客戶端 (瀏覽器) 上執行,透過將其監聽器繫結到 HTML 來啟用互動性(因此稱為通用渲染)。這稱為水合。水合完成後,頁面即可享有動態介面和頁面轉換等優點。
通用渲染允許 Nuxt 應用程式在保留客戶端渲染優點的同時,提供快速的頁面載入時間。此外,由於內容已存在於 HTML 文件中,因此爬蟲程式可以無額外負擔地索引它。
哪些是伺服器渲染,哪些是客戶端渲染?
在通用渲染模式下,詢問 Vue 檔案的哪些部分在伺服器和/或客戶端上執行是很正常的。
<script setup lang="ts">
const counter = ref(0); // executes in server and client environments
const handleClick = () => {
counter.value++; // executes only in a client environment
};
</script>
<template>
<div>
<p>Count: {{ counter }}</p>
<button @click="handleClick">Increment</button>
</div>
</template>
在初始請求時,由於在 <p>
標籤內渲染,因此 counter
ref 會在伺服器中初始化。這裡永遠不會執行 handleClick
的內容。在瀏覽器中進行水合期間,counter
ref 會重新初始化。 handleClick
最終會將自身繫結到按鈕;因此可以合理推斷 handleClick
的主體將始終在瀏覽器環境中執行。
中介軟體和頁面會在伺服器和水合期間在客戶端上執行。 外掛可以在伺服器或客戶端或兩者上進行渲染。元件也可以強制僅在客戶端上執行。 組合式函式和公用程式會根據其使用情況的上下文進行渲染。
伺服器端渲染的優點
- 效能:使用者可以立即存取頁面內容,因為瀏覽器顯示靜態內容的速度比 JavaScript 產生的內容快得多。同時,Nuxt 在水合過程中保留了 Web 應用程式的互動性。
- 搜尋引擎最佳化:通用渲染會以傳統伺服器應用程式的形式,將頁面的整個 HTML 內容傳遞到瀏覽器。Web 爬蟲程式可以直接索引頁面的內容,這使得通用渲染成為任何您想要快速索引的內容的絕佳選擇。
伺服器端渲染的缺點
- 開發限制:伺服器和瀏覽器環境不提供相同的 API,而且撰寫可以在兩端無縫執行的程式碼可能會很棘手。幸運的是,Nuxt 提供了指南和特定變數,以協助您確定程式碼在何處執行。
- 成本:需要執行伺服器才能動態渲染頁面。這會像任何傳統伺服器一樣增加每月成本。然而,由於通用渲染以及客戶端導覽的瀏覽器接管,伺服器呼叫次數大大減少。透過利用邊緣端渲染可以降低成本。
通用渲染功能非常多樣化,可以適用於幾乎任何使用案例,尤其適用於任何以內容為導向的網站:部落格、行銷網站、作品集、電子商務網站和市場。
客戶端渲染
開箱即用,傳統的 Vue.js 應用程式會在瀏覽器(或客戶端)中進行渲染。然後,瀏覽器下載並解析所有包含建立目前介面指令的 JavaScript 程式碼後,Vue.js 會產生 HTML 元素。
客戶端渲染的優點
- 開發速度:完全在客戶端上工作時,我們不必擔心程式碼的伺服器相容性,例如,使用僅限瀏覽器的 API,如
window
物件。 - 更便宜: 運行伺服器會增加基礎設施成本,因為您需要在支援 JavaScript 的平台上運行。我們可以在任何具有 HTML、CSS 和 JavaScript 檔案的靜態伺服器上託管僅限用戶端的應用程式。
- 離線: 因為程式碼完全在瀏覽器中運行,即使在網路不可用時,它也能正常運作。
用戶端渲染的缺點
- 效能:使用者必須等待瀏覽器下載、解析和執行 JavaScript 檔案。根據下載的網路速度以及使用者裝置的解析和執行能力,這可能需要一些時間,並影響使用者的體驗。
- 搜尋引擎最佳化:透過用戶端渲染傳遞的內容進行索引和更新,比使用伺服器渲染的 HTML 文件需要更多時間。這與我們討論的效能缺點有關,因為搜尋引擎爬蟲不會等待介面在第一次嘗試索引頁面時完全渲染。使用純用戶端渲染,您的內容會在搜尋結果頁面中花費更多時間顯示和更新。
對於不需要索引或使用者經常訪問的重度互動式網頁應用程式來說,用戶端渲染是一個不錯的選擇。它可以利用瀏覽器快取來跳過後續訪問的下載階段,例如 SaaS、後台應用程式或線上遊戲。
您可以在 nuxt.config.ts
中啟用 Nuxt 的僅限用戶端渲染。
export default defineNuxtConfig({
ssr: false
})
ssr: false
,您也應該在 ~/app/spa-loading-template.html
中放置一個 HTML 檔案,其中包含您想要用於渲染載入畫面的 HTML,該畫面將在您的應用程式完成 hydration 前渲染。部署靜態用戶端渲染應用程式
如果您使用 nuxi generate
或 nuxi build --prerender
命令將您的應用程式部署到靜態託管,那麼預設情況下,Nuxt 會將每個頁面渲染為單獨的靜態 HTML 檔案。
如果您使用的是純用戶端渲染,那麼這可能是不必要的。您可能只需要一個 index.html
檔案,加上 200.html
和 404.html
回退,您可以告訴您的靜態網頁主機為所有請求提供這些檔案。
為了實現這一點,我們可以更改路由的預渲染方式。只需將此添加到您的 hook 中 nuxt.config.ts
。
export default defineNuxtConfig({
hooks: {
'prerender:routes' ({ routes }) {
routes.clear() // Do not generate any routes (except the defaults)
}
},
})
這將產生三個檔案
index.html
200.html
404.html
200.html
和 404.html
可能對您正在使用的託管提供商有用。
混合渲染
混合渲染允許使用路由規則針對每個路由使用不同的快取規則,並決定伺服器應如何回應給定 URL 的新請求。
先前,Nuxt 應用程式和伺服器的每個路由/頁面都必須使用相同的渲染模式,即通用或用戶端渲染。在許多情況下,某些頁面可以在建置時生成,而其他頁面應由用戶端渲染。例如,想想一個帶有管理員部分的內容網站。每個內容頁面都應該主要是靜態的且生成一次,但管理員部分需要註冊,並且行為更像是一個動態應用程式。
Nuxt 包含路由規則和混合渲染支援。使用路由規則,您可以為一組 Nuxt 路由定義規則,變更渲染模式或根據路由分配快取策略!
Nuxt 伺服器將使用 Nitro 快取層自動註冊相應的中介軟體,並使用快取處理常式包裝路由。
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 pages 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
- 禁用應用程式區段的 HTML 伺服器端渲染,使其僅在瀏覽器中使用ssr: false
渲染cors: boolean
- 使用cors: true
自動新增 cors 標頭 - 您可以通過使用headers
覆蓋來客製化輸出headers: object
- 為您網站的區段新增特定標頭 - 例如,您的資產swr: number | boolean
- 將快取標頭新增到伺服器回應,並在伺服器或反向代理上快取可配置的 TTL(存活時間)。Nitro 的node-server
預設值能夠快取完整的回應。當 TTL 過期時,將傳送快取的回應,同時頁面將在背景中重新產生。如果使用 true,則會新增一個不帶 MaxAge 的stale-while-revalidate
標頭。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
時,混合渲染不可用。範例
邊緣端渲染
邊緣端渲染 (ESR) 是 Nuxt 中引入的一項強大功能,它允許透過內容傳遞網路 (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
環境變數 - 使用
nuxt build
命令和NITRO_PRESET=netlify-edge
環境變數的 Netlify Edge Functions
請注意,當使用邊緣端渲染 (Edge-Side Rendering) 與路由規則時,可以使用混合渲染 (Hybrid Rendering)。
您可以探索在上述某些平台上部署的開源範例