content-visibility: auto 对大图本身无效，因它仅跳过渲染不阻止请求，首屏图须用 loading="eager"+，非首屏图才可 lazy 加载并配合固定高度容器与 contain-intrinsic-size。
content-visibility: auto 对大图本身无效，真正起效的是组合策略：预加载 + 格式降级 + 懒加载时机控制 + 容器尺寸可预测性保障。
为什么直接给 <img> 加 content-visibility: auto 是错的
浏览器遇到这个声明时，只跳过 layout 和 paint，但 <img> 的网络请求照常发起。你看到“图没出来”，是渲染被跳过，不是还没下载；Network 面板里能清楚看到请求早已发出，甚至排在首屏资源前面。若这张图恰是 LCP 元素，content-visibility 不但救不了，还会掩盖真实瓶颈——比如它本该 fetchpriority="high" 却被 DOM 位置拖到队尾。
- 它不阻止图片请求，只跳过渲染
- 对无固定高度的容器（如仅含
<img>的<div>）会失效，因 <code>contain-intrinsic-size必须显式设置 - 若内部有
position: fixed或transform，强制重绘抵消全部收益 - 去掉
loading属性，或显式写loading="eager"（不要留空） - 在
中加预加载：<link rel="preload" as="image" href="hero.webp" fetchpriority="high">——as="image"缺一不可，否则不进高优队列 - 避免把首屏图写在 DOM 后半段（例如放在页脚附近再用 CSS
position: absolute拉上来），这会让浏览器误判其非关键性 -
<img>的 DOM 位置必须在首屏内容之后（不能是第 1 个<img>却靠 CSS 移到页面底部） - 必须配合响应式
srcset，例如：<img src="small.jpg" srcset="small.jpg 500w, medium.jpg 1000w, large.jpg 2000w" sizes="(max-width: 600px) 500px, 1000px"> - 图片格式必须是 WebP 或 AVIF，单张建议 ≤ 300KB；JPEG 质量控制在 60–75% 区间
- 容器必须设固定高度：
contain-intrinsic-size: 120px（不能是0、auto或百分比） - 用
@supports (content-visibility: auto)包裹，降级方案用opacity: 0.99（比display: none更安全，避免布局抖动） - 禁用内部
position: fixed、transform、animation等触发重绘的属性
首屏大图必须用 loading="eager" + <link rel="preload">
移动端弱网下，首屏图延迟 1 秒 = LCP 延迟 1 秒。不能依赖浏览器默认行为，必须主动干预加载优先级。
非首屏大图要用 loading="lazy"，但得满足三个前提
懒加载不是加个属性就完事。它生效的前提是：浏览器能准确判断该图是否在视口外，且不因此阻塞关键路径。
用 @supports + contain-intrinsic-size 安全启用 content-visibility
它只适合「不参与首屏、高度可预估、无动态尺寸变化」的图片区块，比如瀑布流第 20 页后的卡片列表，或折叠评论区。
最容易被忽略的是：调 content-visibility 前，得先确认那张大图是否已在 Network 面板里被排到了队尾——如果请求本身就慢，这个 CSS 属性连边都碰不到。
