在 Headless WordPress + Nuxt.js 的架構中，WordPress 作為內容後端透過 REST API 提供資料，Nuxt.js 作為前端負責渲染頁面。這種分離帶來了靈活性和可擴展性，但也引入了一個新挑戰：每次頁面請求都可能觸發一次或多個 WordPress API 呼叫，在高流量場景下不僅拖慢回應速度，還會給伺服器帶來不必要的壓力。本文將系統性地介紹在 Nuxt.js 專案中最佳化 WordPress REST API 資料快取的多層策略。
為什麼快取至關重要
一個典型的 Nuxt.js 文章列表頁可能需要請求三到四個 WordPress 端點：文章列表（/wp/v2/posts）、分類目錄（/wp/v2/categories）、標籤（/wp/v2/tags）、媒體資訊（/wp/v2/media）。如果每位訪客都觸發完整的 API 呼叫鏈，伺服器負載會呈線性增長。合理使用快取可以將重複請求的回應時間從數百毫秒降至幾毫秒，使用者體驗提升顯著。
第一層：Nuxt.js useFetch 的快取能力
Nuxt 3 內建的 useFetch 和 useAsyncData 組合式函數提供了開箱即用的快取機制。key 參數是快取的核心——具有相同 key 的請求在伺服器端渲染（SSR）期間只會執行一次，客戶端導航時則重複使用已有資料。
// composables/usePosts.ts
export const usePosts = (page: number) => {
return useFetch('/wp/v2/posts', {
baseURL: 'https://api.example.com/wp-json',
key: `posts-page-${page}`,
query: { page, per_page: 10, _embed: true },
getCachedData: (key) => {
const nuxtApp = useNuxtApp()
const data = nuxtApp.payload.data[key]
if (!data) return
const age = Date.now() - (nuxtApp._cachedTime?.[key] || 0)
if (age < 5 * 60 * 1000) return data
}
})
}上面的程式碼透過 getCachedData 實現了簡單的 stale-while-revalidate 模式：5 分鐘內直接返回快取資料，過期後下一次請求會觸發後台重新整理。
第二層：Nitro Server Route Rules
Nuxt 3 的 Nitro 伺服器引擎支援透過 routeRules 設定細粒度的快取策略。這是最推薦的做法——直接在 nuxt.config.ts 中宣告每個路由的快取行為：
// nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
'/': { swr: 300 },
'/posts/**': { swr: 600 },
'/categories/**': { swr: 3600 },
},
nitro: {
storage: {
redis: {
driver: 'redis',
host: '127.0.0.1',
port: 6379
}
}
}
})swr（stale-while-revalidate）參數指定快取有效期（秒）。Nitro 在有效期內直接返回快取內容，過期後先返回舊內容同時背景生成新內容更新快取。將 Nitro 的儲存驅動切換為 Redis，可使快取資料在服務重啟後依然有效。
第三層：WordPress REST API 快取控制
在 WordPress 端也可以做文章級別的快取最佳化。REST API 預設不傳送強快取頭，我們可以透過 rest_post_dispatch 過濾器新增 Cache-Control 頭：
add_filter('rest_post_dispatch', function($response, $server, $request) {
$method = $request->get_method();
if ($method !== 'GET') return $response;
$response->header('Cache-Control', 'public, max-age=300, s-maxage=600');
$response->header('Vary', 'Accept-Encoding');
return $response;
}, 10, 3);第四層：CDN 邊緣快取
對於生產環境，CDN 是最外層的快取防線。將 Nuxt.js 的 SSR 輸出和靜態資源透過 Cloudflare、Vercel Edge Network 或阿里雲 CDN 分發，配合 stale-while-revalidate 回應頭，即使後端 API 暫時不可用，CDN 也能持續提供舊版本內容。
實戰組合策略
一個成熟專案的快取架構應該是：瀏覽器快取 → CDN → Nitro/Node.js → WordPress 物件快取 → MySQL 查詢快取。具體建議：
- 開發環境：僅使用 useFetch 的 key 去重
- 測試環境：啟用 Nitro swr 快取，60-120 秒過期
- 正式環境：Nitro Redis 快取 + CDN 邊緣快取，頁面級 5-10 分鐘
注意事項與總結
快取的核心矛盾是資料新鮮度與回應速度的平衡。內容更新頻繁的站點應縮短快取時間，或採用 Webhook 機制在 WordPress 發布文章時主動清除相關快取。包含使用者個人化內容的頁面（如使用者中心、購物車）必須排除在快取策略之外。合理運用這些多層快取策略，你的 Headless WordPress 站點將擁有媲美純靜態站點的存取速度。
