rel="preload"仅对浏览器无法自主发现且首屏立即需要的图片有效，如CSS background-image、内联JS动态创建的Image实例等；必须写在<head>中、指定as="image"，否则降级为低优先级fetch。
预加载图片不是“加了就快”，而是必须精准匹配资源调度链路——用错位置、填错as、漏掉crossorigin，都会导致请求被降级甚至静默失败。
什么时候该用 rel="preload" 加载图片
它只对「浏览器无法自主发现 + 当前页首屏立即需要」的图片有效。典型场景包括：background-image 写在 CSS 里、@font-face 引用的图标字体、内联 JS 中动态创建的 Image() 实例、或通过 fetch() 加载的 JSON 里带的 banner 图 URL。
- 不要给轮播图所有图片都 preload：浏览器预扫描器（preload scanner）已经能自动发现
<img src>，重复 preload 会抢占带宽 - 不要对
<picture>里的<source>单独 preload：浏览器不识别这种间接引用，必须指向最终解析出的src地址 - 检查 Chrome DevTools → Network → 刷新（禁用缓存），确认目标图片是否出现在 HTML 解析完成前 —— 如果它排在 main.js 后面才发起，才是 preload 的适用位
as="image" 必须配 crossorigin 吗
不需要。只有 as="font" 强制要求 crossorigin；as="image" 在同源时可省略，但跨域图片建议显式写上 crossorigin="anonymous"，否则某些 CDN 或 S3 配置下可能触发 CORS 预检失败且无明确报错。
- 错误写法：
<link rel="preload" href="https://cdn.example.com/hero.jpg">（缺as，降级为低优先级 fetch） - 正确写法：
<link rel="preload" href="https://cdn.example.com/hero.jpg" as="image" crossorigin="anonymous"> - 如果图片是 WebP/AVIF 格式，
href必须是最终加载地址（不能是 .jpg 占位符），否则格式协商失败，浏览器仍会回退下载原格式
preload 和 lazyload 能一起用吗
能，但必须分清职责：preload 是「现在就要」，lazyload 是「等会儿再要」。混用会导致冲突或浪费。
立即学习“前端免费学习笔记（深入）”；
- 首屏关键图（如 LCP 元素）：用
<link rel="preload" as="image">+<img src="hero.webp">（不加loading="lazy"） - 第二屏开始的图：用
loading="lazy"，或data-src+IntersectionObserver，不要 preload - 绝对不要这样写：
<link rel="preload" href="list-1.jpg" as="image"><img src="list-1.jpg" loading="lazy">—— 浏览器可能提前加载又丢弃，或因 3s 超时取消请求（Chrome 94+ 行为）
为什么预加载后图片还是没显示出来
常见原因不是加载失败，而是渲染链路断开：preload 只管下载进内存缓存，不负责插入 DOM 或触发绘制。若图片实际由 JS 动态赋值（如 el.style.backgroundImage = url(...)），必须确保 JS 执行时机早于渲染，且 URL 字符串与 preload 的 href 完全一致（含查询参数、大小写）。
- 检查 Network 面板中该资源状态：如果是
from memory cache但页面空白，说明 JS 没读取或赋值逻辑有误 - 避免在
DOMContentLoaded之后才执行背景图赋值：此时渲染已开始，可能跳过重绘 - 不要用
document.write()或 innerHTML 插入含 preload 的片段：会破坏预加载器扫描上下文
