Core Web Vitals 實戰：台灣中小企業官網速度最容易掉分的 5 個地方

重點摘要

• Core Web Vitalsⓘ 自 2021 年起納入 Google 搜尋排名訊號，包含 LCPⓘ、INPⓘ、CLSⓘ 三項指標，直接影響你的官網在搜尋結果的位置
• 根據 HTTP Archive 年度調查，全球只有 48% 的行動版頁面完整通過三項指標（HTTP Archive，2025），台灣中小企業官網情況普遍不樂觀
• 五個最高頻失分點：圖片未設寬高、圖片格式過時、渲染阻塞資源、繁體中文字型未優化、行動版嵌入元件未佔位——其中第四點是台灣網站特有的高頻問題
• 頁面速度直接影響業績：頁面每延遲 1 秒，行動轉換率平均下降 7–20%（Think with Google，2024）
• 修復不需要重做網站，用 Google PageSpeed Insights 找到最低分的問題，逐一改善即可

Core Web Vitalsⓘ 是 Google 衡量頁面使用者體驗的三項核心指標，自 2021 年正式納入排名演算法。台灣中小企業官網面臨的困境不是「不知道」這些指標的存在，而是不知道自己的網站具體在哪裡失分、哪裡修最值得。台灣的網路基礎設施很好，但「網速快」不等於「你的網站快」——後端伺服器快、前端資源沒有優化，分數一樣很難看。這篇文章直接給你五個最高頻的失分點，以及對應的修復優先順序。

Core Web Vitalsⓘ 三個指標的基本認識

Core Web Vitalsⓘ 由三個指標組成，分別測量頁面體驗的不同面向：

LCPⓘ（Largest Contentful Paint，最大內容渲染）：測量頁面主要內容出現的速度。標準是 2.5 秒內完成，超過 4 秒被標為「需要改善」。通常是 Hero 大圖、首屏最大的文字塊，或是商品主圖。

INPⓘ（Interaction to Next Paint，互動至下一幀繪製）：取代原本的 FID，測量使用者點擊、輸入後頁面回應的速度。標準是 200 毫秒內反應。INPⓘ 已於 2024 年 3 月正式取代 FID，許多網站的程式碼還沒跟上這個標準，這個指標對「裝了很多第三方插件的 WordPress 站」來說特別嚴格。

CLSⓘ（Cumulative Layout Shift，累積版面配置偏移）：測量頁面載入時版面跳動的程度。標準是 0.1 以下。CLSⓘ 是手機用戶最容易誤點的原因——看到一個按鈕想點，頁面突然跳動，按到的是廣告或關閉鍵。

根據 HTTP Archive 對全球頁面效能的統計報告，CLSⓘ 達成率在三項指標中最高，但 LCPⓘ 和 INPⓘ 仍是大多數網站的主要瓶頸（HTTP Archive，2025）。有一個常見誤解值得說清楚：台灣的有線和 4G/5G 網速在全球名列前茅，但這和你的 Core Web Vitalsⓘ 分數幾乎沒有因果關係——LCP 掉分通常不是「網路慢」造成的，而是前端資源沒有優化。

失分點一：圖片未設定明確的寬高屬性

圖片是 CLSⓘ 最高頻的元凶，而且是最容易被忽視的那種問題。瀏覽器在解析 HTML 時，如果 <img> 標籤沒有指定 width 和 height 屬性，瀏覽器無法預先保留空間，只能等圖片下載完才確定尺寸，版面這才確定。這個延遲造成的突然跳動，就是 CLSⓘ 分數下降的直接原因。

根據 HTTP Archive 對行動版頁面的分析，高達 62% 的行動版頁面因未指定圖片寬高導致版面偏移（HTTP Archive，2024）。台灣許多使用 WordPress 架站的網站，舊版主題（特別是 2018 年以前的免費主題）預設不強制加這兩個屬性，加上管理員上傳圖片時只顧「看起來對」，沒有人去改底層 HTML，這個問題就一直帶著走。

修復方向：在所有 <img> 標籤加上 width 和 height 屬性，數值對應圖片原始比例即可，CSS 的 max-width: 100% 會處理響應式縮放。現代前端框架如 Next.js 的 <Image> 元件預設強制要求這兩個屬性，這也是它比普通 <img> 標籤更適合正式網站的原因之一。

