CLS修正怎麼做？找出版面位移原因、常見修法與驗收重點

先確認：本文的 CLS 是 Cumulative Layout Shift

CLS 修正指的是修正 Core Web Vitals 裡的 Cumulative Layout Shift，也就是網頁載入或互動過程中的非預期版面位移；這裡不處理 Windows 指令、.NET 規範、股票代號或法律文件。

定義框：在網站效能與 SEO 語境中，CLS 代表累積版面位移，用來衡量使用者看到的內容有沒有突然跳動。常見問題是圖片、廣告、iframe、字體或第三方腳本載入後，把已經出現在畫面上的內容推開。

CLS 修正、CLS 改善、CLS 優化差在哪？

三個說法在實務上多半指同一件事：找出版面位移來源，保留穩定空間，讓頁面載入前後的位置一致。若要精準一點，「CLS 修正」偏工程處理，「CLS 改善」偏分數變好，「CLS 優化」偏整體頁面體驗調整。

為什麼搜尋 CLS 修正會看到 Microsoft、股票或法規頁？

因為 CLS 是同縮寫字。搜尋引擎可能同時抓到 Clear Screen、Common Language Specification、股票代號或文件修正頁。判斷是否相關，只要看頁面是否提到 Core Web Vitals、Cumulative Layout Shift、PageSpeed Insights、Search Console 或 layout shift。

CLS 是什麼？分數多少才算正常？

CLS 是衡量「非預期版面位移」的 Core Web Vitals 指標；分數小於等於 0.1 通常視為良好，0.1 到 0.25 需要改善，大於 0.25 屬於不良。

CLS 衡量的是「非預期」的版面位移

使用者點開頁面後，已經看到的文字、按鈕、商品圖或表單欄位突然移動，就可能形成 layout shift。若位移是使用者點擊、展開選單後立即發生，通常較合理；若廣告或圖片自己載入後把內容推開，就會傷害體驗。

CLS 分數標準：良好、需要改善、不良

CLS 分數	狀態	實務解讀
0.1 以下或等於 0.1	良好	大多數使用者看到的版面穩定
大於 0.1 到 0.25	需要改善	已有明顯跳動，熱門頁與商業頁應優先處理
大於 0.25	不良	通常有圖片、廣告、iframe 或動態區塊未預留空間

Lab data 與 field data 看到的 CLS 為什麼可能不同？

lab data 是 Lighthouse 這類工具在固定條件下測出來的結果，適合重現問題。field data 是真實使用者資料，常來自 CrUX，會受到裝置、網路、地區、瀏覽器與實際流量影響。我的判斷是：修問題時先看 lab data 找元素，驗收 SEO 風險時再看 field data。

CLS 為什麼重要？它如何影響使用者體驗與 SEO？

CLS 重要，是因為版面跳動會讓使用者誤點、看不到內容或中斷結帳流程；SEO 上它屬於頁面體驗訊號之一，不是單一排名開關。

使用者看到的問題：按鈕跑掉、廣告推擠、首圖跳動

最典型的狀況是使用者正要點 CTA 按鈕，上方廣告突然載入，把按鈕往下推；或商品頁主圖晚載入，價格與加入購物車區塊被擠動。這種跳動不只影響分數，也會讓人對網站品質扣分。

SEO 角度：CLS 是頁面體驗訊號，不是單一排名開關

Google 會把 Core Web Vitals 視為實際使用者體驗的一部分。CLS 不會單獨決定排名，但當兩個頁面內容品質、搜尋意圖匹配度接近時，穩定、好用、低干擾的頁面通常比較有競爭力。

電商與表單頁為什麼特別該修 CLS？

電商與表單頁的每一次位移都可能發生在關鍵動作前，例如選規格、填手機、點付款、送出詢問。內容站的 CLS 可能只是閱讀不順，商業頁的 CLS 會直接干擾轉換，這也是我會把商業頁排在修正前段的原因。

CLS 常見原因：哪些元素最容易造成版面位移？

CLS 太高最常見的來源，是圖片沒有尺寸、廣告和 iframe 未預留高度、Web Font 替換、lazy load 區塊插入內容，以及第三方腳本改變既有版面。

元素	常見症狀	修正方向
圖片	首圖或商品圖載入後把文字推下去	設定 width、height 或 aspect-ratio
廣告版位	廣告回填後內容突然下移	預留容器高度與 fallback 狀態
iframe / embed	YouTube、地圖、表單載入後撐開區塊	使用比例容器固定視覺空間
Web Font	文字字重、寬度替換後換行	preload 重點字體，調整 font-display 與 fallback
第三方腳本	推薦、聊天、彈窗插入在內容上方	限制插入位置，避免推擠主要內容

