網站速度優化實戰，拿自己 LCP 11.5 秒的網站開刀

本文重點

• 寫這篇前先測自己的站：行動版 64 分、LCP 11.5 秒。三個元凶：中文字型四個字重共 35 個子集檔 1.4MB（佔全頁傳輸量八成）、138KB 的 render-blocking CSS、162KB 的 GA4 追蹤腳本——靜態網站不等於快。
• 速度優化的正確流程是「量測 → 找出自己的元凶 → 對症修」，不是照通用清單亂裝外掛。
• 中文網站有專屬課題：CJK 字型是台灣網站 LCP 的最大殺手之一，減字重、preload 關鍵子集、swap、系統字型是四段修法。
• 修到綠燈門檻（LCP 2.5s / INP 200ms / CLS 0.1）就停，之後的分數是虛榮指標。

寫這篇文章之前，我先用 Lighthouse 測了本站——一個 Astro 靜態站、掛在 Cloudflare 邊緣節點、沒有留言外掛沒有輪播圖的「理論上很快」的網站。

結果：行動版效能 64 分，LCP 11.5 秒。

這個難看的數字是這篇網站速度優化教學最好的教材：靜態網站不等於快、伺服器快不等於使用者快（本站的 TTFB 只有 280ms，然後在 Lighthouse 模擬的 4G 慢速環境下，花了 11 秒才把主要內容畫出來）。這篇用本站的真實診斷當主軸，示範從量測、定位到修復的完整流程——你可以拿同一套流程檢查自己的網站。

（更新：診斷後三天修復上線，LCP 在真實限速下已降到 1.9 秒、綠燈達標——完整的 before/after 數據與修復過程學到的測量教訓，都補在第七節。）

一、先量測，讓報告告訴你元凶是誰

速度優化最常見的錯誤是跳過診斷直接吃藥：裝快取外掛、開 CDN、壓圖片——這些都對，但如果你的病灶是字型或第三方腳本，做完分數一分都不會動。

工具兩個就夠：PageSpeed Insights（線上版，附真實使用者數據）或 Lighthouse（Chrome DevTools 內建，可離線跑）。跑完看三個地方：

指標區——LCP、INP、CLS 哪個亮紅。三個指標的定義與門檻在核心網頁指標完整指南，本文專注修法。

機會與診斷區——Lighthouse 直接告訴你最大的浪費在哪：render-blocking 資源、過大的圖片、未使用的 JS。

資源清單——按傳輸大小排序網路請求，前十名就是嫌疑人名單。

本站的嫌疑人名單長這樣：第一名 GA4 的 gtag.js 追蹤腳本 162KB、第二名一支 138KB 的 CSS、第三名之後一長串中文字型子集檔——總共 35 個、合計 1.4MB，佔全頁傳輸量的八成。三個元凶，一個都不是「圖片太大」這種教科書答案——這就是為什麼要先量測。

二、LCP 實戰，最大內容多久才畫出來

LCP（最大內容繪製）是多數內容網站的主要痛點，web.dev 的 LCP 優化指南把它拆成四段：TTFB、資源載入延遲、資源載入時間、渲染延遲。對症下藥：

（一）TTFB，伺服器層

目標 800ms 內。主機等級、快取命中率、CDN 距離是三個槓桿。靜態產生（SSG）加邊緣節點是內容站的最優解——本站這段只有 280ms，證明了一件事：TTFB 快不保證 LCP 快，後面的資源與渲染才是大魔王。

（二）render-blocking 資源

HTML 到手後，瀏覽器被 CSS 與同步 JS 擋著不能畫面。檢查 Lighthouse 的「排除轉譯阻礙資源」項目：CSS 該瘦身（本站那支 138KB 的 CSS 就是全站樣式打包成一支的後果，Lighthouse 估計單這一項就拖慢 FCP 約 1.6 秒——本站 FCP 4.6 秒的主因在這裡）、非關鍵樣式延後、同步 JS 加上 defer。

（三）LCP 元素本身

LCP 元素是圖片：控制尺寸（響應式 srcset）、現代格式（WebP/AVIF）、加 fetchpriority="high"、不要對首屏圖 lazy load——圖片的完整處理見圖片 SEO 完整指南。

