上季度，我們接手了一個項目，它完美地說明了為什麼 WordPress 並不總是正確的選擇。SleepDr.com — 一個擁有 228 篇部落格文章、聯繫表單和行動版 Lighthouse 評分為 35 的睡眠健康內容網站 — 急切地尋求我們幫助提升速度。他們的自然流量已經下滑了幾個月。Google 在 2026 年 3 月推出的核心更新引入了整體網站範圍的核心網頁指標評分，對他們造成了沉重打擊。每篇緩慢的部落格文章都在拖累整個域名的表現。

我們將其遷移到 Next.js 15 + Payload CMS 3 + Supabase + Vercel。結果：行動版 Lighthouse 94，桌面版 99。自然流量在 6 週內恢復。這是我們如何實現的完整故事 — 每一項優化、每一個指標、每一個決策 — 以便你可以將相同的思路應用到你自己的項目中。

目錄

SleepDr 案例研究：WordPress 到 Next.js 遷移 (Lighthouse 35→94)

之前：為什麼 WordPress 正在傷害 SleepDr

SleepDr 的 WordPress 設置是積累技術債務的教科書範例。三年來，他們安裝了 34 個外掛。主題加載了 jQuery 加上另外兩個 JavaScript 函式庫。每個頁面請求都會擊中 MySQL 資料庫、動態生成 HTML，並通過已經在負載下掙扎的共享主機方案提供未優化的圖片。

以下是行動版初始 Lighthouse 審計的結果：

  • 總體評分：35（紅色，不合格）
  • FCP：4.2 秒
  • LCP：6.8 秒 — 幾乎是「良好」閾值的三倍
  • CLS：0.28 — 由於廣告、沒有尺寸的圖片和網頁字體加載，佈局到處跳動
  • TBT：1,200ms — 主線程被鎖定超過一秒
  • TTFB：2.1 秒 — 伺服器本身在任何內容呈現之前就很慢

這個網站不只是慢。它對行動裝置上的用戶非常不友善。由於 Google 的 Lighthouse 行動模擬模仿了中檔手機在限流 4G 連接上的表現，評分反映了不理想條件下真實用戶的體驗。

在 Google 的 2026 年 3 月核心更新引入整體 CWV 評分後 — 跨整個域名聚合效能而非按頁面 — SleepDr 的 228 篇緩慢部落格文章正在毒害他們的整個網站排名。來自推出的早期數據顯示，受影響網站的流量下降了 20-35%。SleepDr 看到大約 30% 的下降。

必須做出改變。

遷移堆棧：為什麼我們選擇了這些技術

我們沒有選擇這個堆棧因為它很流行。我們選擇它是因為每個部分都解決了 SleepDr 的一個特定問題。

  • Next.js 15 (App Router)：混合渲染。為部落格文章進行靜態生成，必要時進行伺服器端渲染。React 伺服器元件以最小化客戶端 JavaScript。這是我們的核心業務 — 我們已經通過我們的 Next.js 開發實踐構建了數十個項目。
  • Payload CMS 3：自託管無頭 CMS，為 SleepDr 的內容團隊提供了他們習慣於 WordPress 的相同編輯體驗，但沒有臃腫。我們處理了很多 無頭 CMS 實現，Payload 3 已成為我們對內容繁重網站的首選。
  • Supabase：帶有實時功能的 PostgreSQL 資料庫。處理聯繫表單提交、分析事件和任何動態資料。
  • Vercel：邊緣部署。該網站從最接近用戶的節點提供。TTFB 變得幾乎可以忽略。

整個遷移花費了 7 週。內容遷移 — 全部 228 篇文章及其圖片、中繼資料和 URL 結構 — 花費了大約 2 週的時間。我們編寫了一個自定義腳本來從 WordPress REST API 提取內容、轉換它，並將其推送到 Payload CMS。

遷移前後：數據

以下是完整的分解。這些是 Lighthouse 行動版評分，這是真正故事所在的地方。

指標 遷移前 (WordPress) 遷移後 (Next.js 15) 改進
首次內容繪製 (FCP) 4.2s 1.1s -3.1s (快 74%)
最大內容繪製 (LCP) 6.8s 1.8s -5.0s (快 74%)
累積佈局偏移 (CLS) 0.28 0.01 -0.27 (減少 96%)
總阻塞時間 (TBT) 1,200ms 50ms -1,150ms (減少 96%)
首字節時間 (TTFB) 2.1s 0.3s -1.8s (快 85%)
整體行動版評分 35 94 +59 分
整體桌面版評分 61 99 +38 分