圖片沒有 width / height 或 aspect-ratio

瀏覽器在圖片尚未下載前，如果不知道圖片比例，就無法先保留空間。等圖片載入後，下面的文字、卡片或按鈕被推開，CLS 分數就會上升。

廣告、iframe、YouTube embed 沒有預留空間

廣告與嵌入內容的高度常常不是第一時間可知。站長常犯的錯，是等廣告載入成功才讓容器出現。比較穩的做法，是一開始就保留合理高度，沒有廣告時也維持可接受的空白或替代內容。

Web Font 載入造成字體替換位移

中文字體尤其容易讓行高、字寬或換行位置變動。若 fallback 字體與正式字體差異太大，使用者會看到文字重新排版，導致標題、段落與按鈕位置變動。

lazy load、推薦區塊、彈窗、第三方腳本插入內容

lazy load 本身沒有問題，問題在於載入後才增加高度。推薦文章、會員提示、優惠條、Cookie 提示、聊天外掛，如果插在既有內容上方，都可能製造 CLS。

SPA / 前端框架 hydration 後元件高度改變

React、Vue、Nuxt、Next.js 這類網站常見問題，是伺服器輸出的初始 HTML 高度與 client-side hydration 後的元件高度不同。表面上頁面很快出現，實際上元件接管後又重排一次。

CLS 修正流程：從 PageSpeed 找問題到確認修復成功

有效的 CLS 修正流程是先用 PageSpeed Insights 看 field data 與 lab data，再用 Lighthouse 和 Chrome DevTools 找到位移元素，最後回到 Search Console 觀察 URL 群組是否改善。

Step 1：先看 PageSpeed 的實際使用者資料與實驗室資料

先把同一個 URL 放進 PageSpeed Insights。上方若有真實使用者體驗資料，代表可看 field data；下方 Lighthouse 診斷則用來找當次測試的問題。不要只看總分，CLS 的來源通常藏在診斷項目與截圖時間軸裡。

Step 2：用 Lighthouse 找出造成位移的元素

Lighthouse 會列出避免大型版面位移的相關提示。看到可疑元素後，記下 CSS selector、DOM 位置與發生時間。我的經驗是，CLS 高的頁面常常不是整頁都有問題，而是共用模板裡一個首圖、廣告或嵌入區塊反覆出錯。

Step 3：用 Chrome DevTools Performance 檢查 layout shift

在 Chrome DevTools 開啟 Performance，錄製重新整理流程，觀察 timeline 裡的 Layout Shift。點擊事件後可查看受影響元素，搭配畫面截圖能判斷是哪個區塊把內容推開。工程師應該在這一步確認真兇，不要憑感覺改 CSS。

Step 4：分手機版與桌機版處理

手機版和桌機版的版面斷點不同，廣告尺寸、圖片比例、選單高度也不同。Search Console 與 PageSpeed 都要分裝置看，尤其台灣多數內容站與電商流量以手機為主，行動版應先修。

Step 5：修完後用同一組 URL 與裝置條件重測

修完後用同一個 URL、同一種裝置條件重測，才知道變化是否來自你的修改。PageSpeed lab data 可立即看趨勢，Search Console 則需要等待真實使用者資料累積。

CLS 修正方法與程式碼範例

CLS 修正的核心做法，是在圖片、廣告、iframe、字體與動態內容載入前先保留穩定空間，避免元素出現後才把既有內容推開。

圖片 CLS 修正：設定 width、height 與 aspect-ratio

圖片造成 CLS，通常是瀏覽器不知道比例。先補 width 與 height，或用 CSS aspect-ratio 讓容器保留空間，再用 PageSpeed 與 DevTools 確認圖片載入前後下方內容沒有移動。

HTML 圖片範例

錯誤寫法的問題，是圖片沒有尺寸，瀏覽器只能等圖片回來後才知道高度。

<!-- 錯誤：沒有寬高，容易造成圖片載入後推擠內容 -->
<img src="/assets/product-cover.jpg" alt="網站範例">
<!— 修正：提供原始比例，瀏覽器可先保留空間 —>
<img
src=“/assets/product-cover.jpg”
alt=“網站範例”
width=“1200”
height=“675”
loading=“lazy”>

CSS aspect-ratio 範例

當圖片由 CMS 或 API 動態輸出時，可用外層容器控制比例。這段是在修「圖片資料晚到，但版面先穩住」的問題。

.media-frame {
  width: 100%;
  aspect-ratio: 16 / 9;
  overflow: hidden;
  background: #f2f4f7;
}
.media-frame > img {
width: 100%;
height: 100%;
object-fit: cover;
display: block;
}

