HTML中Link标签的Prefetch指令于搜索结果点击加速的实战

prefetch无效主因是触发条件苛刻：仅页面空闲时低优先级加载，且要求URL静态化、强缓存（Cache-Control: public, max-age=31536000）、同源合法路径；盲目预取动态搜索结果链接导致90%请求白发、缓存白占。

写了 link rel="prefetch" 却没看到搜索结果页变快？不是代码写错了，而是它根本没触发——prefetch 只在页面空闲时低优先级下载，且只对用户大概率点击的链接有效，盲目预取前 10 条搜索结果，90% 的请求白发、缓存白占。

为什么搜索页加 prefetch 常常无效

搜索结果页的典型场景是：用户输入关键词 → 展示 10 条结果 → 点击第 1～2 条。但浏览器并不知道哪条会被点，更不会主动猜；它只认你硬编码进 HTML 的 href。

• 用户还没触发 load 事件（比如 JS 渲染结果列表用了长任务），prefetch 就被阻塞
• 你预取了第 1～10 条，但实际点击集中在第 1 条，其余 9 个请求浪费带宽、挤占缓存
• 搜索结果 URL 带动态参数（如 /item?id=123&q=xxx），而你写的 href 是静态路径，根本匹配不上
• 后端返回头没配 Cache-Control: public, max-age=31536000，下次跳转时缓存失效，prefetch 白做

真正该 prefetch 哪些搜索结果链接

只预取「确定会被高频点击、路径可静态化、资源复用率高」的那 1～2 个目标，而不是堆数量。

• 首页搜索框默认推荐的「热门商品」或「最近搜索」对应的结果页，URL 固定，如 /product/iphone-15
• 搜索页顶部 banner 或「猜你喜欢」模块里的固定入口，比如 /topic/summer-sale
• 搜索关键词命中后，服务端已知的「首条高置信结果」，可通过 SSR 或构建时注入，而非客户端 JS 拼接
• 避免预取带用户态参数的 URL（如 /search?from=history&uid=xxx），这类链接无法复用，也不该进 HTTP 缓存

如何验证 prefetch 是否真生效

别只盯着 Network 面板里有没有请求，要确认它是否进了缓存、并在跳转时被复用。

立即学习“前端免费学习笔记（深入）”；

• 打开 Chrome DevTools → Network → Filter 输入 prefetch，勾选 “All”，找 Initiator: Other 且 Priority: low 的条目
• 刷新页面后立即点开预取的目标页，再看 Network → 找对应资源的 Size 列是否显示 from disk cache 或 from memory cache
• 检查响应头：目标资源必须返回 Cache-Control 且不含 no-store 或 private；若含 immutable，则 prefetch 后几乎永不重验
• 用 chrome://net-internals/#events 搜 URL_REQUEST 和目标 URL，能看到完整生命周期，包括是否被取消、是否因跨域静默丢弃

容易被忽略的同源与路径细节

prefetch 对路径和协议极其敏感，错一个字符就失效。

• href 必须是绝对路径或相对于当前页面的合法路径；//cdn.example.com/next.js 这种协议相对 URL 会被当成非法协议直接忽略
• 跨域请求（协议、域名、端口任一不同）在 Chrome/Firefox 中静默丢弃，Network 里连失败记录都没有
• 如果搜索页是 HTTPS，但预取的链接是 HTTP（如 http://api.example.com/item/123），现代浏览器直接跳过，不报错也不发请求
• SPA 场景下，不要在 JS 里动态插入 link 标签（如 document.head.appendChild(link)），绝大多数浏览器只处理初始 HTML 解析阶段的 prefetch

最麻烦的不是怎么写，而是判断“用户下一步到底点哪个”——这需要结合埋点数据、AB 实验和后端 query 聚类，而不是靠前端硬编码猜。写多了反而污染缓存、拖慢真实请求。