目录站要不要上 Speculation Rules：预取、预渲染和四档急切程度怎么选

2026-10-24 约 2,224 字预计阅读 6 分钟 yiyunkj

目录站的典型动线是这样的：进首页或分类页，扫一眼，点某个条目进详情页。这一步跳转能不能做到「点了就到」，Chrome 的 Speculation Rules API 是现在最直接的答案。

它允许你在页面里放一段 JSON，告诉浏览器：这些链接用户可能会点，提前准备一下。「准备」分两档——只预取文档，或者直接预渲染整个页面。

Speculation Rules API 的四档 eagerness 与预取预渲染上限对照示意图

图片来源：网络，版权归原作者所有，侵权请联系删除

先说它和老写法的区别

很多人印象里的 <link rel="prerender"> 已经不是当年的东西了。Chrome 早先支持的那个旧语法后来被 NoState Prefetch 取代——只抓资源，不真正渲染，也不执行 JS。旧的 rel=prerender 现在仍然指向 NoState Prefetch，官方计划在某个时间点弃用它。

新的完整预渲染不用那个语法，改用 Speculation Rules。另外 <link rel="prefetch"> 的定位也变了：官方现在建议文档导航的预取用推测规则，rel=prefetch 只用来预取子资源。区别在于推测规则加载的文档是按导航的方式处理的（只是不渲染），存在内存里，所以连 HTTP 缓存里存不住的文档也能预取。

两种写法

列表规则——明确给出网址，适合「下一步几乎必然是这几个之一」的场景：

<script type="speculationrules">
{
  "prerender": [{ "urls": ["/item/hot-1", "/item/hot-2"] }]
}
</script>

文档规则——按条件自动匹配页面上的链接，适合目录站这种一页几十个链接的情况：

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/item/*" },
        { "not": { "selector_matches": ".do-not-prerender" } }
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

文档规则从 Chrome 122 起可用。更早的版本里还有个 source 键（list 或 document），Chrome 121 起已经不需要写了，看到老代码里有不用管。

四档急切程度

eagerness 决定什么时候触发，这是控制浪费的主要旋钮：

档位	触发时机	适合谁
immediate	看到规则就立刻推测	列表规则（默认值）
eager	桌面端悬停约 10 毫秒；移动端锚点进入视口约 50 毫秒	轻量静态站
moderate	桌面端悬停 200 毫秒或 pointerdown；移动端按视口启发式	大多数站，推荐起点
conservative	按下或触摸时才推测	文档规则（默认值）

注意 eager 的语义变过：早期它和 immediate 完全一样，从 Chrome 143 起才改成介于两者之间。文档规则的默认值是 conservative，因为一页可能有几十个链接，默认就太保守了些，一般建议显式写 moderate。

Chrome 的两套上限

浏览器会限制推测数量，防止过度使用：

immediate：预取最多 50 个，预渲染最多 10 个。
eager / moderate / conservative：预取和预渲染各 2 个，先进先出。

另外这些情况下不会推测：开启节能模式且电量低、内存不足、用户在浏览器设置里关掉了「预加载网页」（uBlock Origin 这类扩展会明确关掉它）、页面在后台标签页中。跨源 iframe 在页面激活前也不会渲染。

目录站该怎么配

导航站有两个特点会影响选择：一页链接特别多，而条目页本身通常很轻。所以推荐这么配：

用文档规则，eagerness 选 moderate。一页五十个链接全用 immediate 是浪费，conservative 又太晚（点了才开始，等于没有提前量）。
排除掉出链。目录站有大量指向第三方站点的链接，那些不是你的页面，预渲染没意义还浪费。用 href_matches 只匹配站内路径。
首页的「热门」区块可以单独用列表规则 + immediate。那几个位置点击率明显更高，值得最高优先级。
先上 prefetch，稳了再上 prerender。官方也建议把预取当成走向预渲染的第一步。预取只花一点流量，预渲染要跑完整页面，包括执行 JS 和发起页面内的所有请求。

两个别忘了的事

服务器成本。预渲染是真实发起一次导航请求。如果一个分类页的五十个卡片全被预渲染，你的服务器就得多扛五十次条目页请求。轻页面还好，重页面要算一下。这也是为什么要从 moderate 起步，而不是 immediate。

统计口径。预渲染的页面如果被激活，会产生一次真实的页面浏览；如果没被激活，不应该算。所以埋点脚本要注意区分激活状态，别把「预渲染了但用户根本没去」算成 PV。同理，预渲染时页面处于隐藏状态，那些会打扰用户的 API（比如通知权限弹窗）会被推迟到激活时再触发，这个行为是符合预期的。

和 SEO 有关系吗

官方的态度是把它当成提示和渐进增强：不像 preload 那样是硬性的，浏览器会根据用户设置、内存占用和其他启发式方法选择不执行。所以它不会改变爬虫看到的内容——爬虫拿到的 HTML 跟原来一样，正常链接也还在。

真正的好处是体验侧的：LCP 接近零、CLS 变小（加载期的位移发生在首屏之前）、INP 改善（加载在用户交互前就完成了）。这些是真实用户数据，会被 CrUX 采进去。

一句话总结：把它当成锦上添花，不是救命稻草。页面本身慢的话，预渲染掩盖不了第二次访问之外的问题。