Core Web Vitals 怎麼查？LCP、INP、CLS 的判讀與改善順序

把 LCP、INP、CLS 拆成可量測的載入、互動與版面穩定問題，分清現場資料與實驗室測試，再安排改善順序。

三個指標，其實對應三種完全不同的病

Google 用 Core Web Vitals 這一組核心指標，把使用者體驗切成「載入、互動、穩定」三個面向，各由一個指標代表。這些門檻不是拍腦袋訂的，而是綜合人因研究與全球數十億次真實造訪校準出來的合理界線。

LCP（Largest Contentful Paint，最大內容繪製）量的是載入速度，也就是視窗裡最大的那塊主要內容——通常是首圖、影片封面或主標題——多久才真正畫到螢幕上。良好門檻是 2.5 秒以內，介於 2.5 到 4 秒是「需要改善」，超過 4 秒就是「差」。
INP（Interaction to Next Paint，互動到下次繪製）量的是反應速度，使用者每一次點擊、輕觸或按鍵之後，畫面要多久才給出下一幀視覺回饋。良好門檻是 200 毫秒以內，超過 500 毫秒算差。它在 2024 年 3 月正式取代了只看第一次互動的舊指標 FID，改成統計整個瀏覽期間「最差的那幾次互動」，門檻明顯拉高，很多過去看似合格的站台一換算就露餡。
CLS（Cumulative Layout Shift，累計版面位移）量的是視覺穩定度，頁面在載入與互動過程中，元素非預期地跳動了多少。它是沒有單位的比例值，良好門檻是 0.1 以下，超過 0.25 就是差。

先搞懂一件事：你測的是實驗室，還是真實使用者

這是最多人踩的坑。工程師在自己那台高階筆電、接著公司光纖、開無痕視窗跑一次工具，看到分數漂亮就收工，可是客戶的客人是拿三年前的中階手機、在停車場邊走邊連 4G。這兩個世界的數字可以差上好幾倍。

所以 Core Web Vitals 有兩種資料來源要分清楚。實驗室資料是在固定的模擬條件下跑出來的單次結果，適合開發階段除錯、比較改動前後的差異，但它只是一個切片。真正決定 Google 怎麼看你這個頁面的，是現場資料，也就是實際使用者瀏覽器回報、過去 28 天累積的匿名效能紀錄。而且它取的是第 75 百分位：要讓 75% 的造訪都達標，這個頁面才算「良好」。這個設計很關鍵——它逼你不能只服務網路好、手機新的那群人，而是要照顧到大多數人的實際體驗。判斷一個站好不好，我一定先看現場資料，實驗室數字只拿來找原因。

LCP 拆解：慢在「等」，還是慢在「傳」

LCP 看起來只是一個秒數，但把它拆開，會發現時間花在四個完全不同的階段，而每個階段要動的地方天差地遠。

首位元組時間（TTFB）：從使用者按下前往，到瀏覽器收到伺服器回傳的第一個位元組。這一段慢，問題在後端——主機太弱、資料庫查詢肥、沒有快取、機房離使用者太遠。
資源載入延遲：從收到 HTML 到瀏覽器「發現」那張主圖、開始下載之間的空窗。這一段慢，多半是圖片藏在 CSS 或 JavaScript 裡太晚才被解析出來，屬於前端結構問題。
資源載入時長：真正下載那張主圖所花的時間。這一段慢，就是圖片檔太大、格式老舊，或頻寬不足。
元素繪製延遲：資源都到齊了，卻還要等主執行緒忙完別的事才畫得出來。這一段慢，通常是渲染被龐大的腳本卡住。

INP 拆解：卡在輸入、運算，還是繪製

INP 是三個指標裡最難處理的，因為它牽涉到程式碼實際在做什麼。一次互動從按下到畫面更新，同樣可以拆成三段，而它們的平均佔比很能說明問題所在。

