最大內容在 2.5 秒內出現、版面位移壓在 0.1 以內、互動在 200 毫秒內有回應，這三個數字就是 Core Web Vitals 給你的及格線。它們值得在上線前就顧好，是因為量的不是抽象分數，而是使用者打開頁面那幾秒的真實感受：內容多久出現、版面會不會亂跳、點下去有沒有反應。這篇我們把三個指標的意義、首屏內容該怎麼安排、圖片與伺服器這兩個最大的槓桿，連同我們實際在用的上線驗收清單一次寫給你，讓效能變成可以逐項打勾的事，而不是上線後永遠排不進行程的技術債。

1. Core Web Vitals 衡量的是使用者實際的體感

這組指標的設計初衷，是把「這個網站用起來順不順」翻譯成可以量測的數字。搞懂每個指標對應的體感，你才知道優化到底在改善什麼，而不是盲目追一個分數。

1.1 三個指標各自量的是什麼

LCP 量的是最大一塊內容多久才顯示出來，對應「我等了多久才看到主要畫面」；CLS 量的是版面位移的程度，對應「內容有沒有在我要點的時候突然跳走」；INP 量的是頁面對互動的反應速度，對應「我點了之後多久才有回應」。三者合起來，大致就是一個使用者對載入體驗的完整感受。把它們拆開理解，優化時才知道該往哪個方向施力，而不是三個一起模糊地追。

指標	衡量的體感	建議門檻
LCP	最大內容多久顯示	2.5 秒以內
CLS	版面位移的幅度	0.1 以內
INP	互動的反應速度	200 毫秒以內

1.2 CLS 要壓在 0.1 以內的意義

CLS 這個 0.1 的門檻，對應的是一個很具體的挫折：你正要點某個按鈕，一張圖片突然載入把版面往下推，你點到了旁邊的東西。位移分數愈高，代表使用者遇到這種情況愈頻繁。把它壓在 0.1 以內，是在承諾畫面不會在使用者眼皮底下亂跳。這也是我們在驗收時盯得最緊的一個指標，因為它最直接影響誤觸與信任感，一個會亂跳的頁面，再好的內容也會被體驗拖累。

1.3 為什麼效能和 SEO 綁在一起

搜尋引擎把使用者體驗當成排名參考的一環，而 Core Web Vitals 就是它衡量體驗的一把量尺。我們不會說效能好就一定排名高，那太過簡化；但在內容品質接近的情況下，載入體驗差的頁面確實比較吃虧。更現實的是，慢、會跳的頁面本身就留不住人，跳出率高、轉換低，這些對整體表現的傷害往往比排名更早浮現。所以我們把效能當成體驗和成效的共同基礎，而不只是一個為了搜尋引擎而做的加分項。值得一提的是，這組指標用的是真實使用者的資料，也就是實際訪客在各種裝置、各種網路下的體感，而不是實驗室裡的理想值，所以它反映的是你的使用者真正經歷到的狀況。

2. 首屏內容要在初始回應就看得見

首屏，也就是使用者不用捲動就看到的那一塊，是整個載入體驗的第一印象。它出現得快不快、穩不穩，幾乎決定了使用者要不要留下來，也直接牽動 LCP 的表現。

2.1 首屏的文字與圖片不該等 JavaScript

首屏的主要文字與圖片，應該在伺服器的初始回應裡就存在，而不是等瀏覽器跑完 JavaScript 才補上。用檢視原始碼打開頁面，首屏那段標題、文字如果在原始碼裡就看得到，代表它會第一時間顯示；如果原始碼是空的、要靠腳本事後畫，使用者就得多等一輪，LCP 也會被拖長。這件事和渲染方式直接相關，首屏內容進得了初始回應，效能的底子才穩，這也是為什麼我們在談效能時，常常一路談到頁面的渲染架構。

2.2 版面位移多半來自沒有預留空間

CLS 高的頁面，問題常常出在圖片、廣告、嵌入元件載入前沒有替它們保留位置。瀏覽器一開始不知道這塊要多大，先把後面的內容往上擠，等元件載入才把它們推開，位移就發生了。字型太晚載入、載入後文字尺寸改變，也會造成同樣的跳動。找出這些「事後才佔位」的元素，是降 CLS 的第一步，而且通常改起來不難，難的是在上線前就把它們揪出來。

