配了三年长列表，每次首屏都要等那些看不见的内容渲染完——今天 CSS 自己会跳过它们了

页面一打开，你看到的只有前两项，但浏览器已经把 50 项的布局和绘制全算完了——这种事在长列表页面每天都在发生。

这不是你的代码写得不好，是 CSS 一直缺一个能力：告诉浏览器「这些看不见的内容，现在先别管」。

content-visibility: auto 就是干这件事的。

它让浏览器跳过视口外元素的布局和绘制工作，只在元素接近视口时才真正渲染。对于内容密集型页面，这一个属性能把初始渲染时间砍到原来的十分之一。

Google 官方测试过含 27 万 DOM 节点的长文章文档：加了 content-visibility: auto 之后，布局耗时从 50 秒压缩到 400 毫秒。电商商品列表实测首屏渲染从 2.8 秒降到 1.2 秒，FCP 从 1.9 秒降到 0.8 秒。

基本用法很简单：

.card {
  content-visibility: auto;
  contain-intrinsic-size: auto 300px;
}

contain-intrinsic-size 是必须配的搭档。content-visibility: auto 让浏览器跳过渲染，但跳过的元素尺寸未知，滚动条就会乱跳——contain-intrinsic-size 给浏览器一个预估高度，浏览器用它来预留空间。auto 关键字的意思是：第一次用这个值，渲染完记住真实高度，下次复用。不需要精确，接近就行。

什么时候用：

• 电商商品列表 / 瀑布流
• 社交媒体信息流
• 文档目录 / 长文章多章节页面
• 管理后台大数据表格

什么时候不用：

• 首屏关键内容（视口内必须马上显示的，不适合加这个）
• 需要立即获取元素尺寸的场景（getBoundingClientRect 会拿到预估尺寸）
• 搜索必须立即找到所有文字（find-in-page 搜不到未渲染内容）

它和懒加载的区别要搞清楚。懒加载延迟的是「资源下载」，图片还是会被渲染；content-visibility: auto 延迟的是「渲染计算」，浏览器连绘制都不做。它们是互补的关系，不是替代关系。

浏览器支持方面，Chrome 85+、Firefox 125+、Safari 18+ 都支持，2025 年 9 月进 Baseline，渐进增强完全没问题。

这是目前 CSS 层面性价比最高的单项性能优化。没有 JS，没有依赖，一行属性，对内容密集型页面的加速效果往往超过你之前加的所有优化手段。下次写长列表之前，先把它加上。