速度不只是體驗問題，更是排名問題
你有沒有過這種經驗：點進一個網站，等了三秒還沒載入完，就直接按返回鍵走了？你不是特例。研究顯示，頁面載入時間超過 3 秒，超過一半的使用者會離開。
Google 當然也知道這件事。從 2021 年開始，Google 正式把 Core Web Vitals（核心網頁指標）納入排名因素。簡單說就是：你的網站如果太慢、操作會卡頓、畫面會跳來跳去，Google 就會在排名上給你扣分。
這不是可以忽略的小事。在其他條件差不多的情況下，一個 Core Web Vitals 全部達標的網站，排名會比不達標的競爭對手好。尤其在行動搜尋上，速度的影響更加明顯。
Core Web Vitals 不是一個模糊的概念，它是三個可以量化的具體指標，每個都有明確的「及格線」。接下來我們一個一個拆解。
LCP：最大內容繪製
**LCP（Largest Contentful Paint）**衡量的是頁面上最大的內容元素（通常是主圖片或大標題）完成載入所需的時間。白話文就是：使用者要等多久才能看到頁面的主要內容。
| 等級 | 時間 | |------|------| | 好 | ≤ 2.5 秒 | | 需要改善 | 2.5 - 4.0 秒 | | 差 | > 4.0 秒 |
LCP 是三個指標裡最直觀的。使用者點進你的頁面，如果兩秒半之內就能看到主要內容，體驗就算合格。
影響 LCP 最大的因素：
伺服器回應時間：如果你的主機太慢，還沒開始載入頁面內容就已經浪費了好幾秒。使用 CDN（Content Delivery Network）可以讓離使用者最近的伺服器提供內容。選擇品質好的虛擬主機也很重要——不要為了省一個月幾百塊用爛主機。
圖片優化：這是最常見的 LCP 殺手。一張 3MB 的未壓縮 JPEG 就能讓你的 LCP 直接爆表。解決方法：使用 WebP 或 AVIF 格式、設定適當的圖片尺寸、使用響應式圖片（srcset）、對首屏圖片用 preload。
CSS 阻塞渲染：瀏覽器要等 CSS 全部載入完才會開始繪製頁面。如果你的 CSS 檔案很大，或是載入了一堆用不到的 CSS，就會拖慢 LCP。把關鍵 CSS 提取出來 inline 到頁面裡，其他的延遲載入。
字體載入：自訂字體（Web Fonts）如果沒有正確處理，可能導致文字在字體載入完成前不顯示。使用 font-display: swap 讓瀏覽器先用系統字體顯示文字，字體載入完再替換。
INP：互動到下一次繪製
**INP（Interaction to Next Paint）**是 2024 年取代 FID（First Input Delay）的新指標。它衡量的是使用者在頁面上做任何操作（點擊、打字、觸碰）後，頁面要花多久才能回應並更新畫面。
| 等級 | 時間 | |------|------| | 好 | ≤ 200 毫秒 | | 需要改善 | 200 - 500 毫秒 | | 差 | > 500 毫秒 |
跟舊的 FID 只量第一次互動不同，INP 會追蹤整個頁面生命週期中的所有互動，取最差的那個（去掉離群值後）。這意味著你不能只優化首次載入，整個頁面使用過程都要流暢。
改善 INP 的關鍵：
減少 JavaScript 的主執行緒阻塞：瀏覽器的主執行緒一次只能做一件事。如果你的 JavaScript 正在執行一個耗時的運算，使用者的點擊就必須排隊等待。把長時間的任務拆分成小塊，用 requestIdleCallback 或 scheduler.yield() 讓出主執行緒。
延遲載入非必要的 JavaScript：使用者一開始不會用到的功能，不需要在頁面載入時就執行。聊天工具、分析追蹤碼、社群分享按鈕——這些都可以延遲載入。
避免過度的 DOM 操作：每次修改 DOM（網頁的結構），瀏覽器都需要重新計算樣式和排版。如果一次操作要修改上百個 DOM 元素，就會造成明顯的卡頓。盡量批次處理 DOM 修改。
第三方腳本管理：Google Analytics、Facebook Pixel、聊天插件、廣告追蹤碼——這些第三方腳本加在一起可能比你自己的程式碼還重。仔細檢查哪些是真正需要的，不需要的就拿掉。需要的也盡量延遲載入。
CLS：累計版面位移
**CLS（Cumulative Layout Shift）**衡量的是頁面載入過程中，畫面元素意外移動的程度。白話文：你正在看某段文字或準備點某個按鈕，結果畫面突然跳了一下，你點到別的東西——這就是版面位移。
| 等級 | 分數 | |------|------| | 好 | ≤ 0.1 | | 需要改善 | 0.1 - 0.25 | | 差 | > 0.25 |
CLS 是分數而不是時間，數字越小越好。它的計算方式是：位移面積乘以位移距離，然後取最大的那個窗口值。
造成 CLS 的常見原因：
沒有設定圖片和影片的尺寸：如果 <img> 標籤沒有指定 width 和 height，瀏覽器在圖片載入完成之前不知道要預留多少空間，圖片一載入就會把下面的內容擠下去。永遠在 HTML 裡指定圖片的寬高，或用 CSS 的 aspect-ratio 屬性。
動態插入的內容：廣告載入後突然插入頁面中間、cookie 通知彈出後推動內容、延遲載入的區塊高度跟預留空間不一樣。這些都會造成版面位移。解決方法是提前預留空間。
字體載入造成的位移：自訂字體和系統字體的大小可能不同，當字體載入完切換的時候，文字區塊的高度可能改變。使用 font-display: optional 或確保備用字體的大小跟自訂字體接近。
動態調整大小的元素：沒有明確尺寸的 iframe、embed、自適應廣告。盡量在容器上設定固定的 aspect-ratio 或最小高度。
怎麼測量你的 Core Web Vitals
在開始優化之前，你得先知道現在的成績。測量工具分成兩類：
實驗室數據（Lab Data）：在控制環境下模擬的結果，用來開發和除錯。
- Google PageSpeed Insights（pagespeed.web.dev）：最常用的工具，同時顯示實驗室和實際使用者數據
- Chrome DevTools Lighthouse：內建在 Chrome 瀏覽器裡，按 F12 就能用
- WebPageTest（webpagetest.org）：更進階的測試工具，可以指定地點、裝置、網路速度
實際使用者數據（Field Data）：真實使用者的體驗數據，這才是 Google 用來決定排名的依據。
- Google Search Console：「核心網頁指標」報告會告訴你哪些頁面不達標
- Chrome UX Report（CrUX）：收集 Chrome 使用者的真實體驗數據
- PageSpeed Insights 的上半部：如果你的網站有足夠流量，PSI 會顯示真實使用者數據
要注意的是，實驗室數據和實際使用者數據可能差很多。你的電腦可能載入只要 1 秒，但使用者用手機、4G 網路、舊手機，體驗可能完全不同。Google 看的是實際使用者數據，所以優化的目標要以它為準。
系統化的優化流程
不要看到一堆紅色指標就慌了。Core Web Vitals 的優化可以按照優先順序來做：
第一步：處理 LCP
LCP 通常是最容易改善、改善效果最明顯的。先把首屏的最大圖片處理好：壓縮、轉格式、加 preload。然後檢查伺服器回應時間，考慮使用 CDN。
具體動作清單：
- 用 WebP/AVIF 格式替換大型 JPEG/PNG
- 首屏主圖加上
<link rel="preload"> - 刪除未使用的 CSS 和 JavaScript
- 啟用 CDN 和瀏覽器快取
第二步：修復 CLS
CLS 的問題通常很明確——不是圖片沒設尺寸、就是廣告沒預留空間。找到問題源頭，修復起來通常很快。
具體動作清單：
- 所有圖片和影片設定明確的寬高
- 為廣告和動態內容預留空間
- 確認字體載入不會造成位移
- 避免在已有內容上方插入動態元素
第三步：改善 INP
INP 通常是最難處理的，因為它牽涉到 JavaScript 的執行效能。但也有一些快速見效的做法。
具體動作清單：
- 延遲載入非關鍵的第三方腳本
- 把大型 JavaScript 拆分成小塊
- 減少不必要的 DOM 元素數量
- 用 Web Worker 處理複雜運算
持續監控和維護
Core Web Vitals 不是優化一次就永遠沒問題。每次網站更新、加新功能、換廣告版位，都可能影響效能。
建議的做法：
設定效能預算（Performance Budget）：為每個指標設定目標值，並在開發流程中持續檢查。比如規定 LCP 不能超過 2 秒、CLS 不能超過 0.05。
自動化監控：用工具定期自動測試你的重要頁面，在指標惡化的時候及時收到通知。Google Search Console 會在你的 Core Web Vitals 出問題時寄通知信。
在部署前測試：新功能上線前，先在 staging 環境測量一下效能影響。上線後再用實際使用者數據確認。
定期清理：每隔幾個月檢查一次：有沒有不再需要的第三方腳本？有沒有可以進一步壓縮的資源？有沒有效能更好的替代方案？
Core Web Vitals 的優化看起來很技術，但它的核心邏輯很簡單：讓使用者快速看到內容、操作流暢、畫面不亂跳。把這三件事做好，不只排名會受益，使用者體驗也會大幅改善，轉換率自然跟著提升。
