preload 不适合延后加载次要图片，因其设计目标是尽早发起请求，无论位置如何都会立即触发；可靠延后方式为 loading="lazy"、intersectionobserver 手动控制或 js 动态插入 img 标签。
不能用 rel="preload" 延后加载次要图片——它天生就是“抢跑”的，写进去就立刻触发，和“延后”目标完全相反。
为什么 preload 不适合延后处理
rel="preload" 的设计目的只有一个：让浏览器在解析 阶段就发起请求，比 DOM 构建还早。它没有延迟、节流、条件触发机制。哪怕你把它放在 底部，只要被 parser 读到，就会立即 fetch。试图用它“延后”，等于用油门控制刹车。
- 浏览器不支持
delay、timeout或媒体查询条件式 preload - 动态插入
<link rel="preload">（比如document.createElement('link')）完全无效，Initiator 显示为(Other)，Priority 降为Low - 加
fetchpriority="low"也没用：preload 本身已强制设为 high，该参数只对普通<img>或fetch()生效
真正能延后次要图片的三种可靠方式
延后 = 控制请求发起时间点。只有改变“什么时候创建请求”才能做到，而不是改优先级或标签语义。
-
用
loading="lazy"+ 合理 DOM 位置：把次要图片的<img>标签放在 HTML 靠后位置（比如<footer></footer>里），并确保它满足懒加载生效四条件（真实src、有宽高、父容器无transform、初始静态结构）。浏览器会等它快进视口时才发请求 -
用
IntersectionObserver手动控制：适合需要自定义阈值（如滚动前 300px 就加载）、失败重试或 fallback 占位的场景。回调里只做两件事：img.src = img.dataset.src和observer.unobserve(img) -
JS 动态插入
<img>标签：比如在DOMContentLoaded后 500ms 再appendChild，或监听用户操作（如点击“查看更多”）后再插入。注意别在插入前就赋值src，否则会立刻加载
常见误操作：看似延后，实则白忙
这些做法不会真正延后请求，反而可能引发重复加载、白屏或兼容性问题：
- 给
<img>加style="max-width:90%"或opacity:0：样式隐藏不影响请求发起，parser 解析到就加载 - 用
data-src替换src但没配 JS 激活逻辑：HTML 里没src，浏览器根本不会发请求；但一旦 JS 补上src，就立刻加载，毫无延后效果 - 在
<picture></picture>里给<source></source>加loading="lazy"：该属性只对<img>和<iframe></iframe>生效，<source></source>上写了也忽略 - 用 CSS
background-image配opacity:0：同样，声明即加载，且无法监听加载状态
真正关键的是：延后不是靠“藏”，而是靠“晚造”。什么时候把请求指令交给浏览器，决定了它什么时候出发——这个时机，preload 给不了，得靠 DOM 插入、loading 属性或 IntersectionObserver 来拿捏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