LCP 元素是文字（中文內容站的常態）：問題幾乎都出在字型。這值得獨立一節。

三、中文網站的字型專題，台灣站的 LCP 頭號殺手

中文字型的字符數是拉丁字型的百倍等級，完整檔案動輒數 MB。現代方案是切子集（unicode-range subsets）：把字型切成上百個小檔，瀏覽器按頁面用到的字符載入。

聽起來很聰明，但實務上一個中文頁面會觸發大量子集請求——本站首頁載了 35 個 Noto Serif TC 子集檔，合計 1.4MB、佔全頁傳輸量的八成；而且 300、400、500、600 四個字重各載一套（樣式檔一口氣 import 了五個字重，首頁實際觸發四個——連我自己都是量測後才知道）。

本站的 font-display 已經是 swap，所以文字不會空白等字型。但 swap 的代價是：fallback 字型先畫、目標字型到齊後大面積重繪——首頁的 LCP 元素正是一段文字，加上 1.4MB 的下載時間，LCP 就是這樣被拖到 11.5 秒的。

修法按投資報酬率排：

減字重。每多一個字重就是整套子集再來一次。內文一個字重、標題一個字重是上限，能合併就合併。

preload 首屏關鍵子集。把涵蓋首屏文字的主要子集加 <link rel="preload">，讓它跟 CSS 並行下載，參考 web.dev 的字型最佳化指南。

font-display: swap。先用系統字型顯示文字、字型到了再換——版面會閃一下，但使用者能立刻閱讀。中文站幾乎沒有不用 swap 的理由。

終極解：內文用系統字型。font-family 直接走系統字型棧（蘋方、微軟正黑），零下載、零延遲，只在標題保留品牌字型。這是取捨題：本站當初為了閱讀質感選了全站襯線字型，速度帳單現在才來——這筆帳每個中文網站主都該親自算一次。

四、INP 實戰，互動卡不卡

INP（互動至下次繪製）量測互動（點擊、觸控、按鍵）後畫面多久有反應，門檻 200ms，病因幾乎都是 JS 太多、主執行緒太忙（見 web.dev 的 INP 指南）。

第三方腳本是頭號嫌疑。GTM、聊天外掛、追蹤 pixel——本站最大的單一資源就是 GA4 的 gtag.js，162KB。它是非同步載入、不擋渲染，但在慢速網路上會跟字型與圖片搶頻寬。修法：延遲到頁面互動後或閒置時再載入、砍掉沒在用的追蹤碼、一年沒看過報表的工具直接移除。

自家 JS 減量。框架站的 hydration 成本是隱形大戶，JavaScript SEO 與渲染策略講過的 islands 架構在這裡兌現：只讓需要互動的元件帶 JS。本站的 TBT 是 0ms——靜態架構在 INP 這關幾乎免費過關，這是它換來的。

五、CLS 實戰，版面跳不跳

CLS（累積版面位移）的修法最機械（門檻 0.1，見 web.dev 的 CLS 指南）：圖片與影片標好 width/height 讓瀏覽器預留空間、廣告與嵌入版位給固定高度容器、字型 swap 造成的位移用 size-adjust 對齊 fallback 字型的度量。

本站的 CLS 是 0.002——內容站只要圖片有尺寸屬性、沒有動態插入的橫幅，這關通常免費過。

六、平台別的快速修法清單

WordPress——快取外掛（頁面快取 + 物件快取）、圖片壓縮外掛、主題精簡、外掛定期盤點（每個外掛都是潛在的 CSS/JS 負債）、升級 PHP 版本。先做這五件再考慮換主機。

自架與框架站——SSG 或 ISR 優先、islands/partial hydration、圖片管線自動化（build 時轉 WebP 與多尺寸）、CDN 邊緣快取。

電商與租用平台——可動空間小，專注三件做得到的：圖片上傳前壓好、App/外掛盤點刪冗餘、佈景主題選輕量的。平台底層的 TTFB 與 JS 你動不了，把力氣花在能動的地方。

