content-visibility: auto对图片懒加载无效，因它仅跳过布局与绘制，不阻止图片请求发起；真正优化LCP需首屏图用loading="eager"+fetchpriority="high"+<link rel="preload">预加载。
移动端用 content-visibility 做图片延迟加载，本质是错的——它不控制图片加载，只跳过渲染。真要优化首屏 LCP，得把关键图“抢在解析早期就塞进网络栈”，而不是等它滚进来再画。
为什么content-visibility: auto对图片懒加载无效
浏览器遇到 content-visibility: auto 时，只会跳过 layout + paint，但 <img> 的 fetch 请求照常发起（除非加了 loading="lazy"）。也就是说：图片照样下载，只是 DOM 节点暂时不排版、不绘制——这和“延迟加载”完全不是一回事。
- 你看到的“图片没出现”，其实是渲染被跳过，不是还没下载
- Network 面板里能看到请求早已发出，甚至可能比首屏其他资源还早
- 如果图片在 DOM 中靠后，又没配
fetchpriority，它在网络队列里反而会被普通脚本、CSS 挤到后面
content-visibility 真正该用在哪类图片容器上
只适用于「离屏、高度固定、不参与首屏 LCP」的长列表图片区块，比如商品瀑布流中第 20 页之后的卡片、评论区折叠后的历史评论、Tab 切换后未激活的面板。
- 必须配合
contain-intrinsic-size，例如contain-intrinsic-size: 144px（单个卡片预估高度） - 父容器不能是
display: flex且未设align-items: flex-start，否则子项可能错位 - 若容器内有
position: fixed或transform元素，会强制触发重绘，抵消性能收益 - Firefox Android 和 iOS Safari ≤ 16.4 不支持，需用
@supports (content-visibility: auto)包裹降级样式
移动端图片延迟加载的正确组合拳
首屏图必须用 loading="eager" + fetchpriority="high" + <link rel="preload">；非首屏图才考虑懒加载逻辑，而 content-visibility 是给整个容器“减负”，不是替代懒加载。
立即学习“前端免费学习笔记（深入）”；
- 首屏
<img>去掉loading属性，或显式写loading="eager" - 在
<head>加预加载：<link rel="preload" as="image" href="hero.webp" fetchpriority="high">（注意as="image"缺一不可） - 非首屏图片用
loading="lazy"，但要确保 DOM 顺序合理——LCP 图片不能出现在它后面 - 想进一步压首屏时间？对长图容器用
content-visibility: auto，但前提是它不包含 LCP 元素，且已设好contain-intrinsic-size
最容易被忽略的一点：content-visibility 不解决网络请求时机问题，只解决渲染开销。如果你的 LCP 卡在图片下载慢，调这个属性毫无意义——得先看 Network 面板里那张图是不是被排到了队尾。
