link rel="preload"对首屏关键图片的加载时间影响通常在100–400ms之间，前提是路径静态、as="image"正确且存在“发现晚→使用早”的时间差；否则可能零增益甚至负收益，因其仅在图片被html延迟发现（如css background-image、动态插入img）时才有效，而直接写在html中的img标签解析极快，preload难以抢占时机。
直接说结论：link rel="preload"对首屏关键图片的加载时间影响，通常在 100–400ms 之间，但前提是资源路径静态、as="image"正确、且图片确实存在“发现晚→使用早”的时间差；否则可能零增益甚至负收益。
为什么 preload 图片有时快得不明显？
浏览器对 <img> 标签的解析和请求发起其实非常快——只要 HTML 里写了 <img src="/hero.jpg">，parser 一碰到就发请求。所以如果 hero 图就在 开头，preload 几乎没机会抢时间。
- 真正能受益的是被“藏”起来的图片：比如内联
<style></style>里的background-image、<picture></picture>中靠后的<source></source>、或 JS 动态插入的<img> - 若图片体积小（
-
fetchpriority="high"在 Chrome 101+ 有效，但 Safari 和 Firefox 不识别，不能当作跨浏览器提速手段
as="image" 写错或漏写，等于没写
as 不是可选项，它直接决定浏览器是否按图片逻辑处理该请求。漏掉或写成 as="fetch"，浏览器就当普通 fetch 处理，Priority 显示为 Low，和没加标签一样。
-
as="image"→ 请求头带Accept: image/webp,image/apng,image/svg+xml,image/*,*/*，触发图片解码预判和缓存分区 -
as="script"或as="style"用在图片上，会导致 MIME 类型校验失败，Chrome 直接丢弃响应（Network 面板显示failed但无报错） -
href必须是完整静态路径，href="./hero.webp"在子路径页（如/blog/post）下会 404；必须写成/assets/hero.webp或https://cdn.example.com/hero.webp
和 Image 对象比，preload 更早但更死板
link rel="preload" 在 HTML 解析第一帧就开始拉资源，比 JS 执行早几百毫秒；但一旦写死在 里，就没法根据设备像素比、用户偏好或网络条件动态切换。
- 想支持
@2x图？link不支持srcset，只能选一个确定尺寸/格式的 URL，比如/hero-1200w.webp - 需要监听加载失败重试？
link没onerror，必须配合 JS 的Image对象做 fallback - 想控制并发数？
link是声明式，浏览器自己调度；new Image()可用Promise.allSettled限流，避免打爆连接池
真正难的不是怎么写这行标签，而是判断“这张图到底算不算首屏关键”——它取决于你是否清楚 parser 到达那个 <img> 的确切位置、当前网络 RTT、以及用户滚动行为是否会让它进视口。写错一行 as，或预加载一张用户根本不会看到的图，比不加还伤性能。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
