content-visibility: auto 怎麼用：加上 contain-intrinsic-size 避免版面跳動

為什麼要同時指定預估尺寸#

1
.feed-item {
2
  content-visibility: auto;
3
  contain-intrinsic-block-size: auto 28rem;
4
}

這裡使用 contain-intrinsic-block-size，在水平書寫模式下，block 軸對應高度：尚未正常渲染過的項目，以 28rem 作為略過內容時的預估尺寸；正常渲染後，後續略過內容時可以使用記住的尺寸。直排文字的 block 軸則對應水平尺寸，不能把屬性名稱直接當成 height。

contain-intrinsic-size: auto 28rem 是設定 width 與 height 的 shorthand，不能解釋成「只預留 28rem 高度」。如果卡片寬度應由父容器決定，而你只想估算 block 尺寸，使用上面的 longhand 更清楚。這項修正依 MDN shorthand 與 block-size 文件於 2026-10-04 查核。

不要照抄數字。先在目標 viewport 實測卡片高度，對高度差異大的項目採用較保守的預估，或改為讓圖片與文字區各自保留尺寸。若你的清單在 grid 或多欄 layout 中，固定預估尺寸也可能改變排版，必須逐一測試。

記住尺寸不代表內容改變後永遠準確#

記住的是先前正常渲染得到的尺寸。視窗變窄、字型載入或文字更新都可能改變所需高度，因此「捲出再捲回沒跳動」不足以代表預估一直正確。把首次載入與曾經看過的項目分開驗收：

1. 重新載入頁面，讓未曾顯示的卡片進入視窗，觀察後方項目與捲軸位置。
2. 捲過卡片後離開，再返回，確認 remembered size 沒有造成可見位移。
3. 卡片在畫面外時縮窄 viewport，再捲回；檢查換行後的高度與排列。
4. 用專案正常的資料更新方式修改畫面外文字，再返回確認，另外測試圖片與字型晚到。

不要為了取得每張畫面外卡片的「真實高度」，在捲動事件中遍歷所有子元素並同步讀取 layout。那會要求瀏覽器做原本想延後的工作。先以代表性的卡片估算；若產品必須精確掌握每列位置，應另外評估虛擬清單及其量測策略。

auto 和 hidden 的語意不同#

content-visibility: auto 在元素與使用者不相關時，可略過其內容渲染；該內容仍留在 DOM 與 accessibility tree，搜尋頁面文字、tab navigation 等 user-agent 功能仍可使用。

hidden 則不是 lazy rendering 的替代品。它讓內容跳過渲染，且不應被 user-agent 功能取得，效果更接近把內容從互動流程移除。不要用 hidden 來藏一個仍需要被鍵盤或搜尋找到的段落。

這裡略過的是渲染工作，不是 DOM 建立、網路下載或應用程式 JavaScript。它不能當成 lazy image、分頁 API 或事件清理的替代品。可存取性仍要檢查實際內容：例如子項目自己的 hidden 狀態，不應因為外層使用 auto 就免除螢幕閱讀器驗收。web.dev 的說明也提醒畫面外內容與 layout 讀取的界線。

先量測，再決定是否保留#

對一篇只有幾個區塊的頁面，加 containment 未必有實際收益，反而增加維護條件。先在 DevTools Performance 面板或實機上比較：初始 render、捲動時的 layout、以及 CLS。這和 Skeleton 預留資料載入空間的目標相近，但兩者解決的時間點不同；可參考 Skeleton 與 Shimmer 的版面穩定做法。

檢查時至少確認：

• 項目離開與回到視窗時，沒有可見跳動。
• Tab 鍵仍能到達原本可互動的內容。
• 搜尋頁面文字與錨點跳轉符合預期。
• 低階裝置與支援範圍外的瀏覽器仍有可接受的正常版面。

content-visibility: auto 適合當你已找到「大量畫面外、可獨立呈現內容」這個瓶頸後的局部優化；先保留尺寸，才能不把渲染成本轉成讀者看得見的版面跳動。

本文的 CSS 與驗收流程依文件整理，未執行跨瀏覽器排版測試，也沒有量測 CLS 或渲染時間；28rem 是示意預估值，不是本站效能改善數字。

參考資料：

MDN：content-visibility

MDN：contain-intrinsic-size

MDN：contain-intrinsic-block-size

web.dev：content-visibility