常見誤區：很多人以為只要圖片在視覺上「填滿」了容器就沒問題，但 CLSⓘ 看的是 HTML 原始屬性，不是 CSS 樣式的效果。加了 width: 100% 的 CSS 不等於加了 HTML 的 width 屬性。

失分點二：首圖格式仍是 JPEG 或 PNG 而非 WebP

LCPⓘ 的核心是讓頁面最大的可見元素盡快出現。對大多數品牌官網來說，這個元素通常是 Hero 圖片——訪客打開頁面最先看到的全寬大圖。如果這張圖仍在使用 JPEG 或 PNG，檔案比 WebP 格式大 25–35%，載入時間相應拉長，LCP 分數直接受影響。

根據 Google 開發者文件的技術說明，WebP 格式在不損失視覺品質的前提下，比 JPEG 平均減少 25–34% 的檔案大小（Google，2024）。Google PageSpeed Insights 的建議清單中，「以現代格式提供圖片」是出現頻率最高的改善建議之一，幾乎每一個沒有刻意優化圖片的網站都會被標出來。

修復方向：使用 Squoosh（squoosh.app，免費，有瀏覽器版）或 Sharp CLI 將現有圖片批次轉換為 WebP；在 HTML 裡用 <picture> 搭配 <source type="image/webp"> 提供瀏覽器降級支援。如果使用 Cloudflare CDN 或 Vercel 部署，可啟用平台的自動圖片最佳化，無需手動轉換每一張圖。

工具選擇建議：如果是 WordPress 站，Imagify、ShortPixel 等插件可以批次處理現有媒體庫；如果是靜態站或 Next.js，Vercel 的 Image Optimization 是零設定選項。

失分點三：渲染阻塞的 CSS 和 JavaScript

LCPⓘ 的另一個殺手是渲染阻塞資源。瀏覽器解析 HTML 時，遇到沒有加 async 或 defer 屬性的 <script> 標籤，會暫停整個渲染流程，等腳本下載並執行完才繼續——LCPⓘ 就從這裡開始計時等待。

根據 Google 的行動速度研究調查，53% 的行動用戶會在頁面超過 3 秒未載入時直接離開網站（Think with Google，2024）。台灣中小企業網站特別容易積累渲染阻塞問題，因為行銷工具會隨業務成長不斷疊加：Meta Pixel、GA4、Line Conversion API、HotJar、Crisp 客服……每個工具都說「複製貼上到 <head>」，但沒有人說這些加總起來的阻塞效果有多嚴重。

修復方向：

• 對非關鍵腳本加上 defer 屬性（適合需要 DOM 的腳本），或 async（適合獨立的追蹤腳本）
• 將首屏渲染所需的關鍵 CSS 提取為 inline 樣式，其餘用 media="print" 技巧延遲載入
• 定期審查 <head> 裡的腳本清單，特別是那些「當初測試用、後來忘記移除」的追蹤程式碼

常見誤區：有人以為追蹤腳本輕量、不影響速度，但問題不在個別腳本的大小，而在多個腳本同步阻塞的疊加效應。五個各 20KB 的腳本同步載入，比一個 200KB 的非同步腳本對 LCPⓘ 的傷害更大。

失分點四：繁體中文字型的載入策略錯誤

繁體中文字型是台灣網站特有的效能挑戰，這個問題在歐美的技術文件中幾乎看不到說明，但對台灣開發者來說卻是高頻遇到的坑。

問題的規模差異很大：西文主流字型如 Inter、Plus Jakarta Sans 單一 woff2 通常在 50–120KB 之間；但 Noto Sans TC 完整字型集超過 10MB，Noto Serif TC 更大。如果沒有做字型子集（Subset），整個字型檔在每次頁面載入時都要從 CDN 下載。即使有快取，首次訪問的用戶和清空快取後的訪問，都要等待這個下載完成。

CLSⓘ 的問題來自字型替換（FOUT，Flash of Unstyled Text）：系統字先顯示，目標字型下載完後切換，文字位置略微跳動。更糟糕的是如果 @font-face 沒有設定 font-display: swap，瀏覽器預設等待字型下載完才顯示文字（FOIT，Flash of Invisible Text），用戶看到的是空白文字區塊，LCPⓘ 時間直接拉長。

