Core Web Vitals 實測：中文網頁 LCP 從 54 秒到 9 秒

作者 Nick TasiAds & Code 創辦人·發布 2026-10-24·約 14 分鐘讀完

Core Web Vitals 是 Google 用來衡量網頁使用體驗的三個指標：LCP（最大內容繪製）看主要內容多快出現，INP 看點擊之後畫面多快回應，CLS 看版面會不會亂跳，良好門檻分別是 2.5 秒、200 毫秒和 0.1。中文網頁要改善，多半先從 LCP 下手：圖片縮到實際顯示的尺寸並轉成 WebP，再處理 Google 中文字型，我們有一支中文廣告落地頁靠這幾步，把 LCP 從 54.3 秒降到 9.3 秒。

這篇的數字來自我們 2026 年 5 月到 10 月在幾個網站上的實測，包括一支中文廣告落地頁、一個工具型官網、一個寵物內容站和一個資訊網站。量測工具是 Lighthouse 手機版和 PageSpeed Insights，多數是單一頁面、量一到兩次的結果，拿去跟自己的網站比之前，要用同一種量法重新量過。

Core Web Vitals 是什麼？三個指標與門檻

Core Web Vitals 是 Google 從眾多網頁效能指標裡挑出來、建議每個網站都要顧的三項。web.dev 的官方定義是：LCP 量載入，要在頁面開始載入後 2.5 秒內出現；INP 量互動，要在 200 毫秒以內；CLS 量版面穩定，要維持在 0.1 以下。及格的算法是看真實造訪的第 75 百分位，手機和桌機分開算，三項同時達標才算通過。

LCP 的「最大內容」指的是什麼，web.dev 的 LCP 說明寫得很具體：它回報的是視窗內最大的圖片、文字區塊或影片畫出來的時間。中文網頁的 LCP 元素常常是首頁主圖，也常常是一大段標題文字；後者如果用了網頁字型，字型什麼時候下載完，就直接決定 LCP。web.dev 也說這些門檻會盡量保持穩定，要調整會提前通知，節奏大約一年一次。

Core Web Vitals 會影響 SEO 排名嗎？

會影響，但它蓋不過內容本身。Google 搜尋中心的 Core Web Vitals 說明寫，良好的 Core Web Vitals 加上其他頁面體驗項目，「aligns with what our core ranking systems seek to reward」；頁面體驗說明則寫，Google 搜尋一律優先顯示最相關的內容，就算頁面體驗不理想也一樣。

我們的解讀是：速度是同樣切題的頁面之間的加分，不是內容不夠時的解藥。實務上我們把網站速度當成上線驗收的一項，修到不扣分、不讓訪客等到離開就好，不會為了追滿分拿掉該有的內容。新站如果連收錄都還沒有，先查的通常不是速度，而是 canonical 跟 sitemap 有沒有打架。

速度改版也有一個常被忽略的副作用：只壓縮圖片、換字型，頁面的主要內容沒有變，sitemap 的 lastmod 就不該跟著換成今天。我們的做法是讓日期只跟著內容走，細節寫在 sitemap lastmod 的內容雜湊做法。

怎麼看 Core Web Vitals？PageSpeed Insights 和 Lighthouse 差在哪

看 Core Web Vitals 有兩種資料。PageSpeed Insights 官方說明把它分成實地資料和實驗室資料：實地資料來自 Chrome 使用者體驗報告，是真實訪客過去 28 天的經驗；實驗室資料是 Lighthouse 在受控環境載入一次的結果，適合找問題，但官方也說它不一定抓得到真實世界的瓶頸。新站或流量小的頁面常常沒有實地資料，只能先靠實驗室數字。

網站速度測試工具很多，我們固定只用兩種：線上的 PageSpeed Insights，和本機用指令跑的 Lighthouse 手機版。兩者底層都是 Lighthouse，差別在限速方式。Lighthouse 預設用「模擬推算」，官方的限速說明寫，它是先不限速載入一次，再依觀察到的資料推算慢速網路下的結果，所以快、而且每次差不多，但推算不一定準。

模擬推算的誤差，我們 2026 年 10 月 20 日在某工具型官網踩到過：同一頁用真限速量，實際 0.25 秒就出畫面，模擬推算卻算成 2.8 秒，因為它把剛好在畫面出來前才下載完的字型，算成主畫面要等的東西。後來修前修後都改用真限速量（修前那一次，量的是 Cloudflare 保留的舊版部署網址），首頁從 67 分到 92 分、LCP 從 3.6 秒到 2.3 秒。模擬推算的數字，不能跟真限速的數字放在同一張表裡比。官方文件也說，模擬推算對多數網站的準確度跟 devtools 限速差不多、甚至更好，只是有一些邊角情況算不準；我們碰到的字型時間差，就是這種邊角情況，所以只有一頁、一個網站的觀察，不代表模擬推算整體不可信。