我想說清楚：這些不是從單一頁面挑選的數字。我們在 20 個代表性頁面上運行了 Lighthouse 並平均了結果。行動版評分在所有測試頁面上範圍從 91 到 97。桌面版是 97 到 100。

現在讓我詳細介紹我們如何實現這些改進中的每一個。

SleepDr 案例研究：WordPress 到 Next.js 遷移 (Lighthouse 35→94) - 架構

優化 1：圖片優化 (LCP -3s)

圖片是舊網站上最大的單一效能殺手。SleepDr 的部落格文章大量使用產品攝影和信息圖表 — 通常以完整解析度 PNG 的形式直接從設計師的機器上傳。某些圖片達 3-4MB。

我們所做的事

為每一張圖片使用 next/image。 此元件執行大量繁重的工作：

import Image from 'next/image';

export function HeroImage({ src, alt }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={1200}
      height={630}
      priority // 首屏英雄圖：預加載它
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
      quality={80}
    />
  );
}

以下是 next/image 自動處理的內容：

  • 格式轉換：提供 WebP（或支援的 AVIF）而非 PNG/JPEG。僅此一項就將圖片大小減少了 60-80%。
  • 回應式 srcset：生成多個大小，因此行動用戶不會下載桌面大小的圖片。
  • 預設延遲加載：折頁下方的圖片在用戶滾動時才加載。
  • 明確尺寸：width 和 height 屬性在佈局中保留空間，直接修復 CLS。

關鍵洞察：LCP 元素的優先加載

英雄圖上的 priority 屬性是關鍵。沒有它，Next.js 會延遲加載圖片。但如果英雄圖片是 LCP 元素 — 這在 SleepDr 的大多數頁面上都是如此 — 延遲加載它實際上會傷害你的 LCP 評分。你希望它立即開始下載。

我們審計了每個頁面範本，識別了 LCP 元素，並用 priority 標記它。部落格文章頁面使用特色圖片。主頁使用英雄橫幅。簡單，但它在 LCP 上產生了 3 秒的差異。

圖片 CDN

Vercel 的內置圖片優化用作 CDN。圖片在首次請求時在邊緣被處理並緩存。後續訪問者在毫秒內獲得緩存的優化版本。無需 Cloudinary 訂閱。無需 WordPress 外掛嘗試做相同的事情但效果更差。

淨影響：LCP 從圖片優化單獨下降從 6.8s 到大約 3.8s。剩餘的 LCP 收益來自 TTFB 改進和字體加載。

優化 2：字體優化 (FCP -1.5s)

SleepDr 的 WordPress 主題通過外部樣式表連結加載三個 Google 字體。每個都是對 fonts.googleapis.com 的渲染阻塞請求，隨後是對 fonts.gstatic.com 的另一個請求用於實際字體文件。那是六個網絡往返，然後瀏覽器才能繪製文本。

我們所做的事

使用 next/font 自託管字體：

import { Inter, Merriweather } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
});

const merriweather = Merriweather({
  weight: ['400', '700'],
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-merriweather',
});

next/font 的不同之處：

  • 自託管字體文件：無外部網絡請求。字體與構建捆綁在一起並從相同的 CDN 提供。
  • 自動子集設置：僅包含你實際需要的字符集。Inter 的拉丁子集約 20KB，而非完整的 100KB+ 文件。
  • display: 'swap'：文本使用後備字體立即呈現，然後在網頁字體加載時交換。無不可見文本。無阻塞 FCP 的樣式無內容閃爍。
  • CSS 變數注入：字體通過 CSS 自定義屬性應用，這意味著當字體交換時零佈局偏移，因為我們仔細匹配了後備字體指標。

我們也完全放棄了第三種字體。舊網站為標題使用了一種裝飾字體，增加了視覺雜亂但沒有改善可讀性。兩種字體。就這樣。

淨影響：FCP 從消除渲染阻塞字體請求改進了約 1.5 秒。

優化 3：JavaScript 減少 (TBT 1200ms → 50ms)

這是最戲劇性的單一改進。1,200ms 的 TBT 意味著瀏覽器主線程被阻塞超過整整一秒 — 在這段時間內，用戶無法點擊、滾動或與任何內容互動。

所有那些 JavaScript 來自哪裡？

WordPress 網站加載了：

  • jQuery (87KB 縮小) — 由主題和大多數外掛使用
  • 34 個外掛腳本 — 聯繫表單、分析、社交分享、cookie 同意、兩個不同的滑塊函式庫、一個燈箱和更多
  • 主題 JavaScript — 菜單切換和動畫函式庫的另外 150KB
  • 內聯腳本 — 來自各種外掛的隨機代碼片段注入到 <head> 中

