Nuxt.js + WordPress 架構：效能、速度、安全與快取的全方位解析

引言

傳統 WordPress 網站將前後端耦合在同一套 PHP 系統中，每次頁面存取都需要後端渲染 HTML、查詢資料庫、載入主題模板，導致首屏載入慢、伺服器壓力大、擴展性受限。而 Nuxt.js + WordPress Headless 架構將兩者徹底解耦：WordPress 退居幕後專注內容管理，Nuxt.js 作為獨立前端接管所有使用者互動與頁面渲染，中間透過 GraphQL 和 REST API 進行安全高效的資料通訊。

一、極致效能：SSR 渲染與增量靜態再生

Nuxt.js 的核心優勢在於伺服器端渲染（SSR）。與純 SPA 應用需要等待 JavaScript 下載、解析、執行後才能渲染頁面不同，SSR 在伺服器端直接生成完整 HTML 回傳給瀏覽器，使用者幾乎在請求發出的瞬間就能看到頁面內容。

本專案進一步引入了 ISR（Incremental Static Regeneration） 機制：

// nuxt.config.ts
routeRules: {
    '/_nuxt/**': {
        isr: 600,
        headers: { 'Cache-Control': 'public, max-age=31536000, immutable' }
    }
}

靜態資源（JS/CSS/字型）被設定為一年的永久快取配合 immutable 標記，檔名自帶 Hash，更新時自動失效。頁面資料則透過 ISR 在 10 分鐘後自動重新生成，既保證了存取速度，又確保內容的新鮮度。

配合 Vite + esbuild 建構工具，程式碼分割和資源內聯策略讓首屏 JS 體積大幅縮減。小於 4KB 的資源自動內聯為 base64，減少 HTTP 請求數；核心依賴透過 optimizeDeps 預打包，避免執行階段重複解析。

二、多層快取體系：從伺服器端到客戶端的完整鏈路

快取是效能最佳化的核心。本專案构建了四層快取體系，層層遞進，確保每一層都發揮最大效能：

第一層：GraphQL SHA-256 回應快取

每個公開 GraphQL 查詢的結果被 SHA-256 雜湊後存入 Nitro Storage，TTL 預設 120 秒。同一查詢在有效期內直接回傳快取結果，零延遲、零 WordPress 負載。

第二層：飛行中請求去重

當快取未命中時，如果有 100 個使用者同時請求同一資料，createInFlightRequestPool 將併發請求合併為一次上游呼叫，其餘 99 個請求共享結果——徹底消除快取擊穿問題。

第三層：LRU 快取預算控制

快取不是無限制的。cache-budget.mjs 實作 LRU 淘汰演算法：當快取條目超過 500 條或總位元組超過 32MB，按「最久未使用」原則自動清理。單條回應上限 256KB，防止大查詢擠佔快取空間。

第四層：客戶端 shallowRef 響應式最佳化

前端使用 shallowRef 而非 ref 儲存 GraphQL 回應資料，避免 Vue 對深層巢狀物件進行遞迴響應式追蹤，顯著降低記憶體佔用和渲染開銷。

三、安全架構：三道防線守護 WordPress 後端

在 Headless 架構中，安全性是首要考量。本專案透過 Nitro 伺服器端构建了三道安全防線：

防線一：API 代理隔離

WordPress 後端位址（wp-admin、wp-json）完全隱藏在 Nitro 代理之後。瀏覽器中只能看到 /api/graphql 和 /api/salong/v1/*，攻擊者無法直接掃描或攻擊 WordPress 端點。

瀏覽器 → /api/graphql → Nitro 伺服器端 → WordPress（內網/白名單）

防線二：認證憑證隔離

使用者登入後，WordPress 頒發的 JWT Token 儲存在伺服器端 Cookie 中，前端 JavaScript 程式碼完全不可見。即使網站遭受 XSS 攻擊，攻擊者也無法竊取認證憑證。

防線三：錯誤訊息過濾

所有代理端點統一使用 normalizeApiError 處理異常，使用者只能看到乾淨的 HTTP 狀態碼和簡短訊息。任何伺服器堆疊追蹤、WordPress 內部錯誤、資料庫連線資訊都不會洩露到前端。

四、內容安全與 XSS 防護

前端渲染 WordPress 內容時，所有使用者生成內容（文章正文、評論等）都經過 DOMPurify 消毒處理：

<div v-safe-html="post.content"></div>

v-safe-html 指令基於 DOMPurify 白名單機制，過濾掉所有危險的 HTML 標籤和事件處理器（如 onerror、javascript: 協定），確保即使後端回傳惡意內容，前端也能安全渲染。

五、壓縮與傳輸最佳化

Nitro 伺服器端在建構時啟用了雙層壓縮：

nitro: {
    compressPublicAssets: {
        gzip: true,
        brotli: true
    }
}

Gzip 提供廣泛相容性，Brotli 在支援的瀏覽器中可額外減少 15-25% 的傳輸體積。配合 minify: true 對伺服器端程式碼進行壓縮，減少冷啟動時間。

靜態資源透過 @nuxt/image 模組自動轉換為 WebP 格式，品質設定為 80，在視覺無損的前提下將圖片體積縮減 50-70%。

六、請求韌性與容錯

上游 WordPress 可能偶發 429 限流或臨時故障。request-resilience.mjs 提供兩組容錯工具：

• runWithRetry：關鍵請求自動重試，指數退避延遲，預設重試 1 次，間隔 150ms 起步
• runNonCriticalAsync：非關鍵請求（如側邊欄熱門文章）遇到 429 直接使用預設降級資料，不阻塞頁面渲染

這種設計確保了核心頁面永遠可存取，非核心內容在極端情況下優雅降級。

七、SEO 與搜尋引擎友善

SSR 渲染天然對搜尋引擎友善——爬蟲抓取到的是完整 HTML，而非空殼 SPA。配合 @nuxtjs/seo 模組，專案內建了：

• Schema.org 結構化資料標記（Organization 等）
• XML Sitemap 自動生成
• robots.txt 自訂爬蟲規則
• 鏈路檢查器，建構時自動檢測死鏈
• llms.txt 為 AI 模型提供站台說明

八、多租戶與可擴展性

一套程式碼支援多個客戶站台獨立建構和部署，每個租戶擁有獨立的環境變數、網域和設定。透過 Python 建構腳本實現自動化批次建構，目前已服務於龍霄、薩龍網路、念山川旅行、AceMath 等多個站台。

總結

Nuxt.js + WordPress Headless 架構不是簡單的技術堆砌，而是在效能、安全、可維護性之間做出的系統性工程決策：

這套架構讓 WordPress 回歸它最擅長的事情——內容管理，而將效能、安全和使用者體驗交給 Nuxt.js 來保障。