動態內容 CLS：成因、診斷與修復實驗報告

開場：我的廣告載入時，頁面跳了 0.35

動態內容導致的 Cumulative Layout Shift (CLS) 是隱形殺手，常見於廣告、第三方 widget 和 SPA 路由。這篇文章記錄我將一個動態評論區的 CLS 從 0.35 壓到 0.02 的完整過程。當你的頁面因為 JavaScript 動態注入的元素而反覆跳動時，本文將提供具體的診斷方法與可執行的修復方案，而非僅討論靜態圖片的優化。這與我們之前討論的基礎 CLS 概念（CLS 意思）及圖片優化（CLS 圖片修復）一脈相承，是更深入的動態場景實驗。

指標	改動前	改動後
CLS 分數	0.35 (Poor)	0.02 (Good)
評估等級	不良	優良
觸發元素	.comment-section 容器高度突變	已預留穩定空間

實驗案例：一個 API 載入的評論區

讓我們從一個真實的場景開始。我有一個使用 React 建構的部落格文章頁，頁面底部有一個評論區，它透過 REST API 動態載入。在頁面初始渲染時，評論區是一個空的容器，高度為零。當 JavaScript 執行並取得 API 資料後，才會將評論內容填充進去，導致該容器高度突然擴張，將頁面上方所有內容（包括正文、側邊欄）向下推擠。

在改動前，使用 Lighthouse 測量這個頁面的 CLS 分數為 0.35，這在 Core Web Vitals 中被評為「不良（Poor）」。打開 Chrome DevTools 的 Performance 面板進行錄製，觸發評論區載入後，可以在 Experience 區塊看到一個紅色的、標記為「Layout Shift」的長條。點擊該事件，下方詳情會顯示觸發位移的具體 DOM 節點。根據我的實驗，這個節點是類別為 .comment-section 的 div，它的出現導致了佈局偏移。從時間軸上可以看到，這個 Shift 發生在頁面載入後約 1.2 秒，正好是評論資料 fetch 回來並渲染的時刻。

診斷實驗：如何用 Performance 面板抓到元兇

診斷動態 CLS 的關鍵在於定位「何時」以及「什麼元素」觸發了位移。我推薦的流程是：首先，打開 Chrome DevTools 切換到 Performance 面板。其次，點擊錄製按鈕，然後進行會觸發動態內容載入的操作（例如滾動頁面、點擊按鈕）。操作完成後停止錄製。第三，在錄製結果中，找到 Experience 行，點擊上面紅色的「Layout Shift」標記。此時，瀏覽器會在下方自動篩選出「Layout Shift」類別的事件。具體的面板操作與 UI 元素可參考 Chrome DevTools Performance 面板官方文檔。

在選中的 Layout Shift 事件詳情中，你會看到兩個關鍵資訊：Previous Layout Node 和 Current Layout Node。前者是位移發生前的 DOM 節點佈局狀態，後者是位移發生後的狀態。點擊它們旁邊的箭頭，可以直接在 Elements 面板中定位到對應的 DOM 節點。這就是抓到元兇的過程——你現在確切地知道，是哪個動態插入的容器（例如 .comment-section）在什麼時間點改變了其尺寸，從而導致了整個頁面的佈局重排。

可複製的修復代碼

找到問題後，修復的核心策略是「空間預留」。以下是兩套經過實驗驗證的代碼方案。方案一使用 CSS 的 aspect-ratio 屬性。這種方法適用於動態內容的高度與寬度有固定比例關係的場景。你可以為動態容器預設一個合理的寬高比，即使內容尚未載入，它也會佔據穩定的空間。關於 aspect-ratio 的更多用法與瀏覽器支援，請參閱 MDN Web Docs 關於 aspect-ratio 屬性的文檔。

