preload预加载大图基本无效，因浏览器对img标签有强启发式预加载能力；仅CSS中background-image等无法静态发现的场景才需preload as="image"，且须URL完全一致；fetchpriority="high"是更优方案。
用 preload 预加载大图基本无效
浏览器对 <img> 标签本身就有强启发式预加载能力，link rel="preload" as="image" 对首屏 <img src> 不仅没收益，还可能抢带宽拖慢 FCP。实测中，Chrome 会把 <img> 的请求优先级自动提至 Highest，而手动 preload 同一资源反而触发重复下载或降级为 Low。
- 只在极少数场景下有意义：比如
background-image引用的大图（CSS 里写的），浏览器无法静态发现，才需preload as="image" -
as="image"不支持srcset或sizes，无法适配响应式图片逻辑 - 若大图路径含动态参数（如
?v=123），preload和真实<img>的 URL 必须完全一致，否则缓存不命中
fetchpriority="high" 是更直接有效的方案
现代 Chrome/Edge 支持在 <img> 上直接声明优先级，比 preload 更精准、无冗余、不破坏语义。
- 写法：
<img src="hero.jpg" fetchpriority="high">（无需额外link） - 它让浏览器跳过默认的“延迟加载”启发式判断，立刻发起请求，且与
<img>的自然解析流程深度绑定 - 配合
loading="eager"可进一步关闭懒加载（尤其在非视口内但必须首屏渲染的场景） - 注意：Safari 目前不支持
fetchpriority，但也不会报错，只是退化为默认行为
真正需要 preload 的大图场景：CSS 中的 background-image
当首屏最大元素是 CSS 设置的 background-image（如 hero 区域），浏览器无法从 HTML 中提前识别该资源，LCP 就会卡在图片下载完成前——这时 preload 才是必要手段。
- 必须写对
as：<link rel="preload" href="/images/hero-bg.jpg" as="image"> - 路径要和 CSS 中实际使用的 URL 完全一致（包括协议、域名、斜杠、查询参数）
- 推荐加
fetchpriority="high"到对应容器元素上，辅助浏览器理解其视觉重要性 - 验证方式：Network 面板筛选
Initiator: preload，状态码为200且Priority显示Highest
别忽略字体和 CSS 的协同影响
一张大图能否成为 LCP 元素，不仅取决于它是否下载快，还取决于它是否能及时参与绘制——这常被卡在字体或样式上。
立即学习“前端免费学习笔记（深入）”；
- 如果大图上方有标题文字，而该文字依赖 Web Font，但字体没
preload+font-display: swap，文本会 FOIT，LCP 就不会落在图上，而落在 fallback 字体渲染后 - 如果大图通过
background-image加载，但关键 CSS 在 JS 后才注入（比如 CSS-in-JS），preload的图即使下载完也无法触发 LCP，因为样式层还没就绪 - 结论：单独优化图片加载不够，得确保它所依赖的样式、字体、布局上下文也同步就绪