修復方向：

• 在 CSS 的 @font-face 加入 font-display: swap（一行設定，效果顯著）
• 使用 Google Fonts 接口時，確認 URL 包含 display=swap 參數（如：?family=Noto+Sans+TC&display=swap）
• 繁體中文字型強烈建議做字型子集，只保留常用漢字範圍（約 3,000–5,000 字），可將字型檔案從 10MB 以上降到 500KB 以下
• 字型子集工具推薦：fonttools 的 pyftsubset、或 Google Fonts 內建的動態子集化

這個問題在本地端開發時完全不會出現——因為本機字型快取已建立，開發者看到的載入速度和用戶首次訪問的體驗差距可達 2–3 秒。這也是為什麼很多台灣網站在開發者自己的電腦上「看起來很快」，但 PageSpeed 分數卻很低。

失分點五：行動版廣告和嵌入元件沒有佔位尺寸

第五個失分點是廣告和外嵌內容——包括 Google Ads 廣告、Facebook 外掛、YouTube 嵌入影片、Google 地圖——在載入完成前沒有預留空間，導致它們出現時將頁面其他內容突然往下推，產生嚴重的 CLSⓘ。

根據 Google I/O 2024 的頁面體驗報告，動態載入的廣告和第三方嵌入是行動版 CLSⓘ 最常見的後期載入移位來源（Google，2024）。對台灣服務業官網來說，嵌入的 Google 地圖和第三方預約工具（Calendly、Rezio）都是常見的 CLS 源頭，因為這些 <iframe> 的高度在載入前通常是 0 或未定義，容器沒有佔位就會在內容出現時讓版面突然跳動。

行動版比桌面版更嚴重，原因是手機螢幕窄，相同的位移偏移量在行動版畫面上佔的比例更大，CLSⓘ 分數懲罰也更重。

修復方向：

• 給廣告容器設定最小高度（如 min-height: 250px），即使廣告還沒載入，容器高度已佔位
• 嵌入 YouTube 時使用帶有 aspect-ratio: 16/9 的容器，確保影片空間在載入前就保留好
• 嵌入 Google 地圖時在 <iframe> 上明確指定 height 屬性，不依賴預設值或外部 CSS 的懶人設定

快速自我審查清單

以下五個檢查項目可以讓你在 10 分鐘內確認自己的網站有沒有落入這五個陷阱：

• ☐ 用 Google PageSpeed Insights 測試首頁——行動版分數 vs. 桌面版分數
• ☐ 在 DevTools 的 Elements 面板搜尋 <img，確認有沒有 width、height 屬性
• ☐ 在 PageSpeed 建議清單查看有沒有「以現代格式提供圖片」這一條
• ☐ 在 DevTools 的 Network 面板，篩選 Font，查看字型檔案大小和載入時間
• ☐ 在 <head> 原始碼搜尋 <script，數有幾個沒有 async 或 defer

台灣行動裝置佔整體上網流量的 64%（DataReportal，2024），測試時優先看行動版分數——桌面版幾乎總是比行動版好看，但真實用戶大多在手機上訪問。

了解 Core Web Vitalsⓘ 在整體行銷策略中的位置，可以參考這篇 AEO 完整指南——速度是讓 AI 搜尋引擎能完整讀取並引用你內容的基礎條件之一。

速度不是唯一，但慢下來的代價比你想像的大

Core Web Vitalsⓘ 影響 Google 搜尋排名，但更直接影響的是真實用戶的停留意願。頁面每延遲 1 秒，行動轉換率平均下降 7–20%（Think with Google，2024）。對月流量數百至數千人的台灣中小企業來說，即使只有 5% 的轉換率提升，也是每個月實際多出的詢問和訂單。

五個失分點裡，圖片寬高設定和字型子集化是對台灣網站性價比最高的改善：前者幾乎不需要工具，後者技術門檻稍高但效果極為顯著。如果你是 WordPress 使用者，先從圖片相關的插件入手；如果你是 Next.js 開發者，<Image> 元件和 next/font 已幫你把這兩個坑填平了。