從指標看使用者體驗#
上一章的量測工具會丟出一堆看似專業的 metric 名稱，但光看英文縮寫往往猜不出意義。本章會聚焦兩組「以使用者為中心」的效能指標：
- Core Web Vitals：Google 提出、與搜尋排名連動的核心指標。
- RAIL 模型（Response, Animation, Idle, Load）：以使用者行為為中心的效能評估框架。
兩者的精神都是：效能不是工程師自爽的數字，而是使用者真實感受的具體量化。
Core Web Vitals 是什麼？#
Core Web Vitals 是 Google 從大量使用者體驗資料中歸納出的核心指標，目前由三個面向組成：
- 最大內容繪製（LCP, Largest Contentful Paint）：載入速度。
- 首次輸入延遲（FID, First Input Delay）：互動性。
- 累積版面位移（CLS, Cumulative Layout Shift）：視覺穩定性。
Google 指出，當網站有 75% 以上的使用者都能通過 Core Web Vitals 的門檻時，因為等待而離開的人數可以減少約 24%。指標分數最終會回饋到實際的留存率上。
雖然 Core Web Vitals 不只反映「速度」，但效能優化幾乎是改善這些分數最有效的手段，因此把它當成優化的北極星指標是合理的。
補充說明：FID 已於 2024 年 3 月由 Google 正式以 互動到下次繪製（INP, Interaction to Next Paint）取代為 Core Web Vitals 的互動性指標。本章內容仍以原文為主介紹 FID，但實務上現在量測互動性時應改看 INP。
LCP（Largest Contentful Paint）—— 速度指標#
LCP 量測的是「可視區（viewport）內最大內容元素的載入完成時間」，反映使用者看到主要內容的時間點。
注意：可視區內的最大元素並非固定不變。網頁載入過程中，最大元素可能從一段文字變成一張圖、再變成一段影片；LCP 會以「最終那個最大元素」的呈現時間為準。
目前會被 LCP 納入計算的 DOM 元件包含：
<img>元素- 包在
<svg>內的<image>元素 <video>元素- 透過 CSS
url()載入background-image的元素 - 包含文字節點或 inline-level 文字子元素的 block-level 元素
如何優化 LCP#
優化方向大致可分成「縮短伺服器回應」、「減少阻塞」、「加快資源載入」三類：
- 縮短伺服器回應時間（與 Time To First Byte (TTFB) 直接相關）：主機效能調校、使用地理位置較近的 CDN、善用瀏覽器快取、提早建立第三方資源連線。
- 減少阻塞時間：降低關鍵 JavaScript 與 CSS 的 blocking time。
- 加快資源載入：圖片壓縮與適切尺寸、預先載入關鍵資源、文字檔壓縮、根據網路狀況提供不同等級的內容、使用 Service Worker。
- 渲染策略：純客戶端渲染（CSR）會讓 LCP 變差，能在伺服器端把首屏渲染好就盡量伺服器端做。
FID（First Input Delay）—— 互動性指標#
FID 量測使用者第一次與頁面互動（例如點擊按鈕、點擊連結）時，瀏覽器多久才開始處理該事件。它只看「離散事件」，不會把滾動、縮放等連續性操作算進來。
FID 變差最常見的原因是瀏覽器的主執行緒（Main Thread）正在忙：可能是執行一支龐大的 JavaScript bundle、可能是某段同步運算太久。當主執行緒卡住時，使用者點什麼都沒反應，這種「點了沒反饋」的瞬間就是 FID 想衡量的痛點。
如何優化 FID#
- 減少 JavaScript 的執行時間（例如 code splitting、tree shaking）。
- 減少請求數量並降低檔案大小。
- 減少主執行緒的工作量（拆分長任務、使用 Web Worker）。
- 評估第三方腳本帶來的負擔，必要時延後或移除。
CLS（Cumulative Layout Shift）—— 穩定性指標#
有沒有過這種經驗：正要點某個按鈕時，畫面突然彈出一個廣告或是補了一張圖，整個版面瞬間下移，結果手指點到完全不想點的東西？這就是 CLS 想要避免的「非預期版面位移」。
容易造成 CLS 變差的常見原因：
- 圖片、廣告、
<iframe>沒有給定固定的寬高，載入後才把空間「撐」出來。 - 動態插入內容（例如非預期的 banner）。
- 字體載入造成 FOUT/FOIT，文字尺寸忽然改變。
- 在 DOM 更新前等待網路回應，導致畫面元素抖動。
如何優化 CLS#
CLS 與「速度」較無關，更像是設計與實作層面的問題：
- 為圖片、影片、廣告位等預設固定的寬高或 aspect-ratio。
- 字體可透過
preload等 resource hint 提早載入，避免後期切換造成位移。 - 動態插入內容時，盡量插在使用者視線之外，或預先保留空間。
CLS 的計算方式#
CLS 是介於 0 到 1 之間的分數，計算公式為：
layoutShiftScore = impactFraction * distanceFraction;- impactFraction：受影響範圍佔可視區的比例。
- distanceFraction：元素位移距離佔可視區的比例。
舉例：某元素影響範圍是螢幕的 75%，位移距離是螢幕的 25%，這個位移的分數就是 0.75 × 0.25 = 0.1875。整個網站的 CLS 分數則是把所有非預期位移的分數加總，目標是 0.1 以下。
CLS 在意的是「非預期」的位移。如果是使用者點擊選單後才展開的清單，這種與互動連動的動畫不會被算進 CLS。
用 NPM 模組量測 Core Web Vitals#
除了透過 Lighthouse 等工具，Google 也提供了 Web Vitals 的 NPM 套件，可以在自家程式裡直接收集這些指標、再送到分析後台：
import { getCLS, getFID, getLCP } from "web-vitals";
function sendToAnalytics(metric) {
const body = JSON.stringify(metric);
(navigator.sendBeacon && navigator.sendBeacon("/analytics", body)) ||
fetch("/analytics", { body, method: "POST", keepalive: true });
}
getCLS(sendToAnalytics);
getFID(sendToAnalytics);
getLCP(sendToAnalytics);這種「在真實使用者瀏覽器上收集」的資料稱為 RUM（Real User Monitoring），與 Lighthouse 那種實驗室資料互補，能更貼近真實情境。
RAIL 模型（Response, Animation, Idle, Load）#
RAIL 模型（Response, Animation, Idle, Load）是 Google 提出的另一個以使用者為中心的效能框架。它把網頁生命週期拆成四種使用者行為，並對每一種行為訂出可量化的時間預算。
Response：50ms 內回應#
研究指出，人類從操作到感知反應之間有大約 100ms 的容忍時間。為什麼 RAIL 訂的目標是 50ms？因為瀏覽器除了處理輸入事件之外，還有其他必須完成的工作（例如 idle 任務）。把總預算 100ms 扣掉這些必要工作，留給輸入處理的時間實際大約只有 50ms。
Animation：每幀 10ms 內完成#
多數裝置以每秒 60 次的頻率重新整理螢幕，也就是每幀只有約 16ms 的時間預算。瀏覽器自身渲染一幀約需 6ms，因此實際留給應用程式的工作時間大約是 10ms。超過這個值，動畫就會出現掉幀、卡頓。
Idle：盡量擴大 idle 時間#
idle 時間是讓主執行緒「有空檔」回應使用者輸入的關鍵。建議：
- 把可延後的工作丟到 idle time 執行（例如非首屏資料的預先載入）。
- 每段 idle 工作最好控制在 50ms 以內，避免擠壓到輸入回應的能力。
- 一旦使用者開始互動，idle 工作必須讓出主執行緒。
Load：5 秒內可互動#
考量到實際使用者可能使用中低階手機與緩慢的 3G 網路，RAIL 訂出的 Load 目標是：在這種環境下，網站應該在 5 秒內載入完成並達到可互動。也就是說 Load 的標準不是「在你 MacBook 上幾秒」，而是「在最差情境下幾秒」。
RAIL 的數字看起來很零碎，但每一個都有它的研究依據，是大量使用者體驗資料整理出來的結論，可參考性很高。
本章重點#
- Core Web Vitals 三大指標反映三種使用者感受：載入速度（LCP）、互動回應（FID／INP）、視覺穩定（CLS）。
- LCP 看「最大內容元素何時呈現」、FID 看「第一次互動是否卡住」、CLS 看「畫面有沒有亂跳」。
- 改善 LCP 與 FID 大多靠「減少阻塞、減少工作量」；CLS 則是設計與實作上的「先給空間」。
- RAIL 模型用使用者行為（Response、Animation、Idle、Load）切分效能目標，每個動作都有具體的時間預算可遵循。
- 量測時可結合 Lighthouse 的實驗室資料與 Web Vitals 套件的真實使用者資料，互補更全面。