应仅对搜索结果页前1–3条高点击概率、URL稳定、无query参数、无副作用的静态页面（如商品/文章详情页）使用rel="prefetch"，且必须置于<head>中meta/title之后，通过Initiator为Prefetch、Priority为Low、缓存命中验证效果。
搜索结果页预加载，本质是“猜用户下一步点哪”，但不是所有链接都适合预加载——盲目加 rel="prefetch" 可能白耗带宽、污染缓存、甚至触发跨域 Cookie 泄露。
哪些链接该用 rel="prefetch"？
只对高确定性、低变更频率、无副作用的页面做预加载。搜索结果页里，通常只有前 1–3 条结果符合：
- 用户点击 Top1 的概率远高于 Top5，Top3 之外基本不值得预加载
- 商品详情页、文章详情页这类静态内容页比登录页、表单页更安全（后者可能含 CSRF Token 或临时会话）
- 避免预加载带 query 参数的 URL（如
/product?id=123&utm_source=search），参数变动会导致缓存失效或命中错误资源 - 若结果页本身由 SSR 渲染且 URL 稳定（如
/post/2024-06-15-title），可放心预加载
rel="prefetch" 放错位置就等于没写
必须写在 <head> 里，且要在对应资源标签（比如 <link rel="stylesheet">）之前；如果构建工具自动注入，得确认它没被塞进 <body> 或靠后位置。
- 浏览器只在初始 HTML 解析阶段读取
prefetch指令，document.write或 JS 动态插入完全无效 - 放在
<meta charset>和<title>之后，越早越好——延迟 100ms 可能错过空闲窗口 - 多个
prefetch标签之间无顺序依赖，但建议按用户点击概率从高到低排列，部分浏览器会据此调整优先级
怎么验证预加载是否生效？
别只看 Network 面板有没有请求，重点看三个信号：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 请求发起者（Initiator）显示为
Other或Prefetch，而不是某个 JS 文件 - Priority 显示为
Low（注意：不是High，那是preload的特征） - 响应状态码是
200且 Size 显示为from memory cache或from disk cache，说明后续跳转真用了缓存 - 打开 DevTools → Application → Cache Storage，检查是否有对应 URL 的缓存条目（Firefox 和 Chrome 行为略有差异）
容易被忽略的副作用
预加载不是免费午餐，尤其在搜索场景下：
- 跨域预加载会携带当前域 Cookie，若目标站未设
SameSite=Lax，可能意外触发登录态同步或埋点上报 - 服务端日志里会出现大量
200请求但无真实 PV，干扰统计系统（GA4、百度统计等需额外过滤User-Agent含prefetch的请求） - 移动端弱网下，预加载可能抢占首屏关键资源带宽，导致本页渲染变慢——建议配合
media属性做条件加载，例如：<link rel="prefetch" href="/post/abc" as="document" media="(min-width: 768px)">
真正起效的预加载，不是堆数量，而是控制粒度：只预加载那 1–2 个最可能被点开的 URL，并确保它在正确时机、以正确方式进入缓存。其他优化——比如服务端渲染首屏、压缩 HTML、启用 Brotli——永远比盲目预加载更可靠。