七、本站的修復記錄，before 與 after

這節原本是「接下來要做的四件事」的待辦清單；文章上線三天後修復完成，照內容更新的做法把結果補回來。實際動的三刀：

1. 字型減量——Noto Serif TC 從五個字重砍到 400 與 600 兩個切片版（原本的 300、500 靠瀏覽器字重匹配自動落到 400，版面完全不動）；約 690KB 的 @font-face 規則從主 CSS 拆出來改非同步載入；再 preload 首屏的關鍵切片。
2. CSS 瘦身——上一刀就是主刀：那支 render-blocking 樣式檔的主體就是內嵌的字型規則，拆完後阻塞 CSS 從 743KB 降到 50KB（未壓縮）。
3. gtag.js 延遲載入——延到頁面載入完成加閒置時才注入，162KB 移出首屏頻寬競爭。

成績單（行動版，修復上線三天後的正式環境實測）：

指標	修復前	修復後
Lighthouse 效能（模擬 4G）	64	88
LCP（模擬 4G）	11.5s	3.7s
FCP（模擬 4G）	4.6s	1.8s
LCP（devtools 真實限速）	—	1.9s，綠燈達標
全頁資源量	1.73MB	1.05MB

修復過程還學到一個值得寫進 SOP 的測量教訓：Lighthouse 預設的模擬（simulated）模式，對字型 swap 主導的 LCP 估算噪音高達正負 2 秒——同一個 build 連跑三次可以從 3.0 秒跳到 6.5 秒。驗證字型策略請改用 devtools 真實限速模式（CLI 加 --throttling-method=devtools）；線上版 PSI 跑的也是模擬模式，看到 LCP 在 4 秒上下波動，先懷疑噪音再懷疑網站。

最後一關還在跑：等 28 天的 GSC 體驗區塊與 CrUX 真實使用者數據進場才算完整驗收——實驗室數據找病因，真實數據才算數。這也是本文想示範的最後一件事：速度優化是「量測、修復、驗收」的循環——而且教 SEO 的網站自己也會考 64 分，誠實面對數據比假裝完美有用。

八、FAQ

（一）Q1: 網站速度優化該從哪裡開始？

先量測再動手。用 Lighthouse 或 PageSpeed Insights 跑重要頁面，看三件事：哪個指標亮紅、「機會」區塊列出的最大浪費、資源清單的前十大檔案。

多數網站的病灶集中在兩三個元凶（大圖、字型、第三方腳本），對著報告修比照通用清單亂裝外掛有效得多。

（二）Q2: 中文網站的字型為什麼特別拖速度？

中文字型的字符數是拉丁字型的百倍等級，即使切成子集，一個頁面仍常載入十多個各約 50KB 的子集檔，兩個字重就是雙倍。

修法優先序：減字重、preload 首屏關鍵子集、font-display 用 swap，以及最激進但最有效的——內文改用系統字型。

（三）Q3: Lighthouse 分數跟 GSC 的核心網頁指標為什麼不一樣？

量的東西不同。Lighthouse 是實驗室數據：模擬裝置與網速下單次執行的結果，適合除錯定位。

GSC 與 PSI 上方欄位是真實使用者數據（CrUX）：過去 28 天實際訪客的體驗分布，排名參考的是這個。實務用法：實驗室數據找病因，真實數據驗收。

（四）Q4: 速度優化做到什麼程度就夠了？

三個指標過綠燈就停：LCP 2.5 秒內、INP 200 毫秒內、CLS 0.1 以下（以真實數據的 75 百分位數為準）。

Google 的評估是門檻制不是線性加分，90 推 100 的邊際效益極低。過線後，把時間投回內容與結構的報酬率高得多。

（五）Q5: 裝了快取外掛分數還是沒動怎麼辦？

代表你的病灶不在快取能解的範圍。快取解的是 TTFB 與重複資源載入；如果元凶是字型、第三方腳本或 render-blocking CSS，快取幫不上忙。

回到 Lighthouse 報告看「機會」區塊實際列了什麼——本站就是活例子：TTFB 只有 280ms，LCP 卻 11.5 秒，問題全在快取之外。