廣告版位修正：預留固定容器，不要載入後才撐開

廣告造成的位移常發生在文章上方、段落中間與側邊欄。修法不是硬塞空白，而是依照實際廣告尺寸保留最小高度，並處理沒有廣告回填時的狀態。

廣告 placeholder 範例

這段是在修「AdSense 或廣告腳本載入後才把文章往下推」的問題。容器先存在，廣告晚到也不會改變下方內容位置。

.ad-slot {
  min-height: 280px;
  width: 100%;
  display: grid;
  place-items: center;
  background: #f6f7f9;
}
@media (min-width: 768px) {
.ad-slot {
min-height: 250px;
}
}

iframe / YouTube embed 修正：用比例容器保留高度

YouTube、Google Maps、表單與第三方 embed 常在 JS 載入後才決定高度。用比例容器先保留空間，可避免嵌入內容把段落或 CTA 往下推。

responsive wrapper 範例

這段是在修「iframe 還沒完成載入前，高度為 0 或不穩定」的問題。

.embed-wrapper {
  position: relative;
  width: 100%;
  aspect-ratio: 16 / 9;
  background: #eef1f5;
}
.embed-wrapper iframe {
position: absolute;
inset: 0;
width: 100%;
height: 100%;
border: 0;
}

Web Font 修正：preload、font-display 與 fallback 字體

Web Font 造成 CLS，常見原因是正式字體載入後替換 fallback，導致行高、字寬與換行改變。重點字體可 preload，但不要把所有字重都 preload，否則 LCP 可能被拖慢。

字體載入範例

這段是在修「字體晚到造成文字重排」的問題。只 preload 首屏真正需要的字體，並搭配 font-display 控制替換行為。

<link
  rel="preload"
  href="/fonts/site-regular.woff2"
  as="font"
  type="font/woff2"
  crossorigin>
@font-face {
font-family: “SiteFont”;
src: url(“/fonts/site-regular.woff2”) format(“woff2”);
font-display: swap;
}
body {
font-family: “SiteFont”, system-ui, -apple-system, BlinkMacSystemFont, “Noto Sans TC”, sans-serif;
}

避免在既有內容上方插入新元素

優惠條、APP 下載提示、會員登入提示、Cookie 訊息若一定要出現，應避免插在主內容上方並推擠頁面。比較好的做法是使用已預留的固定區域，或讓它覆蓋在不干擾閱讀與點擊的位置。

不同網站的 CLS 常見問題與修正重點

不同網站的 CLS 來源不同：WordPress 常見於外掛與字體，電商常見於商品圖與促銷條，內容站常見於首圖、目錄、廣告與嵌入內容。

網站類型	常見位移來源	優先修正重點
WordPress	外掛、lazy load、廣告、Web Font	先檢查主題模板與外掛輸出位置
電商網站	商品圖、價格、規格、推薦商品	先修商品頁模板與結帳前流程
內容站	首圖、目錄、段落廣告、YouTube embed	先修文章模板與內文廣告版位
廣告收益站	AdSense、聯播廣告、動態需求	先建立穩定廣告容器與 fallback
SPA / 前端框架	hydration、client-side 元件、資料晚載入	先對齊 SSR 與 hydration 後高度

WordPress：外掛、lazy load、廣告與字體最常出問題

WordPress 站長應先看主題是否替圖片輸出 width 與 height，再檢查 lazy load、目錄外掛、廣告外掛、Cookie 外掛是否插在內容上方。不要一開始就換主機，CLS 多半是版面保留空間問題。

電商網站：商品圖、價格區塊、推薦商品、促銷條

商品頁要特別檢查主圖比例、縮圖列、價格載入、規格選項與推薦商品。若促銷條在頁面載入後才出現，會把整個商品資訊區往下推，影響加入購物車。

內容站：首圖、目錄、廣告、嵌入內容

文章頁常見問題是首圖沒有尺寸、目錄延後插入、段落廣告回填、YouTube 或社群貼文 embed 高度不穩。內容站的修正價值高，因為文章模板一修，很多 URL 會一起受益。

廣告收益站：廣告版位與動態需求要先預留空間

廣告收益站不能只追填充率，也要管理版面穩定。若不同廣告尺寸會進同一個版位，容器高度要以實際常見尺寸規劃，不要每次競價完成後才改變高度。

SPA / 前端框架網站：hydration 與 client-side 元件高度

前端框架網站要檢查 skeleton、資料載入前高度、hydration 後 DOM 差異。若 SSR 先輸出一種卡片高度，client-side 又改成另一種高度，使用者會看到明顯跳動。

