speculation rules 实测 27 个首页：只有 2 个在发，而且规则都不是站长写的

实测 · 2026-09-03 · 27 个首页 · 每站一次请求 · speculation rules 与老一代资源提示

样本 / 口径：2026-09-03 当天对 30 个首页各发一次 GET，桌面 Chrome UA，跟随跳转，不执行 JavaScript，出口在日本大阪。stackoverflow.com、medium.com、www.reddit.com 三个站返回 403，剔除后纳入 27 个。

27 个首页里，有 2 个页面源码里带 speculation rules：arstechnica.com 和 techcrunch.com。两个都跑 WordPress，两个都只做 prefetch，两个的 eagerness 都是 conservative，两段规则和 WordPress 内核文档写明的默认值逐项对得上。没有一个站做 prerender。同样这 27 个页面里，比它更早的那套 link rel 资源提示出现在 20 个站上。

怎么测的

每个站一次 GET，用桌面 Chrome UA 而不是 Googlebot，跟随跳转。在投递 HTML 里找 <script type="speculationrules"> 块并按 JSON 解析，在响应头里找 Speculation-Rules。另外单独数了 <link rel> 提示：preload、preconnect、dns-prefetch、modulepreload。

# 在你自己的页面上读同样两处
curl -sL -A 'Mozilla/5.0' https://example.com/ > page.html
grep -o 'type="speculationrules"' page.html | wc -l
grep -oiE '<link [^>]*rel="(preload|preconnect|dns-prefetch)"' page.html | wc -l

最要紧的那条局限正好卡在这里。我们不执行 JavaScript，而 Chrome 文档写明规则「can be statically included in the page's HTML or dynamically inserted into the page by JavaScript」—— 所以在运行时才插规则的站，这一遍全部记成零，真实数字高于 2，高多少我们测不出来。另外只测了首页、每站一次，也没有测任何一次预取到底让跳转快了多少。

那段 speculation rules 多半不是站长自己写的

两个站、两段规则，382 字节和 375 字节。除了主题目录名，两段是同一条规则。

下面是 arstechnica.com 那一段，只重排了换行，内容一字未改：

{"prefetch": [{
  "source": "document",
  "where": {"and": [
    {"href_matches": "/*"},
    {"not": {"href_matches": [
      "/wp/wp-*.php", "/wp/wp-admin/*", "/wp-content/uploads/*",
      "/wp-content/*", "/wp-content/plugins/*",
      "/wp-content/themes/ars-v9/*", "/*\?(.+)"]}},
    {"not": {"selector_matches": "a[rel~=\"nofollow\"]"}},
    {"not": {"selector_matches": ".no-prefetch, .no-prefetch a"}}
  ]},
  "eagerness": "conservative"
}]}

techcrunch.com 发的是同一套结构，把路径换成 /wp-*.php 和 /wp-content/themes/tc-24/*。两段都排除了后台路由、上传目录、插件与主题目录、带搜索串的链接、标了 nofollow 的链接，以及任何放在 .no-prefetch 容器里的东西。

这两段和 WordPress 默认值逐项一致

WordPress 内核团队在这个特性上线时把默认值写清楚了：「WordPress 6.8 introduces speculative loading, which can lead to near-instant page load times by loading URLs before the user navigates to them」，以及「The default of prefetch with conservative eagerness is used as a reasonable starting point to enable speculative loading at the scale of WordPress」（Speculative Loading in 6.8，2025-03-06 发布，2026-09-03 访问）。同一篇还提到带搜索串的 URL 会被自动排除。

这两段规则在我们能核对的每个轴上都和这段描述一致：动作、source、eagerness、自动排除。我们没法证明两个站都没动过那个 filter。能说的是：两段里没有一处和上线时的默认值不同，各自唯一的站点特征串就是自己的主题目录名。

这类采用率数出来的往往是一次 CMS 版本发布，不是二十七个决定。

整个面板没有一个站在做 prerender

两段规则用的都是 prefetch。Chrome 文档把两种动作的差别写得很清楚：被 prefetch 的文档「processed in the same way that navigations are (but then not rendered) and are held in memory」，而 prerender 的页面「behaves as if the page has been opened in an invisible background tab」（Speculative loading，2026-09-03 访问）。让点击真正变成瞬开的是后者，而这里没有一个站用它。

eagerness 的取值解释了一部分谨慎。Chrome 对两个站都选的那一档只写了一句：「Conservative: This speculates on pointer or touch down.」读者只是把目光落在链接上时，什么都不会被取。

那两个名字里还有第二条线索：它们都是新闻站。这个面板上做框架和做托管的九个首页 —— nextjs.org、vercel.com、astro.build、www.netlify.com、railway.com、supabase.com、linear.app、webflow.com、www.framer.com —— 一个都没有带 speculation rules 规则块，而这九家卖的正是框架、建站工具或托管。

这对你意味着什么

这是个体验特性，不是搜索特性。它改变的是一个已经进站的人看到第二个页面的快慢，不改变你被怎么抓取，这份数据里也没有任何排名信息。

1. 用 WordPress 6.8 以上的，先看看自己是不是已经在发。这里两个站都在发，而规则里写着自己的主题目录名 —— 这算一处自曝，值得读一遍，同一类读法在 x-powered-by 实测 27 个首页 里。
2. 要自己写规则，就从 prefetch 加 conservative 起步。这是两个生产站实际在跑的组合，也是在没人点的链接上浪费最少带宽的那一档。
3. 别在一个没量过的页面上加规则。那套老提示在 27 个站里的 20 个上解决的是另一个问题，把新机制叠在一次很慢的首字节上，什么也动不了。

那套老提示各家用到什么程度，量在 资源提示实测 27 个首页；这些提速工作到底能不能传到排名上，写在 页面速度到底影不影响排名。想看自己的页面在任何脚本运行之前投递了什么 HTML，可以 看看 QueryWin 是怎么读一个页面的。

常见问题

你们是怎么测的

2026-09-03 当天，30 个首页各发一次 GET，桌面 Chrome UA，跟随跳转，正文全部落盘。规则块按 type 属性找出来再按 JSON 解析，link 提示用正则数。全程不执行 JavaScript，所以运行时插入的规则在这里看不见。出口在日本大阪。

页面里那段 speculationrules 是谁加的

先看它排除了哪些路径。这两个站的规则里都写着 /wp-admin/* 和自己的主题目录，那是 CMS 生成的形状；手写的规则通常只针对几条具体链接，不会去枚举后台路径。

2 / 27 是真实采用率吗

不是，真实的那个我们也给不出来。它是个下限。加载后由脚本插入的规则不会出现在静态抓取里，而这个面板是 27 个首页，不是全网抽样。

预取对 SEO 有帮助吗

这里没有任何证据说有。这份测量完全不含排名数据。预取影响的是读者已经进站之后的那一次跳转。

要不要直接上 prerender

它是两种里更强的那个，也是能让点击瞬开的那个，而这个面板上零个站选了它。这说明的是大家怎么看待它的风险，不是一条推荐 —— 两种设置各自会浪费掉多少工作，我们没测。