量的次數也有講究。Lighthouse 的分數變動說明直接寫，沒改任何程式碼，分數也會變，建議多跑幾次、看中位數，5 次的中位數比單跑 1 次穩定一倍。我們的底線是每頁至少量兩次、線上對線上比，不拿本機數字跟線上比；剛部署完的頭一次常常偏慢，因為 Cloudflare 的快取還沒熱，要再量一次才算數。

LCP 怎麼改善？先看四段拆解

LCP 慢，可以拆成四段找原因。web.dev 的 LCP 改善指南把它分成：伺服器回應第一個位元組的時間（TTFB）、開始下載 LCP 資源前的等待、資源本身的下載時間、下載完到畫出來的延遲，名字裡有「延遲」的兩段，理想上要接近零。Lighthouse 報告的「Largest Contentful Paint element」會列出四段各花多久。

這張表最常用到的是載入延遲那一列。2026 年 8 月 18 日我們量那支中文廣告落地頁，主圖的載入延遲是 5,096 毫秒，問題不在主圖多大，是 Google 中文字型一口氣拉了 20 多個分片，把頻寬吃掉，主圖排不到隊。看到載入延遲很大，先找誰在搶頻寬；載入時間很長，才回頭壓縮圖片。

實測：中文落地頁 LCP 從 54.3 秒到 9.3 秒

2026 年 8 月 18 日，我們分四個階段量一支中文廣告落地頁的 Lighthouse 手機版。改版前放了 11 張沒壓縮的 PNG，總重 16,847 KiB、LCP 54.3 秒；圖片轉 WebP 並縮到顯示尺寸後剩 2,203 KiB、11.8 秒；把 Google 中文字型拆小後是 1,253 KiB、9.3 秒，總重一共少了 93%。

從這張表看得出三件事。圖片是最大的一刀，一步就從 54.3 秒到 11.8 秒。第 2 步只拿掉用不到的字型，總重少了 235 KiB，LCP 反而從 11.8 秒變成 13.7 秒，代表那一步沒碰到真正的瓶頸，單次量測的起伏也可能蓋過這點差距。第 3 步處理到字型本身，LCP 才又往下掉。9.3 秒離 2.5 秒的門檻還很遠，這一頁還要繼續處理，但前面四十幾秒，只靠圖片和字型兩件事就拿回來了。

圖片：先量顯示尺寸再縮

圖片的問題多半不是格式，是尺寸。那支落地頁每張圖都比實際顯示的大了 4 到 11 倍，例如一張 1024px 寬的圖，在手機上只顯示 164px。我們的做法是先用瀏覽器量出每張圖在手機上實際顯示多寬，目標寬度設成顯示寬度乘以 2，給高解析螢幕用，再轉成 WebP。

格式方面，Google 的 WebP 官方說明寫，無損 WebP 比 PNG 小 26%，有損 WebP 在同等畫質下比 JPEG 小 25% 到 34%。我們實際省下的比例大得多，2026 年 8 月 7 日某站首頁上半部 10 張圖從 13.1MB 降到 1.4MB（少 89%），全站 143 張封面從 189MB 降到 20.5MB。能省多少，要看原圖本來有多肥。

WebP 有一個地方要留意：頁面上顯示的圖用 WebP，分享卡片用的 og:image 和結構化資料裡的圖片，我們保留 PNG，因為社群平台的爬蟲對 WebP 的支援不一致，換掉可能讓分享卡片破圖。PNG 原檔一張都不刪，留給 <picture> 裡的備援 <img>。落地頁要接廣告預算時，速度和追蹤都省不得，報價與製作流程寫在一頁式網頁的報價與自己做的極限。

Google Fonts 中文字型：圖片之後的第二個兇手

用 Google Fonts 中文字型時，瀏覽器下載的不是一個字型檔，而是依字碼範圍切成的上百個小分片，而且每個字重各一整套。以 Noto Sans TC 為例，2026 年 8 月我們那支落地頁請求 4 個字重，實際拉了 20 多個分片、共 1,090KB，主圖的載入延遲因此拖到 5,096 毫秒。在我們量過的中文頁面裡，圖片處理完之後，剩下最大的一塊就是字型。

我們用過三種做法，都量過結果：

text= 參數是 Google Fonts 官方提供的功能，官方入門文件寫，在某些情況下可以把字型檔縮小最多 90%，前提是事先知道要顯示哪些字。我們的做法是用真瀏覽器收集每一頁實際用到那個字型的字，寫進 text=，建站時自動跑。

為什麼不乾脆把網頁字型全部拿掉、只用系統字型？我們試過。台灣的手機本來就有不錯的中文字型，但 iPhone 的蘋方最粗只到 Semibold，沒有 900 那種黑體，整個拿掉之後，標題和按鈕明顯變細、少了力道。折衷是只載 900 一個字重給粗標題，內文改用系統字型；改完把改版前後的畫面並排比，粗標題、按鈕和數字要看起來一樣。