為什麼 CLS 修完了，Search Console 還沒變好？

Search Console 的 Core Web Vitals 報告來自真實使用者資料與網址群組，更新不會像 PageSpeed lab data 一樣立即反映；修完後仍需等待資料累積。

PageSpeed 實驗室分數可立即重測，GSC 需要真實使用者資料累積

PageSpeed 的 Lighthouse 結果可立刻重跑，適合看修改是否有效。Search Console 看的是 field data，會等真實 Chrome 使用者資料累積後才更新。剛修完隔天還是紅色，不代表修正失敗。

GSC 顯示的是網址群組，不一定是單一頁面的即時結果

Core Web Vitals 報告常以相似 URL 群組呈現，例如同一種文章模板或商品模板。你修了其中一頁，群組內其他頁若仍有相同問題，報告可能不會馬上轉好。實務上要修模板，而不是只修單一 URL。

行動版與電腦版要分開看

GSC 會分行動版與電腦版報告。手機版不良、桌機版良好很常見，原因可能是手機廣告尺寸、選單高度、圖片比例或網路條件不同。驗收時要分開看，不要用桌機結果安慰自己。

什麼時候該按「驗證修正」？

當 PageSpeed lab data 已改善，DevTools 也確認主要 layout shift 消失，且共用模板已部署到受影響 URL 群組，再按 Search Console 的驗證修正。太早按只會讓驗證流程卡在同樣問題上。

修正 CLS 時常見錯誤：不要為了穩定版面犧牲 LCP / INP

CLS 修正不能只追求畫面不動；若用過大固定高度、過度 preload 或大量 JavaScript 補救，可能讓 LCP 變慢、INP 變差。

不要把所有圖片硬套固定高度

固定高度會讓不同比例圖片被裁切或拉伸，也可能在 RWD 斷點出現新的位移。圖片應保留正確比例，搭配 object-fit 與合理容器，而不是所有圖都套同一個高度。

不要用過大的 min-height 亂撐版面

min-height 可以保留空間，但太大會讓首屏內容被推到下方，反而傷害 LCP 與閱讀效率。我的判斷是：min-height 應根據實際版位尺寸設定，不該拿來掩蓋未知內容高度。

不要過度 preload，反而拖慢主要內容

preload 適合關鍵首屏資源，例如主要字體或首圖。若把所有字體、輪播圖、第三方資源都 preload，瀏覽器下載優先順序會被打亂，LCP 可能變差。

不要把所有問題都交給 JavaScript 延後處理

用 JS 延後載入可以減少初始干擾，但若延後後才插入內容，一樣會產生 CLS。版面穩定應優先靠 HTML 與 CSS 保留空間，再讓 JS 填入內容。

CLS、LCP、INP 要一起看，不要只追單一分數

2026 年看 Core Web Vitals，CLS、LCP、INP 要一起判斷。穩定版面、快速呈現主要內容、互動反應順暢，三者缺一個都會讓使用者感覺網站卡或不可靠。

CLS 修正優先順序：先改哪裡最有效？

CLS 修正應先處理共用模板、行動版、有流量或有轉換價值的 URL 群組，再處理單篇頁面的個別細節。

先修共用模板，再修單篇頁面

文章模板、商品模板、分類頁模板、首頁區塊若有 CLS，影響範圍最大。先修模板，可以一次改善大量 URL，也比較符合 Search Console URL 群組的判讀方式。

先修行動版，再看桌機版

若資源有限，先處理行動版。台灣多數網站的自然搜尋與社群流量都高度依賴手機，且手機螢幕較窄，同樣的位移更容易被使用者感受到。

先修有流量、有轉換、有 GSC 警示的 URL 群組

優先順序可以用三個條件排：Search Console 已警示、Google Analytics 或其他分析工具顯示有流量、頁面有詢問、購買、註冊或導流價值。沒有流量的低價值頁面，不該搶走主要修正資源。

先修可重複套用的版位：首圖、廣告、字體、嵌入內容

首圖、廣告、字體、iframe、推薦區塊最值得先查，因為它們常出現在多種頁面。陳建宏在 makewebsites 的網站建置與 SEO 實務觀察是，真正有效的 CLS 修正通常不是改一頁，而是把會重複出現的位移來源一次收斂。

不建議延伸的內容範圍

CLS 修正頁應聚焦在 Cumulative Layout Shift 的診斷、修正與驗證；同縮寫但無關 Core Web Vitals 的主題不應混入正文。

不解釋 Windows `.cls` 指令

Windows 的 cls 是清除命令提示字元畫面的指令，與網頁版面位移沒有關係。若讀者要修 Core Web Vitals，看到這類結果可以直接跳過。