/* 為動態評論區容器預留空間 */
.comment-section {
  /* 假設評論區內容通常呈現為 16:9 的視覺比例 */
  aspect-ratio: 16 / 9;
  /* 或者使用一個合理的最小高度，例如 300px */
  min-height: 300px;
  /* 確保內容載入後可以正確覆蓋預留空間 */
  overflow: hidden;
}

方案二使用 JavaScript 在內容實際渲染前動態計算並設定高度。這種方法適用於內容高度不可預測，但可以在載入前通過某種方式（例如 API 返回的 metadata 或歷史數據）預估的情況。在 React 中，你可以在 useEffect 中執行獲取資料和計算高度的邏輯，在資料返回後、DOM 更新前，先設定容器的 style.height。

// React 組件內的示例
useEffect(() => {
  async function loadComments() {
    // 1. 先取得資料，從中計算或獲取一個預估高度
    const res = await fetch('/api/comments');
    const data = await res.json();
    const estimatedHeight = calculateHeightFromData(data); // 假設你有一個計算函數

    // 2. 在實際渲染評論內容前，先設定容器高度
    const container = document.querySelector('.comment-section');
    if (container) {
      container.style.height = `${estimatedHeight}px`;
    }

    // 3. 然後才進行會改變佈局的狀態更新（如 setComments(data)）
    setComments(data);
  }
  loadComments();
}, []);

工具偏見：我的診斷工作流

在診斷動態 CLS 時，我優先使用 Performance 面板的 'Experience' 區塊，而非單純依賴 Lighthouse 的 CLS 分數。這是一個基於工具特性的選擇。Lighthouse 提供的是一個實驗室環境下的綜合性 CLS 分數，它是一個結論，告訴你「分數是多少」，但它無法告訴你「是哪個具體的腳本或哪個 DOM 節點在什麼時間點觸發了位移」。對於動態內容這種「間歇性」問題，我們需要的是過程分析。

Performance 面板則提供了時間軸上的「過程」視圖。它能精確地捕捉每一次 Layout Shift 事件，並直接關聯到觸發變化的 DOM 節點與執行中的 JavaScript 任務（在 Bottom-Up 面板可以看到）。這種「具體觸發點」的資訊對於修復至關重要。因此，Lighthouse 總分適合作為概覽和監控指標，但當你需要診斷並修復具體的動態 CLS 問題時，Performance 面板才是更強大的工具。兩者不是互斥，而是互補，在我的工作流中，它們扮演不同的角色。

平台差異提醒：Safari 與 React/Vue 的注意事項

在應用上述修復方案時，必須考慮平台與框架的差異。例如，在 Safari 的某些版本中，使用 CSS 屬性 contain: layout 可能不會像在 Chromium 瀏覽器中那樣觸發一個穩定的佈局邊界，這可能會影響一些進階優化技巧的效果。因此，在 Safari 上測試你的佈局穩定性至關重要。

對於使用 React 或 Vue 等現代前端框架的開發者，動態內容的載入通常與組件的狀態變更綁定。確保你對佈局產生影響的操作（如獲取資料後更新 DOM）發生在正確的生命週期之後。在 React 中，應在 useEffect 中處理；在 Vue 中，應在 mounted 或 onMounted 鉤子中處理。此外，React 18 引入的 startTransition API 可以用來將狀態更新標記為非緊急，這有助於瀏覽器更好地協調佈局更新，可能進一步減少意外的佈局位移。

改動後：CLS 0.35 → 0.02 的關鍵

總結這個實驗的核心優化：通過為動態載入的評論區容器使用 aspect-ratio 預留空間，我成功地將 CLS 從 0.35 降低到 0.02。這證明了動態內容 CLS 的核心策略是「空間預留」或確保「尺寸已知」。無論你採用 CSS 的 aspect-ratio、min-height，還是 JavaScript 的動態高度計算，其本質都是在內容實際渲染之前，為它佔據一個穩定的、預期的空間，從而避免後續的佈局跳動。記住，解決動態 CLS 問題的過程就是診斷觸發位移的元素，然後為它預留空間。