為什麼您的WordPress網站速度慢以及Next.js如何修復它
你的 WordPress 網站為什麼很慢，以及 Next.js 如何修復它
我多年來審計了數百個 WordPress 網站，談話通常以相同的方式開始：「我們安裝了快取外掛，但我們的分數仍然很糟糕。」WordPress 生態系統中沒有人想承認的真相是，大多數性能問題無法透過外掛修復。它們是架構性的問題。WordPress 在 2003 年為使用 PHP 呈現部落格文章而建立。現在是 2025 年，我們要求它為複雜的行銷網站、電子商務平台和網路應用程式提供支援——同時 Google 的 Core Web Vitals 越來越多地決定是否有人能夠找到你的內容。
本文確切說明了 WordPress 網站為什麼很慢，將每個問題對應到遭受影響的 Core Web Vitals 指標，並向你展示無頭 Next.js 架構如何從根本上修復它們。不是用 band-aids。而是從根本上。
目錄
- 理解 2025 年的 Core Web Vitals
- WordPress 在架構上為什麼很慢
- 外掛膨脹：沉默的性能殺手
- 外掛無法修復的資料庫查詢問題
- WordPress 主機託管：你可能為平庸支付過高費用
- Next.js 如何修復每個 Core Web Vital
- 無頭架構：WordPress 作為 CMS，Next.js 作為前端
- 真實性能基準：WordPress vs Next.js
- 遷移路徑：從單體 WordPress 到無頭 Next.js
- 常見問題
理解 2025 年的 Core Web Vitals
Google 在 2024 年 3 月更新了其 Core Web Vitals，用互動到下一步繪製 (INP) 取代了首次輸入延遲 (FID)。這個改變的重要性遠超大多數人的認識。以下是決定你網站性能等級的四個指標：
| 指標 | 測量內容 | 良好 | 需要改進 | 較差 |
|---|---|---|---|---|
| LCP（最大內容繪製） | 你的主要內容載入速度 | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP（互動到下一步繪製） | 對使用者輸入的回應速度 | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS（累積布局偏移） | 載入期間的視覺穩定性 | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
| TTFB（首位元組時間） | 伺服器回應時間 | ≤ 800ms | 800ms – 1800ms | > 1800ms |
根據 2025 年初的 Chrome UX 報告，僅有 42% 的 WordPress 來源通過所有三個 Core Web Vitals 閾值。與此相比，67% 的 Next.js 驅動的來源能通過。這不是邊際差異——這是兩個不同的領域。
為什麼這些指標實際上很重要
Google 已經很清楚：Core Web Vitals 是排名信號。但除了 SEO，這些指標與轉換率直接相關。沃達豐發現 LCP 改進 31% 導致銷售增加 8%。Shopify 的內部資料顯示，每減少 100ms 頁面載入時間，轉換增加 1.3%。
你的 WordPress 網站不僅很慢。它在讓你損失金錢。
WordPress 在架構上為什麼很慢
讓我向你介紹當有人訪問典型 WordPress 頁面時發生的情況：
- DNS 查詢 → 解析你的域名
- TCP/TLS 握手 → 建立安全連線
- 請求到達伺服器 → Apache/Nginx 接收它
- PHP 啟動 WordPress → 載入
wp-config.php，初始化 WordPress 核心 - 外掛初始化 → 每個活躍外掛連結到
init、wp_loaded等 - 主題載入 →
functions.php執行，範本階層解決 - 資料庫查詢執行 → WP_Query 執行，通常每頁 30-100+ 個查詢
- PHP 呈現 HTML → 範本文件生成完整頁面
- HTML 發送到瀏覽器 → 最後，回應開始
- 瀏覽器解析 HTML → 發現 CSS、JS、字體、圖像
- 渲染阻止資源載入 → 來自 15 個不同外掛的樣式表
- 頁面最終呈現 → 使用者看到內容
步驟 4 到 9 發生在每個未快取的請求中。這是 PHP 解析 200+ 個文件，執行數十個資料庫查詢，並生成 HTML——所有這些都發生在瀏覽器獲得單一位元組之前。
PHP 問題
PHP 8.3 明顯快於 PHP 7.x，大多數 WordPress 主機現在都支援它。但即使使用 PHP 8.3 和 OPcache 啟用，你仍在執行同步、阻止的過程。WordPress 核心在每個請求上載入大約 100,000 行 PHP 代碼。添加 WooCommerce，你就超過 400,000 行。
問題在於：快取外掛如 WP Super Cache 或 W3 Total Cache 的工作原理是透過短路這個過程——它們改為提供預生成的 HTML 文件。但它們引入了自己的複雜性，與個性化內容不相容，仍然無法修復瀏覽器中發生的情況。
主題問題
大多數 WordPress 主題為了靈活性而建立，而不是為了性能。像 Avada、Divi 或 Elementor 這樣的主題在每個頁面上載入其整個 CSS 和 JavaScript 框架，無論你是否使用這些功能。我見過在簡單部落格文章上載入 2.5MB CSS 和 1.8MB JavaScript 的 Elementor 網站。
<!-- 頁面建立工具網站上典型的 WordPress head -->
<link rel="stylesheet" href="/wp-content/plugins/elementor/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/plugins/elementor-pro/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/style.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/theme.min.css">
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css">
<link rel="stylesheet" href="/wp-content/plugins/woocommerce/assets/css/woocommerce.css">
<!-- ... 還有 12 個樣式表 -->
這些中的每一個都是渲染阻止資源。在所有這些被下載和解析之前，你的 LCP 無法發生。
外掛膨脹：沉默的性能殺手
平均 WordPress 網站執行 20-30 個外掛。我見過有 70+ 個外掛的網站。每個外掛可能：
- 添加自己的 CSS 和 JS 文件（通常在每個頁面上，即使是不用的地方）
- 註冊在每個請求上執行的 WordPress 連結
- 執行自己的資料庫查詢
- 在啟動階段載入自己的 PHP 文件
- 向
<head>添加內嵌腳本和樣式
一個真實例子
我最近審計了執行 WordPress 有 34 個活躍外掛的行銷網站。以下是網路瀑布圖的樣子：
- 47 個 CSS 文件在主頁上載入
- 38 個 JavaScript 文件在主頁上載入
- 總頁面重量：4.7MB
- 總請求數：127
- LCP：在 4G 上 6.8 秒
- TTFB：2.1 秒
客戶已經安裝了一個優化外掛 (Autoptimize) 和一個快取外掛 (LiteSpeed Cache)。即使兩者都啟用，LCP 也是 4.2 秒。仍然失敗。
核心問題？你無法優化掉載入不需要的代碼的根本問題。縮小和組合 47 個 CSS 文件仍然會留下一個龐大的 CSS 負荷，阻止呈現。
外掛依賴陷阱
這使情況變得更糟：外掛相互依賴。你安裝 WooCommerce，然後你需要支付網關外掛，然後需要運費計算器外掛，然後需要產品篩選器外掛。每一個都增加重量。你無法移除其中任何一個而不破壞功能。
這是 WordPress 陷阱。架構鼓勵為一切添加外掛，沒有機制來樹搖未使用的代碼。
外掛無法修復的資料庫查詢問題
WordPress 使用具有臭名昭著的平面結構的單一 MySQL 資料庫。wp_options 表在每個請求上都載入了 autoload='yes' 條目。我見過 wp_options 表有 3,000+ 自動載入行，總共 8MB 資料。
-- 檢查你的自動載入選項大小
SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload = 'yes';
-- 如果這回傳 > 1MB，你有問題
wp_postmeta 表是另一個噩夢。它將所有內容儲存為鍵值對，這意味著 WordPress 無法進行有效的查詢。想找到所有低於 50 美元的產品？那是在 wp_postmeta 上的 JOIN，在儲存數字的文本欄位上進行字符串比較。沒有索引能救你。
查詢計數現實檢查
在你的 WordPress 網站上安裝 Query Monitor 外掛並查看查詢計數。一個「簡單的」WooCommerce 產品頁面通常執行 150-300 個資料庫查詢。一個有相關文章、熱門文章邊欄和麵包屑導航的部落格文章？通常 80-120 個查詢。
比較無頭方法，你的 Next.js 前端進行恰好一個 API 呼叫（或零個，如果使用靜態生成）來獲取它需要的所有資料。
WordPress 主機託管：你可能為平庸支付過高費用
讓我們談論主機託管，因為這是很多錢被浪費的地方。
| 主機類型 | 月費用 | 典型 TTFB | 能修復架構嗎？ |
|---|---|---|---|
| 共享 (GoDaddy, Bluehost) | $3-15 | 1.5-4.0s | 否 |
| 受管 WordPress (WP Engine, Flywheel) | $25-300 | 400ms-1.2s | 否 |
| 高級受管 (Kinsta, Pagely) | $35-600 | 200ms-600ms | 否 |
| VPS/專用 (DigitalOcean, AWS) | $20-500 | 200ms-800ms | 否 |
| Vercel/Edge 上的 Next.js | $0-20 | 50-150ms | 是 |
注意最後一欄。沒有主機升級能修復架構問題。你正在支付高級價格來讓 PHP 執行更快，而真正的解決方案是根本不在每個請求上執行 PHP。
Kinsta 在他們的入門計畫上為 25,000 次訪問收費 $35/月。Vercel 的免費層處理 100GB 頻寬。甚至 Vercel 的 Pro 計畫在 $20/月 也給你跨其全球 CDN 的邊界部署。數字不會說謊。
Next.js 如何修復每個 Core Web Vital
讓我們變得具體。以下是 Next.js（尤其是 Next.js 14/15 中的 App Router）如何解決每個指標：
修復 TTFB
Next.js 給你多個呈現策略：
// 靜態生成 - TTFB 實際上為零（從 CDN 提供）
export default async function BlogPost({ params }: { params: { slug: string } }) {
const post = await getPost(params.slug);
return <Article post={post} />;
}
// 這在建置時預渲染
export async function generateStaticParams() {
const posts = await getAllPosts();
return posts.map((post) => ({ slug: post.slug }));
}
透過靜態生成，你的頁面是預建的 HTML 文件，從世界各地的邊界 CDN 節點提供。TTFB 降低到 50-100ms，無論使用者在哪裡。沒有 PHP 執行，沒有資料庫查詢，沒有請求時的伺服器端處理。
對於動態內容，Next.js 支援 ISR（增量靜態再生），它在背景中提供快取的靜態頁面同時重新驗證：
// 每 60 秒重新驗證一次
export const revalidate = 60;
修復 LCP
Next.js 包含處理 WordPress 外掛嘗試（但失敗）做的所有事情的 <Image> 元件：
import Image from 'next/image';
export default function HeroBanner() {
return (
<Image
src="/hero.jpg"
alt="Hero banner"
width={1200}
height={600}
priority // 預載入 LCP 圖像
sizes="100vw"
// 自動生成 srcset，使用 WebP/AVIF，
// 預設為延遲載入，防止 CLS
/>
);
}
priority 屬性告訴 Next.js 預載入圖像，直接改進 LCP。自動格式談判為支援的瀏覽器提供 WebP 或 AVIF，相比 JPEG 減少 30-50% 的圖像大小。無需外掛。
Next.js 還透過 CSS 模組和自動關鍵 CSS 提取消除了渲染阻止 CSS。只有特定頁面使用的 CSS 才會載入。
修復 INP
INP 測量你的網站對使用者互動的回應速度。WordPress 網站失敗 INP 是因為：
- 來自外掛的重型 JavaScript 阻止主執行緒
- jQuery 和其外掛爭奪執行時間
- 無代碼分割——所有內容都預先載入
Next.js 透過自動代碼分割處理這個問題。每個頁面只載入它需要的 JavaScript：
// 這個元件只在使用者向下捲動到它時載入
import dynamic from 'next/dynamic';
const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
loading: () => <ChartSkeleton />,
ssr: false, // 不在伺服器上呈現
});
React 伺服器元件（App Router 中的預設值）甚至更進一步：不需要互動的元件向瀏覽器發送零 JavaScript。一個沒有互動元素的部落格文章？零 KB 的元件 JavaScript。
修復 CLS
WordPress 中的 CLS 通常來自：
- 沒有明確尺寸的圖像
- 遲到的廣告將內容向下推動
- Web 字體造成 FOUT/FOIT
- 外掛注入的橫幅在載入後出現
Next.js 預設防止 CLS。<Image> 元件需要尺寸（或使用 fill 與調整大小的容器）。next/font 模組內嵌字體聲明並使用 font-display: swap 且零布局偏移：
import { Inter } from 'next/font/google';
const inter = Inter({ subsets: ['latin'] });
export default function RootLayout({ children }) {
return (
<html lang="en" className={inter.className}>
<body>{children}</body>
</html>
);
}
無 FOUT。無來自字體的布局偏移。它只是起作用。
無頭架構：WordPress 作為 CMS，Next.js 作為前端
許多人遺漏了這一點：無頭並不意味著放棄 WordPress。這意味著使用 WordPress 做它實際擅長的事情——內容管理——同時讓 Next.js 處理前端。
架構看起來像這樣：
[WordPress 管理員] → [REST API / WPGraphQL] → [Next.js 前端] → [Vercel 邊界 CDN]
↑ ↑
內容編輯者 你的使用者
使用熟悉的 從邊界得到
WP 儀表板 快速頁面
你的內容團隊保持他們的工作流程。你的使用者得到一個快速網站。你得到乾淨、易維護的代碼。
我們在我們的 Next.js 開發實踐 和 無頭 CMS 開發 中做了大量這類工作。這個模式是完善的和經過戰鬥測試的。
其他無頭 CMS 選項呢？
WordPress 不是內容層的唯一選項。如果你從零開始，像 Sanity、Contentful 或 Storyblok 這樣的目標建築無頭 CMS 平台通常是更好的選擇。它們是以 API-first 方式建立的，所以沒有遺留包袱。
但如果你在 WordPress 中有多年的內容和在其上培訓的團隊，無頭 WordPress with WPGraphQL 是完全有效的方法。
真實性能基準：WordPress vs Next.js
這是我們做過的遷移和公開可用案例研究的真實數字：
| 指標 | WordPress（優化） | Next.js（靜態） | 改進 |
|---|---|---|---|
| TTFB | 650ms | 80ms | 快 87% |
| LCP | 3.8s | 1.2s | 快 68% |
| INP | 380ms | 90ms | 快 76% |
| CLS | 0.18 | 0.01 | 改進 94% |
| 頁面重量 | 3.2MB | 450KB | 輕 86% |
| 請求 | 85 | 12 | 少 86% |
| Lighthouse 分數 | 45-65 | 95-100 | 天壤之別 |
「優化的」WordPress 意味著：PHP 8.3、Redis 物件快取、CDN、圖像優化外掛、快取外掛、資料庫優化。所有你應該做的事情。而它仍然不接近。
遷移路徑：從單體 WordPress 到無頭 Next.js
遷移不必是全有或全無。以下是我們通常建議的分階段方法：
第 1 階段：評估（1-2 週）
- 使用 PageSpeed Insights 和 CrUX 資料審計當前 WordPress 網站性能
- 清點所有外掛並將其對應到前端 vs. 後端功能
- 識別內容模型和自訂欄位
- 評估是否保持 WordPress 作為無頭 CMS 或完全遷移內容
第 2 階段：前端建置（4-8 週）
- 使用 App Router 設置 Next.js 專案
- 在 WordPress 上安裝和配置 WPGraphQL
- 建置匹配當前設計的元件庫（或重新設計——這是個好時機）
- 為內容頁面實現靜態生成
- 為內容編輯者設置預覽模式
第 3 階段：啟動和重新導向（1-2 週）
- 將 Next.js 前端部署到 Vercel（或 Netlify、Cloudflare Pages）
- 配置 DNS 和重新導向
- 驗證所有 URL 都正確重新導向（SEO 保留很重要）
- 鎖定 WordPress 管理員（移除公開訪問）
第 4 階段：優化（持續）
- 在 Google Search Console 中監控 Core Web Vitals
- 微調 ISR 重新驗證間隔
- 添加邊界中介軟體以實現個性化
- 如果 WordPress 變成瓶頸，考慮遷移到目標建築無頭 CMS
如果你考慮這種遷移，你可以查看我們的 定價頁面 以獲得概算數字，或 直接聯絡 以討論你的具體情況。
對於使用 Astro 而不是 Next.js 建置的網站（特別是內容豐富的部落格和行銷網站），我們也有 Astro 開發實踐，為首先靜態的網站提供更激進的性能。
常見問題
我能在不切換到 Next.js 的情況下加快 WordPress 速度嗎？ 是的，在某種程度上。從優質主機開始（Kinsta 或 Cloudways），啟用 Redis 物件快取，使用輕量級主題如 GeneratePress，將外掛減少到 15 以下，並配置 CDN。你可以以這種方式將 WordPress 網站帶入 Core Web Vitals 的「需要改進」範圍。但要與所有指標一致地進入「良好」範圍——特別是 INP——使用傳統 WordPress 架構極其困難。
從 WordPress 遷移到無頭 Next.js 要花多少錢？ 這取決於網站的複雜性。一個簡單的行銷網站（10-30 頁、部落格）通常對完整遷移執行 $15,000-$40,000。使用 WooCommerce 的電子商務網站更複雜，範圍從 $50,000-$150,000+。ROI 通常來自改進的轉換率和減少的主機成本。我們的 定價頁面 有更多細節。
如果我切換到 Next.js，我的 SEO 排名會下降嗎？ 不會，如果你正確處理遷移。適當的 301 重新導向、相同的 URL 結構（或對應的重新導向）、有效的中繼標籤、結構化資料和 XML 站點地圖都是必要的。Next.js 實際上有 SEO 優勢——更快的 Core Web Vitals 直接改進排名，而 Metadata API 使以程式方式管理中繼標籤變得容易。大多數網站在遷移後 2-3 個月內看到排名改進。
如果我們採用無頭，內容編輯者會失去 WordPress 管理員嗎？ 不會。在無頭設置中，WordPress 繼續作為內容管理後端。編輯者使用相同的儀表板、相同的編輯者、相同的工作流程。他們只是看不到前端主題——相反，他們使用一個預覽按鈕，顯示 Next.js 呈現的版本。有些團隊發現這實際上更好，因為預覽是生產網站的準確表示。
WooCommerce 呢——Next.js 能處理電子商務嗎？ 是的，但這是一個更大的專案。你可以透過其 REST API 或 WPGraphQL WooCommerce 擴展以無頭方式使用 WooCommerce。或者，許多團隊遷移到 Shopify 的 Storefront API 或 Saleor 用於商務後端，使用 Next.js 作為前端。結帳流程需要小心處理，因為它涉及支付處理和 PCI 合規性。它是可做到的，但計劃額外的開發時間。
Next.js 是快速前端的唯一選項嗎？ 不是。Astro、Remix、SvelteKit，甚至 Nuxt（用於 Vue 團隊）都是可行的。Astro 特別適合內容豐富的網站，因為它預設發送零 JavaScript。Next.js 贏得需要顯著互動、動態功能或電子商務的網站。我們根據專案的需求與 Next.js 和 Astro 都合作。
增量靜態再生 (ISR) 如何與 WordPress 內容配合？ 當你在 WordPress 中發佈或更新文章時，webhook 觸發並告訴你的 Next.js 部署重新驗證該特定頁面。下一個訪客得到一個新生成的靜態頁面，然後在邊界快取。重新驗證發生在背景中，所以使用者永遠不用等待建置。你也可以設置基於時間的重新驗證（例如，每 60 秒重建一次）作為後備。
團隊在無頭化時犯的最大錯誤是什麼？ 試圖在 Next.js 中 1:1 複製他們的 WordPress 網站。無頭遷移是重新考慮你的內容架構、簡化你的頁面結構並消除多年累積的雜亂的機會。透過將其視為新開始——保持內容但重新考慮呈現——結束時獲得的團隊結果比試圖從舊主題複製每個小部件和邊欄的團隊戲劇性得多。