link rel="preload"可让浏览器在HTML解析早期就发起头像图片请求，需满足as="image"、href为静态有效路径、置于<head>最前；否则失效，验证须看Network面板Initiator为preload且Priority为Highest。
用 link rel="preload" 提前加载头像图片
浏览器默认按 HTML 解析顺序加载资源，头像如果在 DOM 后半部分或由 JS 动态插入，可能延迟渲染。用 link rel="preload" 可让浏览器在解析 HTML 早期就发起请求，不阻塞渲染，也不执行解码，只预取。
关键点：必须指定 as="image"，否则浏览器无法复用该资源；href 必须是绝对或相对有效路径，不能是 data URL 或动态变量（如 ${avatarUrl}）。
- 放在
<head>中，越靠前越好（建议紧贴<meta charset>后） - 不支持响应式
sizes/srcset，若头像有多种尺寸，只预加载最常用的一版（如 128×128） - 若头像 URL 依赖登录态（如
/api/user/avatar?token=xxx），需确保该请求可被缓存（加Cache-Control），否则每次重载都重复预加载无意义
避免预加载失败的常见写法错误
预加载不是“写了就一定生效”，很多看似合理写法实际被浏览器忽略：
-
<link rel="preload" href="avatar.jpg">—— 缺少as="image"，浏览器当普通资源处理，不会进入图像解码流水线 -
<link rel="preload" href="/static/avatars/<code>user.id.webp" as="image"> —— 模板语法未被服务端渲染，HTML 中实际是字面量<code>user.id</code>，404 -
<link rel="preload" href="https://cdn.example.com/avatar.png" as="image" crossorigin>—— 跨域资源没配crossorigin属性时，即使请求成功，后续<img>也无法复用该预加载资源（会重新 fetch）
怎么确认预加载是否生效
打开 Chrome DevTools → Network 面板，刷新页面，筛选 type = "image"，找到对应头像请求，看 Initiator 列是否为 preload。再检查 Timing 标签页中 Start Time 是否显著早于其他图片。
立即学习“前端免费学习笔记（深入）”；
- 若
Initiator是parser或script，说明预加载没触发（路径错、as缺失、跨域未声明等） - 若请求状态是
200 (from memory cache)或200 (from disk cache)，说明复用成功；如果是200 (from service worker)，需确认 SW 是否拦截了预加载请求（一般不会，但自定义逻辑可能干扰） - 不要依赖 Lighthouse 的“Preload key requests”审计项——它只检查是否用了 preload，不验证是否真正复用
JS 动态头像场景下如何补救
用户登录后才拿到头像 URL（比如从 JWT payload 或 API 响应中提取），此时 HTML 已解析完毕，link[rel=preload] 已失效。只能退而求其次：
- 在获取到 URL 后立即创建
Image实例：const img = new Image(); img.src = avatarUrl;，触发浏览器提前解码（注意：这会占用解码线程，大量头像时慎用） - 用
fetch(avatarUrl, { mode: 'no-cors' })发起预取（仅限同域或配置了 CORS 的跨域资源），但 fetch 不触发解码，仅进 HTTP 缓存 - 更稳妥的做法是服务端在登录成功响应中，把头像 URL 注入到 HTML 的
<script>全局变量里，并在首屏 JS 中立即new Image().src = window.__AVATAR_URL__
预加载不是银弹，尤其对动态内容。真正影响体验的是“首次可见头像的加载延迟”，而不是“是否用了 preload 标签”。路径稳定、可预测的头像才值得预加载；频繁变化或条件性展示的，不如优化 CDN 缓存策略和图片格式（如优先用 AVIF/WebP）。