2.3 我們用來壓住位移的做法

我們最常做的一件事，是要求所有圖片與影音元件都明確標出寬高，或以 CSS 預留固定的長寬比，讓瀏覽器在內容載入前就把位置留好。這樣圖片載進來時是填進既有的框，而不是把版面撐開。我們診斷過一個商品列表，CLS 一直過不了關，追下去就是縮圖沒有指定尺寸，補上寬高屬性之後，分數當天就掉到門檻以內。這種問題改起來不難，難的是有沒有在上線前把它揪出來，而不是等使用者先踩到。

2.4 INP 反映的是點下去有沒有卡

除了看得到的位移，互動反應 INP 量的是使用者點擊、輸入之後，頁面多久才給出視覺回饋。它變差的常見原因，是主執行緒被過重的腳本佔住，瀏覽器忙著跑程式碼，來不及回應點擊。首屏塞了太多一次載入的第三方腳本，往往就是元兇。我們的處理方向是把非必要的腳本延後或拆分，讓主執行緒在使用者可能互動的時候保持空檔。這一項不像 LCP、CLS 那麼直覺，卻是使用者「覺得這網站很頓」的主要來源，值得在驗收時一併看。

3. 圖片是效能最大的槓桿

大多數網站真正拖慢載入的，不是程式碼而是圖片。它通常是頁面裡體積最大的資源，也因此是投報率最高的優化對象，先從這裡下手往往事半功倍。我們在替網站做效能體檢時，常常光是把圖片這一塊整頓好，整體分數就拉進及格範圍，連腳本都還沒動。原因很單純：一張沒壓縮的大圖動輒佔掉整頁一半以上的傳輸量，處理它的效益遠比省那幾 KB 的程式碼明顯。

3.1 用 WebP 取代舊格式

同樣的畫質，WebP 的檔案通常比傳統的 JPEG、PNG 小上一截。把主要圖片改用 WebP，往往不需要犧牲肉眼可見的品質，就能明顯減少要下載的位元組，LCP 跟著改善。這是我們接手網站後，最早會建議的技術調整之一，因為它範圍明確、風險低、效果看得到，不必大動架構就能換來實質的載入改善。

格式	相對檔案大小	適合場景
WebP	較小	網站主要圖片的優先選擇
JPEG	中等	相片類、不支援 WebP 時的退路
PNG	較大	需要透明背景或線條圖示

3.2 單張圖片盡量控制在 200KB 以內

我們給一般內容圖片訂的參考線是單張 200KB 以內，首屏的主視覺可以稍微放寬，但也不該無限膨脹。很多網站的圖片是設計稿直接匯出、沒有壓縮就上線，一張動輒好幾 MB。光是把這些圖片壓到合理大小，整頁的載入時間就會有感縮短。控制單張大小，比事後做一堆複雜優化都來得直接，也是最容易讓非技術團隊理解並執行的一條規則。

3.3 尺寸標對、非首屏延遲載入

除了格式與大小，還有兩件事要顧：一是圖片的實際尺寸要符合顯示需求，不要拿一張很大的原圖硬塞進小縮圖的位置，那是在浪費頻寬；二是非首屏的圖片可以延遲載入，等使用者捲到附近再抓，把初始的頻寬留給首屏。這兩者搭配 WebP 與體積控制，圖片這個槓桿就用到位了。順序上我們會先處理首屏的主圖，因為它同時影響 LCP 和第一印象，回收最快。

3.4 讓手機與桌機各取合適的圖

同一張圖，手機和桌機需要的解析度其實不同。讓瀏覽器依裝置挑選合適尺寸的圖片，手機就不必下載一張為大螢幕準備的大圖，能再省下一截頻寬。很多網站忽略這點，不分裝置一律送同一張高解析度原圖，手機使用者因此白白多等。這需要在圖片輸出時就準備幾種尺寸，前期多一點工，換來的是行動端明顯更快的載入，對以手機為主要流量的網站特別值得。

4. 伺服器回應與狀態碼

圖片顧好之後，另一個影響載入的源頭在伺服器這一端。它回應得快不快、狀態碼對不對，都會反映在使用者的等待與搜尋引擎的判讀上。

