網站內容再好，只要頁面打開得慢、點了沒反應，或讀到一半版面突然亂跳，使用者的耐心通常就到這裡了。這種流失，不會等到報表很難看才發生，它往往當下就已經在損失流量和轉換。
這也是為什麼 Core Web Vitals 不能只當成工程團隊的性能指標。它同時關係到 SEO、使用體驗，以及商業結果。
Core Web Vitals 到底在看什麼
這三個指標分別對應頁面體驗的不同面向，最好一起看，不要只盯其中一個分數。
1. LCP（Largest Contentful Paint）
LCP 代表使用者打開頁面後，首屏中最主要、最大的內容什麼時候真正出現。很多時候它會是 hero 圖、Banner、影片封面，或文章開頭的大段文字。
理想目標是 2.5 秒以內。
2. INP（Interaction to Next Paint）
INP 看的是使用者做出操作後，頁面多久給出明確的視覺回應，例如點按按鈕、展開選單、輸入表單。
建議控制在 200 毫秒以內。
3. CLS（Cumulative Layout Shift）
CLS 衡量的是頁面在載入過程中，有沒有出現非預期的版面位移。
通常會以 0.1 以下作為目標。
先量再改，才不會白忙一場
效能優化最怕憑感覺。你以為是圖片太大，實際上可能是第三方腳本卡住主執行緒；你以為是伺服器慢，結果問題出在字型和廣告版位。
1. Google Search Console 與 PageSpeed Insights
先看 Search Console 裡的 Core Web Vitals 報表，確認哪些 URL 群組真的在真實使用者環境中出問題。接著再用 PageSpeed Insights 檢查單一頁面。
2. Chrome Lighthouse
Lighthouse 很適合做第一輪技術排查，重點是看：
- 哪個元素被判定為 LCP
- 哪些腳本長時間佔用主執行緒
- 哪些 CSS、字型或 JS 阻塞首屏渲染
- 版面偏移發生在哪個時機點
3. 真實使用者監測（RUM）
實驗室數據很好用，但不代表真實流量現場。慢速行動網路、舊裝置、第三方外掛、不同地區的延遲，都需要靠 RUM 才看得清楚。
如果你想先從 SEO 角度排優先順序，也可以搭配 SEO Analyzer 一起看，先抓出最值得優先處理的頁面。
LCP 要怎麼降下來
多數 LCP 偏慢的頁面，問題其實很集中：首屏主圖太重、伺服器回應太慢，或關鍵渲染路徑塞了太多東西。
1. 先處理首屏主圖
- 盡量改用 WebP 或 AVIF
- 用
srcset或<picture>提供不同尺寸 - 圖片上線前先壓縮
- 不要把 LCP 候選圖片設成
loading="lazy" - 補上
width與height
1<picture> 2 <source 3 srcset="hero-1200.webp 1200w, hero-800.webp 800w, hero-400.webp 400w" 4 type="image/webp" 5 sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" 6 > 7 <source 8 srcset="hero-1200.jpg 1200w, hero-800.jpg 800w, hero-400.jpg 400w" 9 type="image/jpeg" 10 sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" 11 > 12 <img src="hero-800.jpg" alt="Homepage hero image" width="1200" height="800" loading="eager"> 13</picture>
2. 降低 TTFB
如果伺服器回應本身就慢，瀏覽器根本沒有東西可以開始渲染。
- 啟用頁面快取或物件快取
- 靜態資源走 CDN
- 檢查慢查詢與過重的伺服器邏輯
- 把非首屏必要的運算移出關鍵流程
3. 減少阻塞渲染的資源
不少頁面其實不是內容太重，而是首屏前先載了太多 CSS、字型與 JavaScript。
- 只把首屏必要的 CSS 放進關鍵路徑
- 非必要腳本用
defer - 可獨立執行的第三方腳本用
async - 不必在首屏初始化的套件就不要提早載入
1<head> 2 <link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin> 3 <script src="/js/main.js" defer></script> 4 <script src="https://analytics.example.com/script.js" async></script> 5</head>
4. preload 要精準用
它很適合拿來提早抓取 LCP 圖片或主要字型，但如果什麼都想先載，最後只會讓頻寬更擠。
INP 優化重點：讓頁面真的有反應
INP 表現差，大多不是因為某一個按鈕有問題，而是主執行緒一直太忙。
1. 幫 JavaScript 瘦身
- 把大 bundle 拆開
- 次要功能改成動態載入
- 清掉沒用到的程式碼
- 不需要立刻互動的元件，就別太早 hydrate
1document.querySelector('.open-chart').addEventListener('click', async () => { 2 const { renderChart } = await import('./chart-module.js'); 3 renderChart(); 4});
2. 管好第三方腳本
聊天外掛、追蹤碼、廣告、地圖、A/B 測試平台，常常才是拖慢互動體驗的大戶。
你可以直接問自己三件事：
- 這個腳本真的有商業價值嗎？
- 它能不能延後到第一次互動後再載？
- 它有沒有可能直接移除？
3. 拆分長任務
只要某段 JavaScript 長時間霸佔主執行緒，點擊和輸入就會被排隊。
- 把大型運算拆成小段處理
- 次要任務交給
requestIdleCallback - 重運算搬到 Web Worker
CLS 要怎麼降
CLS 通常不是一個大錯，而是一堆小地方都沒有先想清楚。
1. 為媒體與嵌入內容預留空間
圖片、影片、iframe 若沒有先留位置，載入時就會把其他內容往下擠。
- 明確寫上
width和height - 響應式區塊可搭配
aspect-ratio - 影片與嵌入內容放在高度穩定的容器裡
2. 避免元素突然插隊
公告條、促銷 Banner、推薦模組或廣告如果在頁面上方突然插進來，很容易把版面推亂。
- 先預留空間
- 不想推動內容時可考慮 overlay
- 廣告版位要有最小高度
3. 檢查字型載入策略
網頁字型也很常造成版面位移。
- 預載主要字型
- 使用
font-display: swap - 選擇字寬、行高接近的備援字型
一個很常見的改善案例
某個以行動流量為主的電商網站，初始狀態如下：
- LCP：4.8 秒
- INP：180 毫秒
- CLS：0.25
- 轉換率：1.2%
- 跳出率：65%
後來做了這幾件事：
- 首屏圖片全面改為 WebP
- 圖片與廣告版位預留固定空間
- 分析與廣告腳本延後載入
- 關鍵 hero 圖片使用 preload
- 精簡 critical CSS
- 靜態資源導入 CDN
- 字型改用
font-display: swap
優化後的結果：
- LCP：1.9 秒
- INP：65 毫秒
- CLS：0.08
- 轉換率：2.8%
- 跳出率：42%
沒有什麼神招，重點只是先把最傷體驗的地方優先修掉。
真正有差的是持續維護
Core Web Vitals 不是修一次就永遠穩定。新活動頁、新追蹤碼、新元件，任何一個小變動都可能讓分數再掉回去。
1. 建立持續監控
Search Console、RUM 與重要頁型都要固定追蹤，不要等排名掉了才回頭看。
2. 設定效能預算
最好先定出明確上限，例如：
- JavaScript 總體積
- 單張圖片最大容量
- 字型數量
- 第三方腳本數量
3. 把效能檢查放進發布流程
新頁面上線、改版、功能更新之前，都應該先看一次 LCP、INP、CLS。
4. 讓整個團隊都理解這件事
這不是只有工程師要管。設計、內容、行銷都會影響這三個指標。
最後整理
- LCP 主要看首屏關鍵資源、伺服器回應與關鍵渲染路徑。
- INP 主要看主執行緒負載與 JavaScript 是否過重。
- CLS 主要看版面空間有沒有先規劃好。
- 實驗室數據很有用，但真實使用者數據才最有說服力。
- 目標不是拿漂亮分數，而是做出更快、更穩、也更容易轉換的頁面。
如果你想先找出哪些 URL 最值得優先處理，可以先用 SEO Analyzer 排序，再搭配 Lighthouse 與真實使用者數據深入分析。
