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

如果你也在搜索结果页面尝试过 ，但发现页面加载速度并没有明显提升——别急着怀疑是自己的编码出了问题。问题很可能不是写错了，而是这个指令压根就没被真正执行。

Prefetch 的触发条件相当“挑剔”：它只会在浏览器空闲时，以低优先级去下载资源。而且，它对 URL 的要求极高——必须是静态的、带有强缓存头（比如 Cache-Control: public, max-age=31536000）、并且同源、路径合法。所以，如果你一上来就把搜索结果的前 10 条链接全预取了，那么结果很可能就是：90% 的请求白白浪费，缓存空间也被大量占用。

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

搜索结果页的典型流程很清晰：用户输入关键词 → 展示 10 条结果 → 点击第 1～2 条。但问题在于，浏览器并不会自动去猜测用户到底会点哪一条；它只认你硬编码在 HTML 里的 href。来看看常见的踩坑点：

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

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

正确的思路不是堆数量，而是只预取那些“确定会被高频点击、路径可静态化、资源复用率高”的 1～2 个目标。具体来说，可以从下面几个方向入手：

• 首页搜索框默认推荐的“热门商品”或“最近搜索”对应的结果页。比如 /product/iphone-15，这类 URL 是固定的
• 搜索页顶部的 banner 或“猜你喜欢”模块里的固定入口，比如 /topic/summer-sale
• 搜索关键词命中后，服务端已知的“首条高置信结果”。这个可以通过 SSR 或构建时注入，而不是靠客户端 JS 去拼接
• 避免预取带用户态参数的 URL（如 /searchfrom=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 聚类来做决策，而不是靠前端硬编码去猜。写多了反而会污染缓存、拖慢真实请求，得不偿失。