content-visibility 的 7 倍渲染提升是真的，但没有 contain-intrinsic-size 就是在制造

content-visibility: auto 是 2026 年 CSS 性能优化里最常被推荐的一个属性，Chrome 官方文档报告它在长页面上可以带来最高 7 倍的渲染提升。它的原理很直接：当元素在屏幕外时，浏览器跳过它的布局、绘制和样式计算，只在实际接近视口时才渲染——这是 CSS 层面的虚拟化，不需要 JavaScript。

但这个属性的使用有两个硬性条件，忽略任何一个都会让收益变成 bug。

第一个条件是必须配 contain-intrinsic-size。当浏览器跳过渲染时，它不知道元素的高度；如果没有任何尺寸提示，滚动条会在元素进入视口、实际渲染发生时跳动。contain-intrinsic-size 给浏览器一个估计高度，auto 关键字让浏览器在首次渲染后记住实际尺寸。一个正确的写法是 content-visibility: auto; contain-intrinsic-size: auto 500px;，一个错误的写法是只写 content-visibility: auto 而不给尺寸。

第二个条件是绝不能用在首屏内容上。浏览器会延迟渲染 content-visibility: auto 的元素，如果 hero 区域、主标题、首屏第一张卡片加了这个属性，LCP 会被直接推迟。这不是一个“可能变慢”的风险，是一个确定的性能倒退。它也不应该用在很小的元素上，因为每个元素的 containment 跟踪开销会超过渲染节省，应该用在 section 级容器上，而不是每个子项上。

一个实际的生产案例给出了前后对比：一个页面上方有一个重型交互组件，下方有多个内容区块。不用 containment 时，LCP 约 2.8 秒，滚动过程中出现布局偏移；对下方区块使用 content-visibility: auto 加 contain-intrinsic-size 之后，LCP 降到约 1.7 秒，滚动过程中布局稳定。另一个来自聊天消息列表的案例展示了容易被忽略的副作用：content-visibility 隐含了 paint containment，会裁剪掉行盒子之外绘制的内容——包括悬挂在气泡下方的悬停时间戳。如果组件的设计依赖“子元素可以溢出父元素”，content-visibility 会把这些溢出裁掉。

contain 属性是 content-visibility 的手动、细粒度版本。contain: layout 把内部布局和外部隔离，浮动和布局变化不会影响外部；contain: paint 建立绘制边界，溢出内容被裁剪；contain: size 让元素尺寸不依赖子元素，必须显式设置尺寸；contain: style 限制计数器和引用的作用域；contain: strict 是四者的组合。选择哪一个取决于你要隔离什么：如果只是想让内部布局变化不触发外部重排，contain: layout 就够；如果需要绘制裁剪，加 paint；只有在明确知道尺寸时才用 size。

一个务实的落地顺序是：先用 Chrome DevTools 的 Performance 面板或 Lighthouse 确认渲染确实是瓶颈，而不是脚本或网络；再对首屏之外的 section 级容器应用 content-visibility: auto 并配对 contain-intrinsic-size；然后测量应用前后的 LCP、滚动布局偏移和实际渲染时间，如果没有可测量的差异就移除它。content-visibility 不是“加上就快”的属性，它是有明确适用条件和明确副作用的渲染优化，条件不满足时，7 倍提升不会出现，滚动条抖动会。