4.1 伺服器回應時間直接影響 LCP

使用者送出請求到伺服器吐出第一個位元組的時間，是整條載入鏈的起點。這一段慢，後面所有優化都在替它墊背，LCP 很難好看。資料庫查詢沒有快取、伺服器負載過重，都會反映在這裡。我們看載入問題時，習慣先確認起跑點正不正常，再往資源大小去追，否則在圖片上花再多力氣，也補不回伺服器拖掉的那一截。

講個匿名的實例。我們接手過一個頁面，圖片都壓好了、格式也換成 WebP，LCP 卻始終卡在四秒上下，怎麼調圖片都降不下來。後來一量伺服器吐出第一個位元組的時間就明白了：光這一段就花掉將近一點八秒，問題出在首頁那幾支沒有快取的資料庫查詢。把查詢結果加上快取之後，這一段壓到半秒以內，LCP 當天就掉進三秒以內，圖片一張都沒再動。這件事提醒我們，遇到 LCP 降不下來別急著反覆壓圖，先確認起跑點是不是本身就慢。

4.2 狀態碼要如實反映頁面狀態

正常頁面回應 200、永久搬遷回應 301、不存在的頁面回應 404，這些狀態碼要如實。最常見的坑是「軟性 404」：頁面內容明明不存在，卻回應 200，搜尋引擎於是把一堆空殼頁當成正常頁收錄，稀釋整站品質。狀態碼是伺服器對搜尋引擎說的話，說錯了，後面的判讀全跟著錯。這類問題肉眼不一定看得出來，卻會悄悄拖累整站的收錄品質。

4.3 重導與快取要顧

過長的重導鏈會一段段拖慢載入，每一跳都是額外的往返；能一步到位就別讓連結繞路。快取則相反，是替你加速的工具：靜態資源設定合理的快取，回訪的使用者不必重新下載，載入自然更快。這兩件事一個是減法、一個是加法，方向相反但都指向同一個目標，就是讓頁面更快出現在使用者眼前。我們在驗收時會順手檢查有沒有不必要的重導，以及靜態資源的快取設定是否合理。

4.4 用 CDN 把資源放得離使用者近一點

如果你的使用者分布在不同地區，把圖片、樣式這類靜態資源透過內容傳遞網路分送，能縮短它們傳到使用者端的距離，載入時間跟著下降。這對首屏的主圖尤其有感，因為它直接關係到 LCP。CDN 不是每個網站都非用不可，小型、流量集中在單一地區的站未必需要；但一旦使用者地理分布變廣，它往往是性價比不錯的一步。我們會依使用者的實際分布來判斷要不要導入，而不是一律套用。

5. 上線效能驗收清單

效能最怕上線後才發現，而那時使用者已經在承受慢與跳。我們把驗收前移到上線前，壓成幾個可以逐項打勾的動作，讓團隊不必是效能專家也能照著跑一遍。這份清單的重點不在面面俱到，而在抓住最常出問題、又最容易被忽略的幾個環節，花最少的時間擋下最多的隱患。以下三步照順序做，從結構、體感到資源逐層把關。

5.1 用檢視原始碼確認首屏內容在初始回應裡

按 Ctrl+U 打開原始碼，搜尋首屏那段主要文字。找得到，代表首屏內容會第一時間顯示；找不到，代表它要等 JavaScript 補畫，LCP 會被拖累。這一步不需要任何工具，卻能在最前面就擋下最傷 LCP 的結構問題。我們會把它當成驗收的第一關，因為它最省力、也最能反映渲染架構的根本狀況。

5.2 實際量測 CLS 與載入表現

用效能量測工具跑主要模板，重點看 CLS 有沒有壓在 0.1 以內、LCP 是否落在合理範圍。CLS 過高就回頭找沒有預留空間的元素；LCP 過長就從伺服器回應與圖片兩個方向拆。量測要涵蓋首頁、列表、詳情這幾種模板，不能只測首頁就當作全站過關，因為不同模板的瓶頸常常不一樣。

5.3 抽查圖片格式、大小與狀態碼

抽幾頁檢查圖片是不是 WebP、單張有沒有超過參考的 200KB、有沒有標尺寸。再抽幾個網址確認狀態碼如實：正常頁 200、搬遷頁 301、不存在的頁面 404，特別留意有沒有軟性 404。這三項是效能與可索引性交界的地方，一次抽查就能把大部分隱患攤在眼前，也方便列成固定的上線檢查表交給團隊重複使用。