頁面加載時的總 JavaScript：大約 1.8MB。在限流行動連接上，解析和執行該需要超過一秒。

我們所做的事

零 jQuery。 Next.js 使用 React。我們不需要 jQuery。

零外掛。 每個功能都被重建為目的構建的元件：

  • 聯繫表單：4KB React 元件 + Supabase 伺服器操作
  • Cookie 同意：2KB 元件搭配 next/script 策略
  • 社交分享：原生 Web Share API，具有回退連結 — 無需函式庫
  • 分析：輕量級 Plausible 腳本 (< 1KB)

為折頁下方的任何內容動態導入：

import dynamic from 'next/dynamic';

const NewsletterSignup = dynamic(
  () => import('@/components/NewsletterSignup'),
  { ssr: false } // 僅在客戶端上加載，僅在需要時加載
);

const RelatedPosts = dynamic(
  () => import('@/components/RelatedPosts')
);

React 伺服器元件處理了大多數渲染。部落格文章內容、頁頭、頁腳、導航 — 全部伺服器渲染，零客戶端 JavaScript。只有互動元素（行動菜單切換、聯繫表單、新聞通訊註冊）向瀏覽器傳送 JS。

頁面加載時的總 JavaScript 在遷移後：大約 85KB。那是 95% 的減少。

淨影響：TBT 從 1,200ms 下降到 50ms。 主線程基本上是空閒的。

優化 4：伺服器端渲染和邊緣部署 (TTFB -85%)

TTFB 測量伺服器開始發送回應的第一個字節需要多長時間。SleepDr 的 WordPress 網站在行動版上有 2.1 秒的 TTFB。這意味著在任何事能發生之前 — 在圖片加載之前、在字體下載之前、在 JavaScript 執行之前 — 用戶在等待伺服器回應時盯著空白屏幕超過兩秒。

為什麼 WordPress 這麼慢

WordPress 上的每個頁面請求：

  1. 擊中共享主機伺服器（已經很慢）
  2. 加載 PHP
  3. 執行 WordPress 核心
  4. 運行通過 34 個外掛鉤
  5. 查詢 MySQL 多次
  6. 動態生成 HTML
  7. 發送回應

即使安裝了 WP Super Cache，緩存命中率也不一致，伺服器本身也很低功率。

我們所做的事

為所有 228 篇部落格文章進行靜態生成。 在構建時，Next.js 預先呈現每篇部落格文章為靜態 HTML。結果是一組 .html 文件位於 Vercel 的邊緣網絡上 — 分佈在 80+ 個全球位置。

當用戶請求部落格文章時，他們從最近的邊緣節點提供預先構建的 HTML 文件。無資料庫查詢。無伺服器端處理。只是從 CDN 讀取文件。

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await payload.find({
    collection: 'posts',
    limit: 300,
  });

  return posts.docs.map((post) => ({
    slug: post.slug,
  }));
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug } },
    limit: 1,
  });

  return <ArticleLayout post={post.docs[0]} />;
}

對於聯繫表單頁面，我們使用伺服器端渲染因為它需要動態行為。但即使 Vercel 邊緣函式上的 SSR 也在 100ms 以內運行，因為計算發生在邊緣，而非在集中資料中心。

淨影響：TTFB 從 2.1s 下降到 0.3s — 85% 的改進。在重複訪問時帶緩存，它更接近 50ms。

優化 5：第三方腳本管理

第三方腳本是網頁效能的無聲殺手。SleepDr 的 WordPress 網站加載了 Google Analytics (GA4)、Google Tag Manager、Facebook 像素、Hotjar 錄製腳本和 cookie 同意管理器 — 全部在 <head> 中渲染阻塞。

我們所做的事

Next.js 提供了 next/script 元件，具有加載策略。我們有意使用它們：

import Script from 'next/script';

{/* 分析：在頁面變為互動後加載 */}
<Script
  src="https://plausible.io/js/script.js"
  strategy="afterInteractive"
  data-domain="sleepdr.com"
/>

{/* Cookie 同意：在瀏覽器空閒時加載 */}
<Script
  src="/scripts/cookie-consent.js"
  strategy="lazyOnload"
/>

afterInteractive 策略在 Next.js 水合完成後加載腳本。用戶已經可以看到並與頁面互動。lazyOnload 策略等待直到瀏覽器完全空閒 — 對於非關鍵腳本很棒。

