只有当图片是关键渲染资源（如首屏大图、banner、核心图标）时才该用；必须写在中、as="image"、href路径与完全一致，否则无效。
什么时候该用 <link rel="preload"> 加载图片
只有当图片是关键渲染资源（比如首屏大图、Banner、核心图标）时才值得预加载。浏览器对 preload 不会做懒加载判断，它会在 HTML 解析早期就发起请求，如果乱用反而挤占带宽、干扰正常资源加载顺序。
常见误用场景：给所有 <img> 都加 preload；在非首屏区域或交互后才显示的图上提前预加载；用 preload 替代 loading="lazy"。
- 只对
fetchpriority="high"且实际在首屏可见的图片考虑preload - 避免和
srcset/sizes混用——preload不支持响应式语法，必须指定一个确定的 URL - 不能放在
里，必须写在中，否则会被忽略
<link rel="preload"> 的写法和参数限制
它不是“让图片提前显示”，而是“让图片资源提前下载”。浏览器不会解码、不渲染，只存进内存缓存，等真正 <img> 标签用到时再复用。
必须显式声明 as="image"，否则可能被降级为 fetch 级别，失去高优先级待遇；href 必须是绝对路径或根相对路径（如 /images/banner.webp），不能是相对路径（如 ./banner.webp），否则可能 404。
<link rel="preload" as="image" href="/images/hero.jpg">- 若图片有 CDN 域名，直接写完整 URL：
href="https://cdn.example.com/logo.svg" - 不支持
type属性做 MIME 判断（如type="image/webp"），浏览器按实际响应头识别格式 - 不能加
media查询做条件加载——它无视媒体查询，始终触发
如何避免与现有图片加载逻辑冲突
最常踩的坑是：预加载了图片，但 <img> 标签里写的却是另一份 URL（比如不同尺寸、不同格式、带 query 参数），导致预加载白做了——缓存不命中，重复下载两次。
检查点：预加载的 href 和最终 <img src>（或 srcset 中匹配到的那项）必须完全一致，包括大小写、斜杠、query 参数。
- 如果用 WebP + fallback，预加载只能选一种格式（推荐 WebP），并在
<img>中确保该格式被实际使用 - 构建工具（如 Webpack/Vite）自动哈希文件名时，
preload的href必须同步更新，硬编码路径会失效 - 服务端渲染（SSR）中动态生成图片路径时，需确保
中的preload标签也由同一逻辑生成，不能静态写死
验证是否生效的三个关键检查点
光写对代码没用，得确认浏览器真按预期执行了。打开 Chrome DevTools → Network 标签页，筛选 Media，看是否有请求标记为 Preload，且时间线早于 DOMContentLoaded。
- 在请求详情的
Headers里确认Initiator是parser（说明来自 HTML 解析），不是script或other - 对比同张图的两个请求：如果
preload请求状态是200 (from memory cache)，而后续<img>请求是200 (from cache)或直接跳过，则说明复用成功 - 禁用 JS 后再刷新——如果图片仍能快速显示，说明预加载起效；如果变慢或空白，可能是 JS 动态插入
<img>导致无法复用预加载资源
预加载本身不解决解码慢、渲染阻塞或布局抖动问题，它只管“下得早”。真正影响首屏视觉速度的，往往卡在 CSSOM 构建、JS 执行或图片解码阶段——这些得另想办法。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
