content-visibility: auto 对移动端大图无效，因它不阻止图片请求仅跳过渲染；真正适用场景是固定高度的离屏容器，如瀑布流后页卡片、折叠评论区等，需配合 contain-intrinsic-size 和 @supports 降级。
content-visibility: auto 对移动端大图本身无效，加了反而可能让 LCP 更差——它不控制图片请求，只跳过渲染，而卡顿根源常在下载慢或布局抖动。
为什么给 <img> 或图片容器加 content-visibility: auto 没用
浏览器遇到 content-visibility: auto 时，仅跳过 layout 和 paint，但 <img> 的 fetch 请求照常发起。你看到“图没出来”，是渲染被跳过，不是还没下载；Network 面板里能清楚看到请求早已发出，甚至排在首屏资源前面。若这张大图恰是 LCP 元素，它被延迟下载（比如因 DOM 位置靠后 + 未设 fetchpriority），content-visibility 不但救不了，还会掩盖真实瓶颈。
真正该加 content-visibility: auto 的地方：固定高度的离屏图片区块
它只适合「不参与首屏、高度可预估、无动态尺寸变化」的容器，比如：
- 商品瀑布流中第 20 页之后的卡片列表（每张卡片含图，高度固定 120px）
- 评论区折叠后的历史评论区（文字+头像图，预估高度 160px）
- Tab 切换后未激活的面板（内含多张图，但整个面板高度已知）
必须同时满足：
- 容器上设
contain-intrinsic-size: 120px（不能写0、auto或百分比） - 避免内部有
position: fixed或transform，否则强制重绘抵消收益 - 用
@supports (content-visibility: auto)包裹，降级方案如opacity: 0.99
移动端大图卡顿的正确解法组合
先定位卡在哪：打开 Chrome DevTools → Network 标签，看那张大图的 Start Time 是否远晚于 TTFB；再切到 Performance 标签，确认 LCP 元素是不是它。然后针对性处理：
- 首屏大图必须去掉
loading属性，或显式写loading="eager" - 在
加预加载：<link rel="preload" as="image" href="hero.webp" fetchpriority="high">（as="image"缺一不可） - 非首屏大图才用
loading="lazy"，且确保 DOM 顺序合理（LCP 图不能出现在它后面） - 响应式
srcset+ WebP/AVIF 格式压缩，避免单张图超 300KB
最容易被忽略的是：你调 content-visibility 前，得先确认那张大图是否已在 Network 面板里被排到了队尾——如果请求本身就慢，这个 CSS 属性连边都碰不到。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
