应仅对当前导航中立刻要用的关键资源使用preload，如首屏字体（需as="font"+crossorigin）、Hero图、异步模块入口；避免用于非首屏JS、prefetch类资源或未压缩大图，且必须配合真实引入，否则白下载并可能阻塞关键资源。
怎么判断该不该用 preload
不是所有资源都值得 preload，它只对「当前导航中立刻要用」的资源有效。浏览器会把它标为 Priority: high，抢带宽；如果资源没被后续代码引用，DevTools Network 面板会报 “Preload request for ‘xxx’ is not used”，还可能挤掉 HTML 或关键 CSS 的下载。
典型该用的场景：
-
font.woff2：首屏文本依赖的字体，必须配as="font"+crossorigin，否则加载失败 - Hero 图对应的
src地址：比如<img src="hero.jpg">，就preload这个hero.jpg - 异步模块入口：比如
import('./module.js')立刻调用，可先preload它
不该用的：
- 非首屏 JS（如弹窗逻辑、后台同步脚本）
- 所有
prefetch类资源（下一页用的 CSS/JS） - 未压缩的大体积图片（先压图，再决定是否
preload）
preload 和 defer/async 怎么配合
单独 preload 只下载不执行，必须和实际引入方式联动才生效。常见组合：
立即学习“前端免费学习笔记（深入）”；
- 预加载 JS +
defer：<link rel="preload" href="main.js" as="script">+<script src="main.js" defer></script>—— 下载提前，执行时机不变，但避免了首次请求延迟 - 预加载 CSS + 正常
link：<link rel="preload" href="critical.css" as="style">+<link rel="stylesheet" href="critical.css">—— 浏览器拿到preload后立即发起请求，等真正link解析时直接复用缓存 - 不搭配
async：因为async执行不可控，preload下载完立刻执行可能早于 DOM 就绪，反而引发错误
注意：不能只写 preload 而漏掉后续真实引入，否则资源白下，页面也用不上。
为什么 crossorigin 在字体 preload 里不能省
Web 字体受 CORS 策略限制，即使同域也要显式声明 crossorigin，否则浏览器会拒绝应用预加载的字体文件，导致 FOIT（空白期）依旧存在。
正确写法必须包含三要素：
as="font"-
crossorigin（属性本身无值，写上即可） -
type="font/woff2"（推荐，提升 MIME 匹配准确率）
错误示例：<link rel="preload" href="font.woff2" as="font"> —— 缺 crossorigin，Chrome 直接忽略该 preload 指令。
预加载链路容易被忽略的兼容性断点
preload 在主流现代浏览器支持良好，但真实链路里有两处易断点：
- HTTP/2 环境下，
preload请求会抢占流优先级，若服务器未正确配置流控制，可能卡住 HTML 响应流本身 - CDN 缓存策略若未透传
LinkHTTP 头（对应preload的 Header 形式），会导致服务端渲染（SSR）页面在 CDN 边缘节点丢失预加载指令 - 部分安卓 WebView（尤其 Android 8 及更早）不识别
as="font"，需 fallback 到as="fetch"并手动 fetch + inject，但代价是失去浏览器原生字体加载优化
上线前务必用真实设备 + Lighthouse 跑一遍，重点看 Preload key requests 是否命中且无 warning。
