一个可感知的工程问题
打开一个包含上千个商品卡片的电商列表页，首屏往往要等待数秒才能稳定。即使只展示视口内的二三十个商品，浏览器仍然要为整个文档执行布局和绘制：每个卡片的尺寸、位置、背景、图片占位都要参与计算。滚动时，主线程被大量离屏元素的样式计算和布局占据，帧率下降，滚动出现卡顿。
常见的优化思路是虚拟滚动：只渲染视口附近的条目，用 JavaScript 维护可视窗口，动态增删 DOM。虚拟滚动确实有效，但它要求列表项高度固定、结构统一，并且要处理滚动条占位、焦点管理、键盘导航等一系列边界问题。实现复杂度高，稍有不慎就会破坏滚动位置或可访问性。
CSS 的 content-visibility 提供了一条不同的路径：不改变 DOM 结构，而是让浏览器自己判断哪些元素离屏，跳过它们的渲染工作。它不需要 JavaScript 参与，也不需要固定高度。本文以长商品列表为贯穿场景，说明它的工作机制、与 contain 的关系、失效条件以及工程上的取舍。
content-visibility 是什么：让浏览器跳过离屏内容的渲染
content-visibility 是 CSS Containment Module Level 2 定义的属性，它允许用户代理在元素不需要时跳过其内容的渲染，包括布局和绘制。MDN 的描述是：它控制元素是否渲染其内容，并强制一组强包含，使用户代理可以省略大量布局和渲染工作，直到需要时才执行。
属性有三个关键字值：
visible：默认值，没有任何效果，元素正常渲染。hidden：元素跳过其内容，效果类似于display: none，但元素本身的盒模型（尺寸、背景等）仍然保留。auto：元素开启布局包含、样式包含和绘制包含；如果元素与用户无关（不在视口内），则跳过其内容。与hidden不同，auto跳过的内容仍然对查找、Tab 导航、选择等用户代理功能可用。
在长商品列表中，给每个商品卡片设置 content-visibility: auto，浏览器会在初始渲染时只处理视口附近的卡片，离屏卡片的内容被跳过，从而大幅减少首次布局和绘制的工作量。滚动时，新进入视口的卡片才被渲染，离开视口的卡片再次被跳过。
核心机制：包含与交集观察
content-visibility: auto 的渲染跳过依赖两个机制：CSS 包含（containment）和交集观察（intersection observation）。
CSS 包含是一种声明元素子树独立于页面其余部分的机制。content-visibility: auto 会强制开启三种包含：
- 布局包含（layout containment）：元素内部的布局不会影响外部，外部变化也不会触发内部重新布局。浏览器可以独立处理该元素的布局，无需向上传播尺寸变化。
- 样式包含（style containment）：元素内部的样式计数（如计数器）不会泄漏到外部，外部样式也不会影响内部计数。
- 绘制包含（paint containment）：元素的内容被裁剪到其边界内，不会绘制到边界之外。这允许浏览器在元素离屏时直接跳过绘制。
交集观察是浏览器内部使用的机制，类似于 IntersectionObserver，但由渲染引擎直接驱动。浏览器会监测元素与视口的交叉状态：当元素完全或部分进入视口时，它被视为“相关”，需要渲染；当元素完全离开视口时，它被视为不相关，可以跳过。
这两个机制共同作用：包含保证了跳过渲染不会破坏页面其他部分，交集观察则决定了何时跳过、何时恢复。
与 contain 的区别：为什么 contain 不够
contain 属性是 content-visibility 的基础，但它本身不会跳过渲染。contain: layout paint 只是告诉浏览器该元素的子树是独立的，浏览器可以利用这一点做优化，但元素仍然会被布局和绘制。
content-visibility: auto 在 contain 的基础上增加了“跳过”行为：当元素离屏时，浏览器不仅认为它独立，还直接不执行它的布局和绘制。这是质的区别。
用一个对比表格说明：
| 特性 | contain: layout paint | content-visibility: auto |
|---|---|---|
| 布局包含 | 是 | 是 |
| 绘制包含 | 是 | 是 |
| 样式包含 | 否（需单独指定） | 是 |
| 离屏时跳过布局 | 否 | 是 |
| 离屏时跳过绘制 | 否 | 是 |
| 内容对查找/焦点可用 | 是 | 是 |
需要配合 contain-intrinsic-size | 否 | 建议 |
| 典型用途 | 隔离组件，防止布局抖动 | 长列表、长文档的渲染优化 |
contain 的价值在于防止一个组件的内部变化影响外部，例如一个频繁更新的图表组件，用 contain: layout 可以避免其尺寸变化导致整个页面重排。但 contain 不会减少初始渲染的总工作量，因为它仍然会渲染所有内容。
content-visibility: auto 则直接砍掉了离屏内容的渲染，因此优化效果更显著。但它也带来了新的问题，比如滚动条抖动，需要额外处理。
长商品列表的完整生命周期
以一个包含 1000 个商品卡片的列表为例，每个卡片包含图片、标题、价格和评分。页面加载时，浏览器执行以下步骤：
- 解析 HTML 构建 DOM：所有 1000 个卡片节点都存在于 DOM 中，不受
content-visibility影响。 - 计算样式：浏览器为每个元素计算最终样式。
content-visibility: auto本身不影响样式计算，但包含机制可能让某些样式计算被延迟。实际上，样式计算仍然会执行，但布局和绘制被跳过。 - 布局：浏览器为每个元素计算几何位置。对于设置了
content-visibility: auto且离屏的元素，布局被跳过。但为了维持滚动条高度，浏览器需要知道这些元素的大小，这由contain-intrinsic-size提供。 - 绘制：离屏元素不绘制，节省了大量绘制时间。
- 合成：只有视口内的元素被合成到屏幕上。
滚动时，浏览器通过交集观察监测每个卡片与视口的关系。当卡片进入视口，浏览器开始执行它的布局和绘制；当卡片离开视口，浏览器停止维护它的渲染状态。这个过程是动态的，但用户感知到的滚动条高度可能因为 contain-intrinsic-size 的设置而保持稳定。
下面的流程图展示了这一生命周期：
flowchart TD
A[页面加载] --> B[解析 HTML 构建 DOM]
B --> C[计算样式]
C --> D{元素是否在视口内?}
D -- 是 --> E[执行布局]
D -- 否 --> F[跳过布局]
E --> G[执行绘制]
F --> H[跳过绘制]
G --> I[合成显示]
H --> I
I --> J[用户滚动]
J --> K{元素进入视口?}
K -- 是 --> L[恢复布局和绘制]
K -- 否 --> M[继续跳过]
L --> I
M --> J
关键转折点在于交集观察：元素进入视口时，浏览器需要恢复渲染，这会产生一次布局和绘制的工作量。如果元素高度未知，恢复时会导致滚动条跳动。contain-intrinsic-size 的作用就是为离屏元素提供一个占位高度，让滚动条保持稳定。
工程实现：contain-intrinsic-size 与滚动条稳定性
contain-intrinsic-size 是 content-visibility 的配套属性，它指定元素在未被渲染时的自然大小。MDN 和规范都建议在设置 content-visibility: auto 时使用它。
在商品列表中，每个卡片的高度通常是固定的，比如 320px。可以这样设置：
.product-card {
content-visibility: auto;
contain-intrinsic-size: 320px;
}这样，即使卡片离屏未渲染，浏览器也认为它占据 320px 的高度，滚动条的总高度与实际内容一致，不会出现抖动。
如果列表项高度不固定，可以提供一个估计值，但这样滚动条可能不完全准确。另一种做法是使用 contain-intrinsic-size: auto 320px，它表示元素在渲染时使用实际大小，未渲染时使用 320px。但 auto 关键字需要浏览器支持，且实际行为可能因渲染状态而异。
工程上，contain-intrinsic-size 是必须的，否则滚动条会像虚拟列表一样抖动。ChokCoco 的实践文章指出，不设置该属性时，视口外的元素高度为 0，滚动条高度比实际内容短，滚动过程中随着元素进入视口，高度逐渐恢复，导致滚动条跳动。
设置 contain-intrinsic-size 后，滚动条保持稳定，用户体验接近原生列表。但要注意，如果元素实际高度与占位高度差异较大，滚动条仍会有轻微跳动。因此，尽量使用准确的高度值。
失效条件：查找文本、焦点和网络请求
content-visibility: auto 的一个关键特性是，跳过的内容仍然对用户代理功能可用。这意味着：
- 查找文本：浏览器全局查找（Ctrl+F）可以找到离屏元素中的文本。因为 DOM 仍然存在，查找功能不受影响。ChokCoco 的实验验证了这一点。
- Tab 导航：离屏元素仍然可以接收焦点，键盘用户可以通过 Tab 键导航到这些元素。浏览器会滚动到相应位置并渲染它。
- 选择：用户可以通过鼠标选择离屏文本（例如按住鼠标拖动），尽管这在实际操作中不太常见。
这些功能之所以可用，是因为 content-visibility: auto 只是跳过了渲染，并没有从 DOM 中移除内容。这与 display: none 或 hidden 不同，后者会使内容对查找和焦点不可用。
但这也意味着，content-visibility: auto 不能替代懒加载。ChokCoco 的实验表明，即使元素离屏未渲染，其中的图片资源仍然会在页面初始化时被加载。这是因为资源加载发生在 DOM 解析阶段，与渲染无关。因此，如果列表中有大量图片，仍然需要配合懒加载（如 loading="lazy"）来减少网络请求。
另一个失效条件是：如果元素的内容会影响页面其他部分的布局，例如元素内部的尺寸变化会传播到外部，那么包含机制可能无法生效，浏览器会回退到完整渲染。但 content-visibility: auto 强制开启布局包含，通常可以避免这种情况。
可访问性影响与渐进增强
content-visibility: auto 对可访问性的影响是积极的：离屏内容仍然对屏幕阅读器可用，因为 DOM 和可访问性树仍然存在。MDN 指出，auto 跳过的内容仍然在文档对象模型和可访问性树中。
然而，content-visibility: hidden 则不同，它会使内容对辅助技术不可用，类似于 display: none。因此，如果只是希望隐藏内容但保留可访问性，应该使用 auto 而不是 hidden。
在实际项目中，content-visibility: auto 属于渐进增强特性。浏览器不支持时，元素正常渲染，没有任何副作用。支持时，性能得到优化。因此，可以放心使用，无需担心兼容性问题。
但要注意，content-visibility: auto 可能会影响滚动行为。例如，当用户使用键盘 Tab 导航到离屏元素时，浏览器需要滚动到该元素并渲染它，这可能导致滚动位置跳变。不过，现代浏览器通常会处理这种情况，确保焦点元素可见。
与其他方案的比较与适用边界
content-visibility: auto 与虚拟滚动、懒加载是三种不同的优化手段，各有适用场景。
| 方案 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
content-visibility: auto | 浏览器跳过离屏渲染 | 无需 JS、DOM 完整、可访问性好 | 滚动条需 contain-intrinsic-size、不能减少资源加载 | 长列表、长文档，内容静态或高度已知 |
| 虚拟滚动 | 只渲染视口附近的 DOM | 内存占用低、滚动性能好 | 实现复杂、需固定高度、可访问性差 | 超长列表（万级）、聊天记录 |
| 懒加载 | 延迟加载资源 | 减少网络请求 | 需要 JS、可能影响布局 | 图片、iframe、视频 |
content-visibility: auto 的优势在于实现简单，只需一行 CSS，且不破坏 DOM 完整性，对 SEO 和可访问性友好。但它不能减少网络请求，如果列表项包含大量图片，仍需配合懒加载。
在长商品列表中，如果商品卡片高度固定，且图片使用 loading="lazy"，那么 content-visibility: auto 可以显著提升滚动性能，同时保持滚动条稳定。如果列表项高度不固定，或者需要频繁动态插入删除，虚拟滚动可能更合适。
可观测信号与诊断
要验证 content-visibility: auto 是否生效，可以观察以下信号：
- 首次渲染时间：使用 Performance 面板记录 DOMContentLoaded 和首次绘制时间，对比添加前后的差异。ChokCoco 的实验中，渲染时间从 2900ms 降到 61ms，但这是特定页面的数据，不同场景差异很大。
- 滚动帧率：在滚动过程中录制帧，查看是否有长任务或掉帧。
content-visibility应该减少滚动时的布局和绘制时间。 - 滚动条抖动：如果滚动条在滚动时跳动，说明
contain-intrinsic-size未设置或不准确。 contentvisibilityautostatechange事件：该事件在元素开始或停止跳过渲染时触发，可以用于调试或动态调整（如暂停 canvas 绘制）。
如果性能没有改善，可能的原因包括：
- 元素没有真正离屏（例如视口很大，所有元素都在视口内）。
- 元素高度未设置
contain-intrinsic-size，导致浏览器无法正确跳过布局。 - 元素内部有影响外部的样式（如
position: fixed子元素），导致包含失效。 - 浏览器不支持该属性（需要检查兼容性）。
结论与使用建议
content-visibility: auto 是 CSS 原生提供的渲染优化手段，它通过包含和交集观察跳过离屏元素的布局与绘制，从而降低长列表的初始渲染和滚动成本。与虚拟滚动相比，它实现简单、不破坏 DOM 完整性，对可访问性友好；但它不能减少资源加载，需要配合懒加载使用。
在实际项目中，建议在长列表、长文档等场景中启用它，并始终设置 contain-intrinsic-size 以避免滚动条抖动。同时，应通过性能面板验证优化效果，并关注 contentvisibilityautostatechange 事件以处理动态内容。
content-visibility 不是万能的，它无法替代懒加载，也不适用于所有动态场景。但在合适的场景下，它可以用最少的代码获得显著的性能提升，是前端性能优化工具箱中值得掌握的一项。