<link rel="preload">是HTML中预加载关键资源的正确方式，必须置于<head>最前、配准as属性（如as="font"需crossorigin）、静态声明且路径严格匹配，否则静默失效。
<meta> 标签本身不支持预加载功能，HTML 中用于预加载关键资源的正确方式是 <link rel="preload">，不是 <meta>。常有人误把 rel="preload" 写成 <meta>，这会导致完全无效——浏览器直接忽略，Network 面板里看不到请求，Priority 显示为 Low，Initiator 是 (Other)。
真正起效的预加载，必须用 <link>，且严格满足以下条件：
- ✅ 必须放在
<head>最前面（紧贴<meta charset>或<title>之前） - ✅
as属性必须准确填写（如as="font"、as="image"、as="script"） - ✅
href必须是静态路径，大小写、斜杠、协议必须与后续实际使用的 URL 完全一致 - ✅ 动态插入（如 JS 创建
<link>）、放在<body>里、或被构建工具塞到 CSS 后面，全部失效
关键搜索资源怎么用 preload 加速
搜索场景下，真正该 preload 的不是“搜索结果页本身”，而是当前页首屏强依赖、但浏览器无法自动发现的资源，比如：
- 搜索框聚焦时立即要用的图标字体（如
search-icon.woff2），藏在@font-face里 - 首屏搜索推荐卡片中用
background-image声明的 banner 图（内联<style>中） - 搜索联想接口返回的 JSON Schema 文件（如
/api/suggest/schema.json），被内联 JS 同步 fetch - SSR 渲染的搜索页顶部固定模块所依赖的主 JS chunk（如
search-main.js），紧跟<script type="module">
这些资源共同特点是：当前页立刻要渲染，但 parser 看不见、preload scanner 扫不到、等 JS 执行才发起请求 → 就会卡住 LCP 或触发 FOIT/FOUT。
立即学习“前端免费学习笔记（深入）”；
为什么不能对搜索结果链接用 preload？
-
<link rel="preload" href="/result?id=123">是错的：as属性不支持document类型的页面级预加载（as="document"不被主流浏览器识别，Chrome 会降级为普通 fetch） - 搜索结果页 URL 带 query 参数（如
?q=xxx&from=search），每次不同 → 缓存基本无效，还可能污染磁盘缓存 - 浏览器对
as="document"支持极差，实际行为不稳定；真要预取下一页，该用rel="prefetch"，不是preload
验证是否真的加速了
打开 Chrome DevTools → Network 面板 → 刷新页面后筛选：
- Initiator 列显示为
preload（不是parser、script或(Other)） - Priority 列：字体应为
Highest，图片/CSS/JS 应为High（若显示Medium或Low，说明as漏写或写错） - Start Time 对比未加前：理想提前 200–600ms，尤其在弱网下更明显
- Size 显示
from memory cache或from disk cache，说明后续复用成功
不复杂但容易忽略。