6. 常見問題

6.1 Core Web Vitals 分數不好，排名一定會掉嗎

不能這樣直接畫等號。搜尋引擎把體驗當成參考之一，但內容品質仍是主軸。比較實際的說法是：內容相近時，載入體驗差的頁面比較吃虧；而且慢、會跳的頁面本身就留不住人，對轉換的傷害常常比排名更早出現。把它當成體驗的基礎來顧，比只盯著一個分數更有意義。我們的建議是先求及格、別追滿分，把三個指標都拉進門檻以內，剩下的力氣留給內容本身，通常比硬把分數從良好再往上擠划算。

6.2 CLS 一直過不了 0.1，通常是哪裡出問題

多半是有元素在載入前沒有預留空間，例如沒指定寬高的圖片、事後插入的廣告或嵌入元件、太晚載入又改變尺寸的字型。替這些元素預留固定的位置或長寬比，讓內容填進既有的框而不是把版面撐開，分數通常會明顯下降。先用量測工具找出是哪個元素造成位移，再針對它處理，比整頁亂猜有效率。

6.3 圖片一定要換成 WebP 嗎

不是硬性規定，但它在相同畫質下檔案通常更小，是投報率很高的調整。你可以把 WebP 當主要選擇，遇到需要透明背景的用 PNG、相片類在不支援時退回 JPEG。重點是別讓沒壓縮的大圖直接上線，格式只是其中一環，體積控制才是關鍵。

6.4 首屏內容要放進初始 HTML，和渲染方式有關嗎

有直接關係。如果頁面是前端渲染，首屏內容要等 JavaScript 執行才出現，LCP 會被拖長。讓首屏主要文字與圖片在伺服器的初始回應裡就存在，是改善 LCP 的根本做法，這也牽涉到你選擇的渲染架構。要被索引又重視載入速度的頁面，把內容放進初始回應通常是比較穩的選擇。換句話說，效能問題有時不是單純調圖片、壓腳本就能解，而要回頭看頁面是怎麼被產生出來的，這也是我們在排查 LCP 時，常常把渲染方式一起納入考量的原因。

6.5 上線前效能驗收，最少要做哪幾件事

三件：用檢視原始碼確認首屏內容在初始回應裡、用工具量測主要模板的 CLS 與 LCP、抽查圖片格式大小與狀態碼是否如實。這三項涵蓋了結構、體感與資源三個層面，能擋下絕大多數上線後才爆的效能問題。做完這三關再上線，比上線後救火省事得多。

6.6 手機和電腦的分數差很多，該以哪個為準

以手機為準。多數網站的主要流量來自手機，而手機的網路與運算條件通常比電腦差，瓶頸也更明顯。我們量測時一律先看手機版的表現，把手機過關當成基本要求，電腦版順帶確認即可。若兩者落差很大，通常是圖片或腳本在行動環境下的負擔被放大，順著這個方向查多半能找到原因。

6.7 量測工具跑出來的分數，每次都不太一樣正常嗎

正常。單次量測會受當下網路、伺服器負載、甚至第三方腳本回應速度影響，出現波動很常見。所以我們不會只看一次結果就下判斷，而是多跑幾次看趨勢，並且優先參考真實使用者資料的長期走向。與其糾結某一次的數字，不如確認同一個問題是不是反覆出現；穩定重現的問題才值得花力氣處理，偶發的波動通常會自己平復。

6.8 已經上線的舊頁面，Core Web Vitals 要怎麼排優先順序來改

我們的原則是照流量與商業價值排，不是照分數高低排。先把帶來最多流量、又離轉換最近的那幾個模板挑出來，哪怕它們的分數只差一點點，改善的回報也比去救一個幾乎沒人看的頁面大。同一個模板通常套用在成百上千頁上，所以改一個模板等於一次改掉一整批。我們會先量出各主要模板的 LCP 與 CLS，對照它們的流量與詢問貢獻，把力氣集中在高流量又不及格的那幾個，剩下的長尾頁面排在後面慢慢收。這樣同樣的工時，換到的整體體驗改善最大。