我們也用 Plausible 替換了 Google Analytics（< 1KB，隱私中心，在大多數司法管轄區無需 cookie 同意）。完全移除了 Hotjar — SleepDr 實際上沒有在審查錄製。移除了 Facebook 像素因為他們已經停止運行 Facebook 廣告六個月了。

殺死不必要的第三方腳本是網頁開發中最簡單的效能勝利。我一直在說這個。大多數網站加載沒有人在團隊中積極使用的服務的腳本。

優化 6：CSS 優化 (800KB → 35KB)

SleepDr 的 WordPress 主題附帶了約 800KB 的 CSS。這包括主題的樣式表、外掛樣式表、完整 Bootstrap 網格系統（未使用）和 Font Awesome（用於約 12 個圖標）。

我們所做的事

Tailwind CSS，帶有自動清除。 Tailwind 在構建時掃描你的範本文件，並只為你實際使用的實用程式類生成 CSS。我們的生產 CSS 捆綁：35KB（gzip：~8KB）。

// tailwind.config.ts
export default {
  content: [
    './app/**/*.{ts,tsx}',
    './components/**/*.{ts,tsx}',
  ],
  theme: {
    extend: {
      fontFamily: {
        sans: ['var(--font-inter)'],
        serif: ['var(--font-merriweather)'],
      },
    },
  },
};

對於 12 個圖標，我們使用了內聯 SVG。無圖標函式庫。每個 SVG 約 500 字節。總圖標重量：~6KB，相比之下 Font Awesome 的 70KB+。

結果是零渲染阻塞 CSS 請求。Tailwind 的輸出通過 Next.js 內聯在初始 HTML 有效負載中，因此瀏覽器可以立即開始呈現。

淨影響：CSS 減少 96%，有助於 FCP 和 TBT 改進。

逐步檢查清單

如果你面臨類似的效能問題，這是我建議按照順序解決的確切事項。這是按影響對工作比例優先順序排列的。

階段 1：快速勝利 (第 1 週)

  • 在 10 個最高流量頁面上運行 Lighthouse（行動模式）
  • 識別每個頁面範本上的 LCP 元素
  • 為所有圖片和 iframe 添加明確的 width 和 height
  • 為折頁下方的圖片添加 loading="lazy"
  • 為 LCP 圖片添加 fetchpriority="high"
  • 審計第三方腳本 — 移除任何未使用的
  • 將剩餘第三方腳本移至 async 或 defer

階段 2：字體和 CSS (第 2 週)

  • 自託管網頁字體（消除外部字體請求）
  • 為所有 @font-face 聲明添加 font-display: swap
  • 子集字體為只需要的字符集
  • 審計 CSS — 移除未使用的樣式表
  • 用內聯 SVG 替換圖標字體

階段 3：JavaScript (第 3 週)

  • 捆綁分析以識別最大的 JS 依賴
  • 盡可能移除 jQuery
  • 動態導入非關鍵元件
  • 延遲非必要的 JavaScript
  • 實現每條路線的代碼分割

階段 4：基礎設施 (第 4 週+)

  • 評估 CDN/邊緣部署選項
  • 為內容頁面實現靜態生成
  • 設置適當的緩存頭
  • 如果 WordPress 是瓶頸，考慮完全遷移到現代框架

如果你在考慮最後一點 — 完全遷移 — 與我們聯繫。我們已經做過這個確切的項目許多次。我們的 定價頁面詳細介紹了無頭遷移通常花費多少。

2026 核心網頁指標對你的網站意味著什麼

Google 的 2026 年 3 月核心更新改變了遊戲。CWV 不再按頁面評估 — 它跨整個域名聚合，按流量加權。這意味著：

  • 由 200 篇部落格文章使用的單一緩慢頁面範本將坦克你整個網站的排名
  • 高流量頁面在聚合評分中加權更高
  • 你不能只優化你的主頁並稱之為完成

來自推出的早期數據顯示，具有不良 CWV 的網站經歷了 20-35% 的自然流量下降。有些看到超過 50% 的損失。恢復最快的網站是在基礎設施級別解決效能的那些 — 不是通過調整個別頁面，而是通過修復底層架構。

這正是為什麼 SleepDr 的遷移這麼有效。我們沒有優化 228 個個別的 WordPress 頁面。我們重建了整個交付系統，以便每個頁面預設都很快。

對於還沒有準備進行完全遷移的網站，Astro 之類的框架提供了另一條有吸引力的路徑 — 尤其是對於內容繁重的網站，你希望預設接近零 JavaScript。