不解釋 .NET CLS compliant

.NET 的 CLS compliant 屬於程式語言與跨語言相容性規範，不會影響 PageSpeed Insights、Lighthouse 或 Search Console 的 Cumulative Layout Shift 分數。

不討論 CLS 股票代號或法律案例

股票、法律案例、法規文件修正都只是搜尋字面重疊，不能解決圖片、廣告、iframe、Web Font 或第三方腳本造成的 layout shift。

不把本文寫成完整網站速度優化總論

網站速度還包含主機、快取、圖片壓縮、JavaScript、CSS、LCP、INP 等議題。CLS 修正的主軸是版面穩定；若要看完整脈絡，可延伸閱讀 Core Web Vitals，電商頁也可搭配 電商網站架設指南、電商轉換設計 與 CTA 按鈕設計 一起檢查。

CLS 修正是什麼意思？

CLS 修正是指降低 Cumulative Layout Shift，也就是修正網頁載入或互動時的非預期版面位移。常見做法包含替圖片設定尺寸、替廣告和 iframe 預留空間、調整 Web Font 載入方式，以及避免第三方腳本把內容往下推。

CLS 分數多少才算好？

CLS 小於等於 0.1 通常算良好；大於 0.1 到 0.25 需要改善；大於 0.25 屬於不良。實務判斷時要分行動版與電腦版，也要區分 PageSpeed 的 lab data 和 Search Console 的 field data。

CLS 太高一定會影響 SEO 排名嗎？

不一定。CLS 是頁面體驗訊號之一，不是唯一排名因素。內容品質、搜尋意圖、網站權威、內部連結仍然重要。不過 CLS 太高會影響使用者體驗，熱門頁與商業頁仍應優先修正。

PageSpeed 顯示 CLS 不良，第一步該查什麼？

先看 PageSpeed Insights 是否有真實使用者資料，再看 Lighthouse 診斷中的 layout shift 提示。接著用 Chrome DevTools Performance 錄製頁面載入，找出實際位移的元素，通常會落在圖片、廣告、iframe、字體或動態插入內容。

圖片沒有設定寬高真的會造成 CLS 嗎？

會。圖片沒有 width、height 或 aspect-ratio 時，瀏覽器在圖片下載前無法預留正確高度。等圖片載入後，下方文字、卡片或按鈕被推開，就會形成累積版面位移。

AdSense 或廣告版位造成 CLS 要怎麼修？

先替廣告版位設定穩定容器，例如 min-height 或固定比例區塊，讓廣告尚未回填時也保留空間。不要等廣告載入成功才插入容器，也要處理沒有廣告時的 fallback 狀態。

Web Font 會讓版面跳動嗎？

會。正式字體載入後若字寬、字重或行高和 fallback 字體差很多，文字可能重新換行，造成標題、段落與按鈕位置改變。可用 font-display、合適 fallback 字體與必要的 preload 降低位移。

為什麼 CLS 修完後 Search Console 還是顯示不良？

Search Console 的 Core Web Vitals 報告依賴真實使用者資料與 URL 群組，不是即時測試工具。PageSpeed lab data 可能已改善，但 GSC 需要等待 field data 累積，也可能因為同群組其他頁仍有問題而維持不良狀態。

手機版 CLS 和桌機版 CLS 可以分開處理嗎？

可以，也應該分開看。手機版與桌機版的版面、廣告尺寸、圖片比例、選單高度不同，CLS 來源也可能不同。若資源有限，通常先修行動版，再檢查桌機版。

WordPress 網站最常見的 CLS 問題是什麼？

WordPress 最常見的 CLS 問題是圖片未輸出尺寸、lazy load 外掛處理不當、目錄或廣告外掛插入內容、Web Font 替換，以及 Cookie 或彈窗外掛推擠主內容。先檢查主題模板和外掛輸出位置，比盲目換主機有效。

CLS 修正是指 Core Web Vitals，還是 .NET CLS compliant？

在 SEO 與網站效能語境中，CLS 修正指的是 Core Web Vitals 的 Cumulative Layout Shift。.NET CLS compliant 是另一個技術縮寫，屬於程式語言相容性規範，和網頁版面位移分數無關。

為什麼搜尋 CLS 修正會出現法律、股票或 Microsoft 文件？

因為 CLS 是多義縮寫，搜尋結果會混入 Clear Screen、.NET Common Language Specification、股票代號或法律文件。要找 Core Web Vitals 的 CLS 修正，應優先判斷頁面是否提到 Cumulative Layout Shift、PageSpeed Insights、Lighthouse、Search Console 或 layout shift。