CLS 修復怎麼做？找出版面偏移原因，改善網站穩定性與分數

CLS 是什麼？先分清楚這裡講的是版面偏移，不是車款或股票

這裡的 CLS 指的是 Cumulative Layout Shift，也就是 Core Web Vitals 裡衡量「版面偏移」的指標。它關心的是頁面載入或互動時，可見元素有沒有非預期移動；這裡不討論 Mercedes-Benz CLS 車款，也不討論 Celestica 的股票代號。

CLS 的三種常見意思：版面偏移、賓士車款、股票代號

為什麼本頁只談 Cumulative Layout Shift

輸入 cls 這種短詞時，搜尋結果很容易混入汽車、金融與技術 SEO 內容。若你的問題是 PageSpeed Insights 顯示 CLS 偏高、Search Console 出現 Core Web Vitals 問題，或手機版頁面載入時內容會跳動，那你需要處理的是網站版面穩定性。

Kevin Lin 在看台灣中小企業網站時，最常看到的不是單一技術錯誤，而是模板、外掛、廣告、圖片與字型一起造成的偏移。只看分數沒有用，重點是找出哪個元素跳動，以及它為什麼改變版面高度。

什麼情境代表你真的需要修 CLS

當使用者還沒點擊，頁面上的文字、圖片、按鈕、廣告或嵌入區塊就突然位移，通常就要檢查 CLS。尤其是手機版首頁、服務頁、文章頁與商品頁，這些頁面同時影響 SEO、閱讀體驗與轉換。

PageSpeed Insights 顯示 CLS 偏高

如果 PageSpeed Insights 顯示 CLS 超過 0.1，先不要急著裝速度外掛。你要看診斷提示、實際使用者資料與受影響裝置，確認問題是發生在桌機、手機，還是特定 URL 群組。

使用者看到按鈕、圖片、廣告區塊跳動

肉眼看得到的版面跳動通常比工具分數更有決策價值。常見狀況是圖片載入後把文字往下推、廣告出現後撐開版面，或頁首通知列插入後讓主要內容下移。

Search Console 的 Core Web Vitals 報告出現版面穩定性問題

Search Console 會用實際使用者資料呈現受影響 URL 群組。若同一批文章、商品頁或服務頁被歸在同一組，通常代表模板層級有問題，修單一 URL 的效益有限。

CLS 分數多少算好？修復前先看 0.1、0.25 與實際使用者資料

CLS 分數低於或等於 0.1 通常屬於良好，0.1 到 0.25 需要改善，大於 0.25 代表版面穩定性較差。修復前要同時看 lab data 與 field data，因為單次 Lighthouse 測試不能代表所有真實使用者。

CLS 0.1、0.25 的判斷方式

Lab Data 和 Field Data 差在哪裡

Lab data 是在固定測試條件下得到的實驗室資料，適合用來重現問題與比較部署前後。Field data 則來自真實使用者資料，例如 CrUX，能反映不同裝置、網路、地區與瀏覽器條件下的實際體驗。

SEO 執行上，lab data 用來修，field data 用來判斷影響範圍。只看其中一個，很容易誤判。

為什麼手機版 CLS 常比桌機版嚴重

手機螢幕窄，圖片比例、廣告高度、導覽列收合、中文字型換行與 Cookie Banner 都更容易改變版面高度。台灣企業網站常見狀況是桌機測起來正常，但手機 field data 很差，原因多半藏在 RWD 模板與第三方元件。

單次測試不等於真實使用者體驗

同一個頁面在不同時間測，分數可能受廣告、快取、字型與第三方 script 影響。修復 CLS 時，應記錄同一 URL、同一裝置條件與部署時間，才有可比較的依據。

行動網路、廣告載入、字型載入會放大偏移

當網路較慢時，圖片、廣告與字型更容易晚到。若版面沒有先保留空間，內容就會在載入後重新排列，手機使用者會更明顯感覺到版面跳動。

怎麼找出 CLS 問題？用 PageSpeed Insights、Lighthouse 和 Search Console 定位頁面

CLS 檢測要先用 Search Console 找受影響 URL 群組，再用 PageSpeed Insights 看分數與診斷提示，最後用 Lighthouse 或 Chrome DevTools 定位實際跳動元素。工具要分工使用，才不會只得到一個分數卻不知道怎麼修。