方法 典型成本 時間表 預期 Lighthouse 增益
WordPress 外掛優化 (WP Rocket, ShortPixel) $100-500/yr 1-2 週 +10-20 分
WordPress 主題替換 $2,000-5,000 2-4 週 +15-25 分
無頭 CMS 遷移 (Next.js/Astro) $15,000-50,000 4-10 週 +30-60 分
完整平台重建 $30,000-100,000+ 8-20 週 +40-65 分

SleepDr 的項目落在 $20,000-25,000 範圍內用於完整遷移，包括所有 228 篇文章的內容傳輸、CMS 設置、自定義元件和效能優化。Vercel 託管在 Pro 方案上運行 $20/月。那大約是 $740/年在託管上，相比他們為無法將 TTFB 保持在 2 秒以下的共享主機支付的 $300/年。

ROI？他們的自然流量在 6 週內恢復並在第 10 週超過衰退前的水準。對於依靠自然搜索的業務，遷移在第一個季度內為自己付費。

常見問題

核心網頁指標改進需要多長時間才能影響 Google 排名？ 根據我們在 SleepDr 和類似項目上的經驗，搜索控制台開始在部署後 28 天內顯示更新的 CWV 數據。排名改進通常在 2-3 個月後跟隨。Google 需要重新爬取你的頁面，從真實 Chrome 用戶（CrUX 數據）收集新的現場數據，並將其納入其排名演算法。不要期望一夜之間的結果 — 但在一個季度內確實期望可測量的改進。

Lighthouse 評分 94 對於真實生產網站是否真的可以實現？ 是的，但它需要從一開始進行有意的架構選擇。在行動版上超過 90 的實驗室評分可以用現代框架如 Next.js 或 Astro 實現，當你控制第三方腳本、正確優化圖片並在邊緣網絡上部署時。關鍵是每個元件必須是效能感知的。一個壞的嵌入或未優化的第三方小工具可以將你打回到 70。

我需要從 WordPress 遷移才能獲得良好的核心網頁指標評分嗎？ 不一定。WordPress 網站可以用正確的主題、激進的緩存（WP Rocket + Cloudflare）、優化的主機（Kinsta, WP Engine）和最少的外掛評分良好。實際上，大多數我們審計的 WordPress 網站在行動版上評分在 30-60 之間，因為積累的外掛臃腫和主題開銷。如果你在 50 以下，外掛優化單獨可能不會將你帶到 75 以上。無頭方法 — 其中 WordPress 用作內容 API，而前端框架處理呈現 — 通常是值得探索的中間地帶。

Lighthouse 評分和真實核心網頁指標數據之間的區別是什麼？ Lighthouse 是一個實驗室工具 — 它模擬中檔手機在限流 4G 上，給你合成評分。搜索控制台中的核心網頁指標是現場數據 — 來自訪問你網站超過 28 天滾動窗口的實際 Chrome 用戶的真實測量。Google 使用現場數據進行排名信號，而非實驗室評分。Lighthouse 對於診斷問題和測試修復很有用，但你的目標是在搜索控制台中的第 75 個百分位數處於綠色 CWV 狀態。

2026 年整體 CWV 評分如何運作？ 自 2026 年 3 月核心更新以來，Google 跨整個域名聚合核心網頁指標數據，而非按個別頁面評估。高流量頁面在計算中加權更高。這意味著在數百個頁面上使用的緩慢部落格存檔範本會拖累你的主頁排名。修複是架構性的 — 你需要每個頁面範本都通過 CWV 閾值，而非只是你的關鍵著陸頁。

WordPress 到 Next.js 遷移通常花費多少？ 對於類似 SleepDr 的內容網站（200+ 頁、標準部落格佈局、聯繫表單、無電商），預期來自經驗豐富的代理機構 $15,000-30,000。電商遷移更高 — 取決於複雜性 $30,000-75,000+。Vercel Pro 上的持續託管是 $20/月。ROI 取決於有機流量對你業務的價值，但對於經歷了不良 CWV 的流量下降的網站，遷移通常在 3-6 個月內為自己付費。

我應該關注行動版還是桌面版 Lighthouse 評分？ 行動版。總是先行動版。Google 使用行動優先索引，行動版 Lighthouse 評分比桌面版的懲罰顯著。如果你的行動版評分是 94，你的桌面版評分幾乎肯定會是 95+。SleepDr 的 99 桌面版評分除了我們為行動版優化所做的之外，沒有需要額外工作。