字型還有兩個小坑，是在另一個網站上踩到的：在 CSS 檔裡用 import 規則引入 Google 字型會擋住畫面，要拿掉；對字型下 preload，反而讓它搶在主圖前面下載，擋住了 LCP。

影片、YouTube 和追蹤碼：圖片以外的拖累

圖片和字型處理完，下一批要查的是第三方的東西：主視覺影片、內嵌的 YouTube、GA4 追蹤碼。它們的共同點是訪客一進來不一定用得到，卻會在載入時搶頻寬，或被算進主畫面。我們的原則是：訪客還沒互動前用不到的，就等互動再載；非放在最前面不可的，就先換成一張輕量的靜態圖。

主視覺影片。 2026 年 10 月 19 日，某工具型官網的主力頁 Lighthouse 手機版只有 56 分、LCP 11.2 秒，原因之一是主視覺的循環影片在網頁載完後才換上，被算成主畫面。我們把影片改成訪客開始捲動、點擊或按鍵才載入，加上字型子集化、預載與圖片用同一組尺寸規則，修完是 77 分、LCP 4.5 秒，整頁從 1.6MB 降到 0.5MB（模擬推算，修後取兩次平均）。

YouTube。 首頁主視覺要放 YouTube 影片時，我們先放縮圖，Lighthouse 官方把這種做法叫 facade：一個長得像播放器、但不會動的靜態元素，訪客點了才換成真的播放器。實測點擊前是 0 個 YouTube 請求，點了才插入 youtube-nocookie 的 iframe。這時縮圖就是 LCP 元素，要用立即載入並加上 fetchpriority="high"，web.dev 的 Fetch Priority 說明也把提高 LCP 圖片的優先順序，列為它最能幫上忙的情況之一。

GA4 追蹤碼。 2026 年 10 月，我們在某寵物內容站做了對照實驗：擋掉一張全站都會載入、773KB 的裝飾圖，LCP 不變；擋掉 GA4 的 gtag，某一頁的 LCP 從 6.9 到 7.4 秒降到 4.8 秒，分數從 69 到 79，量兩次結果一致。憑感覺挑「看起來最肥」的東西拿掉不一定有用，要一項一項擋掉，看 LCP 有沒有動。

延遲載入也要用對地方。web.dev 的圖片延遲載入說明寫，loading="lazy" 只該用在一開始看不到的圖片，LCP 圖片要用預設的立即載入。同一個寵物內容站全站 0 張圖用了 loading="lazy"，主圖要跟頁面下方的圖一起搶頻寬。

預載的尺寸規則。 用 <link rel="preload"> 預載主圖時，尺寸規則要跟 <img> 的 srcset 一致。2026 年 10 月 19 日我們發現，某網站的預載依螢幕寬度抓 640 版，<img> 在高解析手機上又抓 960 版，兩張都下載。web.dev 的響應式圖片預載說明建議預載時用 imagesrcset 和 imagesizes，寫法跟 <img> 的 srcset、sizes 相同。

我們量過的改善幅度

我們 2026 年 5 月到 10 月在幾個網站量過的改善，幅度差很多：有的一步拿回四十幾秒，有的位元組少了九成以上，LCP 卻只快 0.2 秒。看這些數字要注意兩件事，一是樣本數，多數是單一頁面；二是量法，模擬推算和真限速的數字不能互比。

表裡最容易被誤讀的是「字型子集與主圖」那一列：字型少了 91.5%、主圖少了 97.7%，LCP 只從 4.4 秒到 4.2 秒，同一個網站的字型預載就擋住了 LCP。位元組省很多，不代表 LCP 會等比例變快，每做一步都要回頭看四段拆解是哪一段變了。

測速踩過的坑：現象、原因、怎麼修

這些坑多半不是頁面寫錯，而是量法和工具本身會騙人：模擬推算把字型算進主畫面、剛部署完快取還沒熱、測速流量混進 GA4。我們 2026 年 8 月到 10 月在幾個網站上各踩過一次。

模擬推算把字型算進 LCP 現象：同一頁實際 0.25 秒就出畫面，Lighthouse 報告寫 2.8 秒。 原因：預設的模擬推算，把剛好在畫面出來前下載完的字型，算成主畫面要等的東西。 怎麼修：判斷修改有沒有效時改用真限速（--throttling-method=devtools），修前修後用同一種量法。

剛部署完量出來偏慢 現象：部署後頭一次量的分數，明顯比之後幾次低。 原因：Cloudflare 的快取還沒熱。 怎麼修：每頁量兩次、線上對線上，頭一次只當參考。