第一步：用 Search Console 找受影響的 URL 群組

先進入 Google Search Console 的 Core Web Vitals 報告，確認問題發生在手機版還是桌機版，再看受影響 URL 群組。若多個 URL 共用同一模板，例如文章頁、商品頁、服務頁，就優先判斷為模板問題。

第二步：用 PageSpeed Insights 看 CLS 分數與診斷提示

PageSpeed Insights 適合看單一 URL 的 lab data、field data、Core Web Vitals 狀態與診斷提示。檢查時要記錄 CLS 分數、裝置類型、是否有實際使用者資料，以及工具指出的可能偏移元素。

第三步：用 Lighthouse 或 DevTools 確認跳動元素

Lighthouse 適合做部署前後比較，Chrome DevTools 則適合追蹤 layout shift 發生時的元素。工程端需要的不是「CLS 很高」這句話，而是「哪個元素在什麼情境下推動了哪一塊內容」。

第四步：把問題分類成圖片、廣告、字型、嵌入、動態內容

1. 先標記受影響 URL 與裝置，例如手機版文章模板。
2. 記錄偏移元素，例如 Hero 圖、廣告版位、iframe、頁首通知列。
3. 判斷觸發情境，例如首次載入、字型切換、廣告填入、Cookie Banner 出現。
4. 把原因歸類成圖片尺寸、第三方內容、字型載入或動態插入內容。
5. 寫成可交辦需求，包含修復方式與驗收條件。

如何記錄問題頁、元素、裝置、觸發情境

如何把 SEO 問題轉成工程修復需求

不要只寫「改善 CLS」。較好的交辦方式是：手機版文章模板的首屏圖片未預留高度，圖片載入後推動標題與內文，請在模板層級加入 width、height 或 CSS aspect-ratio，並用 Lighthouse 比較部署前後 CLS。

圖片尺寸沒有預留，是最常見的 CLS 原因之一

圖片造成 CLS，通常是因為瀏覽器在圖片載入前不知道它要佔多少空間，等圖片出現後才把下方內容推開。修復重點是預先保留圖片比例與容器空間，尤其是 Hero 圖、Banner、文章封面圖與商品圖。

為什麼缺少寬高會讓版面跳動

當 <img> 沒有 width、height 或穩定比例時，瀏覽器可能先把圖片區塊當成零高度或錯誤高度。圖片載入後，實際高度才被計算出來，文字、按鈕與廣告就會被往下推。

圖片、Hero Banner、文章封面圖的修復方式

• 在圖片 HTML 加上正確的 width 與 height 屬性。
• 使用 CSS aspect-ratio 預留比例。
• 讓圖片容器在載入前就有穩定尺寸。
• Hero 圖與 Banner 不要等圖片載入後才撐開首屏高度。
• lazy loading 可以保留，但必須搭配固定比例或尺寸。

RWD 圖片比例變化時怎麼避免偏移

桌機與手機使用不同裁切比例時，不能只設定桌機尺寸。手機版若從橫幅改成直式比例，容器高度也要跟著定義，否則圖片一載入就會把首屏內容往下推。這是許多台灣企業網站首頁 CLS 偏高的主因之一。

為 <img> 加上 width 和 height

width 與 height 不只是控制顯示大小，也讓瀏覽器能在圖片下載前計算比例。即使 CSS 讓圖片寬度自動縮放，原始寬高仍能幫助瀏覽器保留正確空間。

使用 CSS aspect-ratio

對於卡片縮圖、文章封面、商品圖與 Banner，可以在容器上使用 aspect-ratio。這比等圖片載入後再決定高度更穩定，也更適合 RWD 模板。

避免圖片載入後才撐開容器

如果圖片區塊上方有標題、導覽列或重要 CTA，容器高度更要先固定。我的判斷是，首屏圖片的 CLS 風險通常比圖片檔案大小更急，因為它直接影響使用者第一眼看到的穩定感。

廣告、嵌入內容與第三方元件造成 CLS，要先保留版面空間

廣告、iframe、YouTube、社群貼文、地圖與表單工具造成 CLS，核心原因通常是第三方內容延遲載入後改變容器高度。修復時要先保留版面空間，並處理沒有填入內容時的 fallback 狀態。

廣告區塊為什麼容易造成版面偏移

