link rel="preload"必须置于<head>早期，紧接<meta charset>和<title>后、首个外部CSS/JS前；否则被忽略；需指定as、fetchpriority，避免与loading="lazy"混用，首屏图须eager+high优先级。
link rel="preload" 必须写在 head 早期位置
浏览器只在 HTML 解析的初始阶段（parser phase）识别 link rel="preload"，动态插入或放错位置等于没写。它必须紧接在 <meta charset> 和 <title> 之后、首个外部 <link rel="stylesheet"> 或 <script src> 之前。否则关键 CSS 或 JS 已发起请求，preload 指令被忽略。
常见错误：
- 把
<link rel="preload">放在<script>标签后面 - 用 JavaScript 动态 append 到
document.head - 漏写
as="image"，导致浏览器按普通 fetch 处理，Priority 降为 Low
preload 不等于 img，别混用 loading 属性
loading="lazy" 是延迟加载，和预加载完全相反。给首屏图片加 loading="lazy" 会让 Chrome 延迟到滚动前 500px 才发请求，直接抵消 preload 效果。首屏图必须保持 loading="eager"（默认值），且配合 fetchpriority="high" 确保解码优先级。
正确组合方式：
立即学习“前端免费学习笔记（深入）”；
-
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">（提前拉取） -
<img src="/hero.webp" fetchpriority="high" width="1200" height="600">（确保渲染不跳动）
漏设 width/height 会导致 layout shift，也会影响 Safari 对 lazy 加载的判断逻辑。
避免用 Image 对象密集触发请求
JavaScript 创建 Image 对象虽可控，但浏览器并发连接数有限（通常 6–8 个）。在循环里密集执行 new Image() + 赋值 src，会挤占关键资源带宽，反而拖慢首屏。
适用场景仅限于条件触发，例如：
- 用户 hover 导航项后预加载下一页 banner
- 根据
window.devicePixelRatio选择性加载 @2x 版本 - 配合
IntersectionObserver提前 200px 加载即将进入视口的图
记得监听 onload/onerror，失败不会抛异常；也不必手动清理 img.src = ''，GC 会回收，除非你把它挂在全局变量里长期持有。
WebP 预加载必须带 type 属性并 fallback
现代浏览器对 WebP 支持良好，但 preload 时若只写 href="/hero.webp"，旧版 Safari 或部分安卓 WebView 可能无法识别 MIME 类型，导致缓存策略错乱或请求失败。
稳妥做法：
- 加
type="image/webp"明确声明格式 - 同时提供 JPEG fallback：
<picture><source srcset="/hero.webp" type="image/webp"><img src="/hero.jpg"></picture> - 不要依赖服务端 User-Agent 判断——preload 是纯静态声明，无法运行 JS 逻辑
真正容易被忽略的是：WebP 图片若未压缩到位（比如导出时未勾选“无损”或“质量 80+”），体积反而比 JPEG 大，预加载就失去意义。