主圖下載了兩張 現象：高解析手機上，主圖的 640 版和 960 版都被下載。 原因：預載依螢幕寬度選圖，<img> 的 srcset 又照另一套規則選。 怎麼修：預載改用跟 <img> 同一組 imagesrcset、imagesizes。

包一層 picture 之後圖片塌掉 現象：為了給 WebP 包上 <picture>，原本高度設成撐滿父層的圖塌掉，版面跑掉。 原因：高度用百分比時是對父層算的，包了之後父層變成高度自動的 picture。 怎麼修：加上 picture{display:contents}，版面就跟改版前一致。

字型預載反而拖慢 LCP 現象：字型和主圖都壓小了九成以上，LCP 只從 4.4 秒到 4.2 秒。 原因：預載讓字型搶在主圖前面下載，擋住了 LCP。 怎麼修：拿掉字型預載，CSS 檔裡用 import 規則引入的字型也一起拿掉。

Windows 上跑 Lighthouse 一定報錯 現象：在 Windows 跑完 Lighthouse，結尾噴出 EPERM，退出碼是 1。 原因：那是刪除暫存資料夾時的錯誤，JSON 報告其實已經產生。 怎麼修：直接讀報告檔，判斷成敗看報告檔在不在、時間對不對，不看退出碼。

自己測速灌進 GA4 流量 現象：2026 年 10 月 22 日，某站兩天 40 個使用者裡，有 20 個螢幕是 412×823、停留 0 秒。 原因：那正是 Lighthouse 手機版預設的螢幕尺寸，GA4 只自動濾掉已知的機器人，我們判斷是自己的測速被算成訪客。 怎麼修：量速度時用 Lighthouse 的 --blocked-url-patterns 擋掉 GA4 的收集網址，看流量報表時也扣掉測速的日子。

量版面跳動的尺沒先驗 現象：2026 年 10 月 16 日，某站 112 張圖沒寫寬高屬性，看起來一定會讓版面跳動。 原因：CSS 已經固定了圖片的顯示尺寸，實際量到的 CLS 是 0。 怎麼修：用真瀏覽器的 PerformanceObserver 量 CLS；量之前先故意塞一張 200px 的圖驗尺，量到 0.2048 才相信這把尺量得出跳動。

我們的方案：落地頁製作與網站速度維護

我們做落地頁時，速度是交付內容的一部分：圖片依顯示尺寸輸出、中文字型只留需要的字重、影片和追蹤碼這類第三方內容延後載入，上線前後用同一種量法各量兩次，加了圖片、影片或字型之後沒有變慢才算完成。落地頁製作每頁 $250，規格與流程在落地頁製作服務。

已經上線的網站要改善 Core Web Vitals，屬於網站維運，依功能報價，評估不收費，可以從自動化與網站維運聯絡我們。網站如果要靠搜尋帶流量，速度通常跟技術 SEO 一起做，SEO 建置 $900 USDT、月維護 $400 USDT／月，方案在價格頁。更多收錄與技術 SEO 的實作整理在 SEO 與 GEO 知識庫。

常見問題

Core Web Vitals 會影響 SEO 排名嗎？ 會，但影響有限。Google 說良好的 Core Web Vitals 符合核心排名系統想獎勵的方向，同時也說會優先顯示最相關的內容，就算頁面體驗不理想也一樣，所以速度是加分，取代不了切題的內容。

LCP 多少秒才算及格？ 2.5 秒內。web.dev 的標準是看真實造訪的第 75 百分位，手機和桌機分開算；INP 要在 200 毫秒以內、CLS 在 0.1 以下，三項同時達標才算通過。

PageSpeed Insights 和 Lighthouse 的分數為什麼不一樣？ 因為資料和量法不同。PageSpeed Insights 的實地資料是真實訪客過去 28 天的經驗，實驗室資料和本機 Lighthouse 都是模擬載入一次；Lighthouse 預設的模擬推算和真限速，也會給出不同的數字，比較時要用同一種量法。

中文網站一定要用 Google Fonts 嗎？ 不一定。台灣的手機本來就有不錯的中文字型，內文用系統字型就夠；需要很粗的標題時，只載一個字重，或用 text= 只抓用到的字。我們在一個網站實測，明體從每頁 14 檔 1,088KB 降到 2 檔 139KB。

網站速度測試要量幾次才準？ 每頁至少兩次，線上對線上比。Lighthouse 官方說 5 次的中位數比單跑 1 次穩定一倍；剛部署完的頭一次常因快取還沒熱而偏慢，不要拿它下結論。

圖片轉成 WebP 之後，分享到社群會破圖嗎？ 有可能，所以我們只把頁面上顯示的圖換成 WebP，og:image 和結構化資料裡的圖片保留 PNG。社群平台的爬蟲對 WebP 的支援不一致，保留 PNG 原檔比較保險。