廣告常在主內容載入後才填入，而且不同廣告尺寸可能高度不一。如果頁面一開始沒有預留廣告槽，廣告出現時就會把文章、商品資訊或按鈕往下推。對內容網站來說，文章段落中間的廣告尤其容易造成閱讀中斷。

YouTube、社群貼文、地圖、表單嵌入怎麼處理

第三方 script 載入順序與版面穩定性的關係

第三方 script 若在頁面穩定後插入新內容，就容易造成 layout shift。廣告、聊天工具、表單、推薦文章、社群嵌入都要檢查載入時機。SEO 執行者可以把這類問題標成「第三方元件插入造成 CLS」，工程端會更容易定位。

預設固定容器高度

廣告槽、影片、地圖與表單至少要有預設高度或比例。不能等第三方內容回傳後才決定版面，否則使用者會先看到內容，再看到內容被推走。

設定最小高度與 fallback 區塊

廣告沒有填入時，也要保留合理空間或用穩定的空白狀態處理。最糟的做法是有廣告時撐開、沒廣告時收掉，導致同一個模板在不同載入狀態下高度不一致。

避免插入內容時推動上方或主要內容

第三方內容若一定要延遲載入，應避免插在首屏主要內容上方。若必須出現在主要內容附近，就要先把區塊高度安排好，讓載入只改變內容，不改變整體版面。

字型載入造成文字跳動，要處理 FOIT、FOUT 與 fallback 字型

字型也會造成 CLS，尤其是 Google Fonts、Noto Sans TC 或多字重中文字型載入後，文字寬度與行高改變，導致標題、段落與按鈕重新排版。修復方向是控制字型載入策略、fallback 字型與首屏文字重排。

FOIT 和 FOUT 對 CLS 的影響

FOIT 是字型載入前文字暫時不可見，FOUT 是先用 fallback 字型顯示，正式字型載入後再替換。兩者都可能影響體驗；FOUT 若 fallback 字型與正式字型差異太大，就可能讓文字換行、按鈕變寬、標題高度增加。

font-display: swap 不是永遠等於零風險

font-display: swap 能讓文字先顯示，通常比空白文字友善，但它不代表 CLS 風險消失。如果 fallback 字型和正式字型的字寬、行高差很多，替換瞬間仍可能讓版面跳動。

如何選擇接近的 fallback 字型

台灣網站常用 Noto Sans TC、系統黑體與 Google Fonts。選 fallback 時，不要只看字型名稱，還要看字重、行高、中文字寬與標題換行。實務上，少用過多字重，比事後微調每個段落更有效。

控制字重數量

同一頁若載入太多字重，字型請求會增加，也更容易在不同元素上發生替換。首屏常用 400、500、700 已足夠，多餘字重應先刪掉。

預載關鍵字型

對首屏標題、導覽列與重要按鈕使用的字型，可以評估預載。預載不是越多越好，應針對真正影響首屏穩定性的字型檔，避免增加不必要請求。

減少首屏文字重排

若首屏標題在正式字型載入後從一行變兩行，CLS 風險就會上升。這類問題常被誤判成文案太長，其實是字型切換造成的排版差異。

動態內容、Cookie Banner 和彈窗會推動版面時，要改成不影響既有內容流

Cookie Banner、彈窗、sticky bar、會員提示與推薦商品若在頁面穩定後插入內容流，就可能造成 CLS。修復原則是覆蓋、固定或預留，不要突然把既有內容往下推。

Cookie Banner 為什麼可能造成 CLS

Cookie Banner 若載入後插入在頁面頂部，會把導覽列、標題或主要內容往下推。這種偏移在手機版特別明顯，因為 Banner 高度常比預期更高，還可能因多語內容換行。

Sticky bar、促銷條、會員提示怎麼避免推動內容

SPA 或動態渲染頁面要注意哪些版面變化

SPA 或大量使用 JavaScript 的網站，常在資料回來後才渲染卡片、推薦區塊或會員內容。若 skeleton、placeholder 與實際內容高度不同，就會造成版面偏移。這類問題在工具上可能不只顯示為速度問題，也會反映在 CLS。

使用 fixed 或 overlay 模式

Cookie Banner、聊天工具與彈窗若不需要佔用內容流，可以用 fixed 或 overlay。重點是不要讓它出現時改變原本內容的位置。

首屏預留通知區域

如果頁首通知列是固定營運需求，模板一開始就要保留高度。不要等促銷、公告或會員提示載入後才把整個頁面往下推。