輸入延遲：從使用者動作發生，到瀏覽器有空開始跑對應事件的等待時間，平均約佔 INP 的兩成。它幾乎純粹是「主執行緒正被別的長工作卡住、抽不出身」造成的排隊。
處理時間：真正執行事件處理程式、跑你寫的那段邏輯的時間，平均約佔四成。
繪製延遲：邏輯跑完之後，瀏覽器把版面重新計算、重繪成下一幀的時間，平均約佔四成多，往往是最大宗。

這個佔比透露了兩個重點。第一，輸入延遲告訴你，只要主執行緒上有超過 50 毫秒的「長工作」，任何點擊都得排隊等它跑完，所以把肥大的腳本切成小塊、適時把控制權交還給瀏覽器，是降低延遲最直接的手段。第二，繪製延遲常常才是真兇，而它多半跟頁面結構太複雜、DOM 節點太多有關——節點越多，瀏覽器每次重算版面就越吃力。很多人一遇到 INP 差就拼命刪功能，其實更該檢查的是有沒有把畫面塞了幾千個節點、或用了大量會逼瀏覽器反覆重排的寫法。簡化結構、減少一次互動要牽動的畫面範圍，往往比砍功能更有效。

CLS 的計分邏輯：版面「跳一下」到底扣幾分

CLS 是三者中最容易被誤解的，因為它不是時間，而是一個位移分數。每一次非預期的版面位移，分數等於影響範圍比例乘上位移距離比例：前者是這次跳動波及了視窗裡多大面積，後者是元素移動的距離相對於視窗尺寸有多遠。兩者相乘再把整個瀏覽期間所有位移累加，就是 CLS。

搞懂這條公式，改善方向就很明確：要嘛縮小被波及的面積，要嘛縮短跳動的距離，最好是根本不讓它跳。實務上最常見的元凶就那幾個——圖片與影片沒有事先寫死寬高，瀏覽器拿到檔案前不知道要留多少位子，內容一到就把下面全部往下推；廣告或嵌入區塊沒有預留容器；還有自訂字體載入完成的瞬間，文字尺寸抽換造成整段重排。對應的做法是幫每個媒體元素明確標注尺寸或長寬比、替動態插入的區塊預留固定空間、並妥善處理字體載入。最氣人的情境大家都遇過：你正要按下「確認」，版面突然一跳，手指落在旁邊的廣告上——CLS 高的頁面，就是在反覆製造這種讓人想關掉的瞬間。

這三個數字，為什麼值得老闆掏錢顧

把效能顧好，從來不只是工程師的潔癖，它同時牽動搜尋排名與實際營收兩條線。

在 SEO 這一端，Core Web Vitals 是 Google 頁面體驗評估的一部分，會影響搜尋表現。它通常不是決定排名的最大變數，但在內容水準相近時，它就是那個把你往前推或往後拉的分水嶺；而且它是少數你完全能靠工程改善、握在自己手裡的排名因素。

速度、轉換率與維護成本的改善幅度會受網站內容、流量來源、裝置與技術架構影響。先量目前的 Core Web Vitals、錯誤率與轉換漏斗，變更後用同一期間及相同口徑比較，不拿未附樣本與日期的比例當保證。

幾個最常見的誤區

只在自己電腦上測就滿意：前面說過，決定成績的是真實使用者的第 75 百分位，不是你那台高階機器跑一次的漂亮數字。
把總分當診斷：一個籠統的效能分數告訴你「有病」，卻不告訴你「病在哪」。不先做子階段拆解就動手，等於閉著眼睛開刀。
為了衝分砍功能：多數效能問題是「怎麼載、怎麼寫、怎麼排版」的工程問題，而不是「功能太多」。先優化實作，再談取捨。
一次到位的迷思：效能會隨著改版、加外掛、換素材而退化。它需要的是定期健檢，而不是一次性的大掃除。

廷皓科技為高雄與南台灣的企業做網站效能健檢，我們的做法是先抓現場資料、再逐一拆解 LCP、INP、CLS 的子階段，找出真正吃掉時間的那一段，對症下藥，而不是盲目套用網路上的優化清單。如果你也常聽到客人或同事說「網站好像有點慢」，卻說不上來慢在哪，歡迎找我們做一次完整的健檢，把感覺變成數字，再把數字變成生意。