link rel="preload"是唯一推荐的HTML原生预加载方式，必须静态写在<head>中、显式声明as属性（如as="image"）、href路径完全匹配后续使用地址，三者缺一不可，否则静默失效。
link rel="preload" 是唯一推荐的 HTML 原生预加载方式，其他如 loading="lazy" 或 display: none 都不是预加载，而是延迟或隐藏——用错就完全背离目标。
必须写对的三个核心参数：as、href、位置
浏览器只认这三个字段是否合规，缺一不可，错一个就等于没写。
-
as="image"必须显式声明：不写会被当普通 fetch 处理，无法进图片专用缓存池，也拿不到高优先级解码策略 -
href必须是静态、准确路径：支持绝对路径（/assets/logo.webp）或完整 URL（https://cdn.example.com/banner.jpg），但不能是相对路径（如./logo.webp），否则 HTML 在子目录下会 404 - 标签必须放在
<head>里：写在<body>中会被浏览器忽略，Lighthouse 也检测不到
fetchpriority="high" 什么时候起作用
这个属性只在 Chrome 109+ 生效，旧版直接忽略，无副作用，但别指望它在 Safari 或 Firefox 起效。
- 它能压过部分 CSS/JS 请求，让图片下载更早开始，尤其适合首屏 banner 这类抢眼资源
- 不要和
loading="lazy"同时用：逻辑冲突，Chrome 可能直接丢弃preload - 不支持 media 查询：加了
media="(min-width: 768px)"也没用，preload总是无条件触发
常见配置失效的硬伤点
预加载白做，90% 是因为这三处不一致，而不是语法写错。
立即学习“前端免费学习笔记（深入）”；
-
href和最终<img src>的 URL 必须完全相等：包括大小写、斜杠方向、query 参数（hero.jpg?v=2≠hero.jpg?v=3） - WebP + fallback 场景下，只预加载你实际会用到的那个格式（比如
srcset中匹配到的 WebP），别两边都 preload - 构建工具哈希文件名（如
logo.a1b2c3.webp）时，href必须同步更新；硬编码logo.webp就必然 404
最易被忽略的是：预加载只是把字节拉进内存缓存，不触发解码也不渲染。如果 <img> 标签本身写了 decoding="async" 或 loading="eager"，那它会在解析到时立刻从缓存取图——这才是“秒出”的关键链路。漏掉这环，preload 就只是个寂寞的请求。