避免在主要內容上方插入新 DOM

首頁主標、文章標題、商品名稱與主要 CTA 上方，應避免動態插入新 DOM。我的經驗是，這種偏移最容易讓使用者誤點，也最容易被網站團隊忽略。

CLS 修復優先順序：先修影響範圍大、行動版嚴重、模板層級的問題

CLS 修復要先處理影響範圍大的模板問題，再處理手機版嚴重、高流量、高轉換與可索引頁面。不要把時間花在低流量單頁的小偏移，卻放著整站共用模板持續跳動。

優先修模板，不要只修單一 URL

如果 Search Console 顯示一批 URL 同時受影響，通常代表文章模板、商品模板、服務頁模板或頁首頁尾元件有問題。修模板一次能影響多個頁面，SEO 效益也比較明確。

優先修手機版，不要只看桌機分數

Google 與真實使用者體驗都不能只看桌機。台灣中小企業網站常見情境是內部用桌機驗收，但使用者主要從手機進站。手機版 CLS 差時，應先修 RWD 圖片、行動導覽、廣告與通知元件。

優先修高流量、高轉換、可索引頁面

首頁、服務頁、商品頁、重要文章與自然搜尋流量高的頁面，應排在前面。若頁面同時承接廣告流量或表單轉換，版面穩定性也會影響實際商業結果。

什麼情況可以先不修

分數差但流量低

如果只有少數低流量頁面出現 CLS 問題，且不共用重要模板，可以先排在後面。但要確認它不是代表整個頁型的抽樣問題。

偏移發生在非關鍵互動後

某些偏移只在使用者展開選單、送出表單後發生，且不影響主要閱讀與轉換，可以先記錄觀察。判斷重點是它是否屬於非預期移動。

問題來自短期活動元件

短期活動 Banner 或限時彈窗如果快下架，可以先用最小修改穩住版面。但如果行銷團隊常重複使用同一元件，就應回到模板層級修好。

CLS 修完怎麼驗證？看分數回升、頁面不跳、Search Console 狀態更新

CLS 修復後要先用 Lighthouse 確認單頁改善，再用 PageSpeed Insights 比對 lab data 與 field data，最後到 Search Console 驗證修正。實驗室測試可立即反映，實際使用者資料需要時間累積。

修復後先用 Lighthouse 做單頁確認

部署到測試環境或正式環境後，先用 Lighthouse 測同一 URL、同一裝置條件。若修的是圖片、廣告或字型，最好同時用肉眼重新載入頁面，確認首屏不再跳動。

再用 PageSpeed Insights 檢查實驗室與實際資料

PageSpeed Insights 可以看當下測試結果，也能看是否有足夠的實際使用者資料。若 lab data 已改善，但 field data 尚未變化，先不要判定修復失敗，因為 CrUX 與 Search Console 都需要資料更新時間。

最後在 Search Console 驗證修正

Search Console 的 Core Web Vitals 報告適合確認 URL 群組是否逐步改善。當你已經完成模板修復，並用工具確認問題消失，再啟動驗證修正流程會比較合理。

為什麼 Field Data 需要時間反映

Field data 來自真實使用者資料，不會在你部署後立刻更新。這也是 CLS 專案常見的溝通落差：工程端已修、Lighthouse 已變好，但 Search Console 還在顯示舊狀態。這時要看部署日期、測試紀錄與資料更新週期，而不是反覆改同一段程式。

部署前後截點要記錄

至少記錄修復前分數、修復後分數、部署日期、受影響 URL 群組與修復項目。沒有截點，就很難判斷改善來自哪一次修改。

同一 URL 與同一裝置條件比較

不要拿桌機修復後分數去比較手機修復前分數，也不要換 URL 比較。CLS 驗收要固定 URL、裝置、網路模擬與測試工具，才有判斷價值。

分數改善但排名未立刻變動的判斷方式

CLS 是 Core Web Vitals 的一部分，也是網頁體驗訊號之一，但排名不會只因單一分數變好就立刻上升。可搭配 Core Web Vitals 完整指南、Google 排名因素 與 技術 SEO 指南一起判斷。若問題來自圖片，也可延伸檢查圖片 SEO 優化；若主要問題其實是載入速度，則應參考LCP 優化教學與SEO 優化檢查清單。