我是吳承學,做 SEO 二十多年。效能這件事,我看過太多網站把它當成上線後有空再優化的項目,結果變成永遠排不進行程的技術債。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. 首屏內容要在初始回應就看得見

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

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

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

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

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

2.3 我用來壓住位移的做法

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

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

大多數網站真正拖慢載入的,不是程式碼而是圖片。它通常是頁面裡體積最大的資源,也因此是投報率最高的優化對象。

3.1 用 WebP 取代舊格式

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

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

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

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

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

除了格式與大小,還有兩件事要顧:一是圖片的實際尺寸要符合顯示需求,不要拿一張很大的原圖硬塞進小縮圖的位置,那是在浪費頻寬;二是非首屏的圖片可以延遲載入,等使用者捲到附近再抓,把初始的頻寬留給首屏。這兩者搭配 WebP 與體積控制,圖片這個槓桿就用到位了。

4. 伺服器回應與狀態碼

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

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

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

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

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

4.3 重導與快取要顧

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

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 的根本做法,這也牽涉到你選擇的渲染架構。

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

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