使用 Speculation Rules 实现页面即时加载

了解如何通过新的 Speculation Rules API 实现页面即时加载来改善 Core Web Vitals

Arjen Karel - linkedin

Last update: 2026-02-07

使用 'Speculation Rules API' 即时改善 Core Web Vitals

是否好奇为什么有些页面似乎能够即时加载？这很可能是因为该页面实现了 Speculation Rules！

Speculation Rules API 通过 prefetching 甚至 prerendering 来提升多页面应用（MPA）中未来页面加载的速度。开发者可以配置 speculation rules 来建议浏览器 prefetch 或 prerender 文档，以实现更快（或即时）的页面加载。 Speculation rules 取代了旧的技术，例如用于 prefetching 资源的 `<link rel="prefetch">` 或已弃用的 Chrome 专有功能 `<link rel="prerender">`。

Speculation rules 在文档级别工作，使其适用于涉及完整页面导航的 MPA。主要使用 API 调用或部分内容更新的单页面应用（SPA）在其内部路由变化方面不会从该 API 中获得太多收益。然而，Speculation Rules 仍然可以通过从着陆页 prerendering 应用的初始状态来使 SPA 受益，从而可能抵消初始加载时间。

Table of Contents!

使用 'Speculation Rules API' 即时改善 Core Web Vitals
Speculation Rules 快速入门
Speculation Rules 的优势
Prefetch 还是 Prerender
设置合适的 'Eagerness' - 平衡之道
检查和调试 speculation rules
- 监控和分析 Speculation Rules
注意事项 - 不利因素
Speculation Rules WordPress 代码

Speculation Rules 快速入门

已经了解 speculation rules 是什么了吗？太好了！这里有一些现成的代码片段供您立即开始使用。只需选择适合您的代码片段并将其放置在页面的 <head> 中（可以随意将 preload 更改为 prefetch 以及/或者更改 eagerness）！

<!-- 
   corewebvitals.io 的 WordPress speculation rules 
   prefetch 所有内部链接
   跳过匹配 wp-login、wp-admin、wp content 的链接 
   跳过具有 nofollow 属性的链接
   跳过具有查询字符串的链接，例如：/search->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "and": [{ "href_matches": "\/*"},{ "not": {     "href_matches": [         "\/wp-login.php",         "\/wp-admin\/*",         "\/*\\?*",         "\/wp-content\/*",     ] }
                },{ "not": {     "selector_matches": "a[rel~=\\"nofollow\\"]" }
                }]
        },
        "eagerness": "moderate"
    }]
}
</script>

<!-- corewebvitals.io 的 Data-preload 触发 speculation rules -->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "selector_matches": "a[data-preload]"
        },
        "eagerness": "moderate"
    }]
}
</script>

提示：如果您需要快速构建自己的 speculation rules，不妨试试 speculation rules 生成器

Speculation Rules 的优势

改善 user experience (UX)：通过预测和预加载内容，Speculation Rules 确保 近乎即时的页面加载，使用户的导航体验流畅无缝。这使传统多页面网站在不依赖复杂性和 JavaScript 的情况下也能媲美单页面应用的性能。更快的加载时间意味着更好的浏览体验，有可能增加用户参与度并降低跳出率。

SEO 优势：由于页面速度的提升是直接的排名因素，更好的 Time to First Byte 将带来更好的 Largest Contentful Paint，实施 speculation rules 必将改善 Core Web Vitals 并为您带来页面速度方面的优势。

降低复杂性：过去，要实现近乎即时的页面加载，需要使用 SPA 或为 MPA 编写自定义的 prefetch 逻辑。
对于许多场景来说，SPA 的缺点在于初始启动时间，由于严重依赖 JavaScript 且与 MPA 相比复杂度更高，启动时间可能相当可观。Speculation rules 没有这些问题。这使得更广泛的网站，尤其是内容型网站，能够实现快速加载。
该 API 还通过将大部分逻辑委托给浏览器来简化决定哪些页面需要 prerender 的过程。这是对之前依赖 JavaScript 来进行这些检查并注入要 preload 的页面的方法的巨大改进。浏览器可以在决定是否 prerender 时原生地考虑用户上下文，例如移动设备上的低内存或省电模式。这种动态适配有助于节约用户资源，并确保即使在受限条件下也能提供流畅的体验。

其他优势：Speculation-Rules HTTP header 允许通过内容分发网络（CDN）更轻松地部署，无需直接修改文档内容。Document Rules 的精细控制允许开发者根据 URL 模式或 CSS 选择器定义精确的 prefetching 或 prerendering 条件。这减少了手动 URL 指定，并允许站点范围的 speculation 规则集。"eagerness" 设置提供了对何时进行 speculation 的细粒度控制，在预加载速度和资源消耗之间取得平衡。这有助于减少不必要的预加载并防止资源浪费。

Speculation Rules 工作原理

Speculation rules 使用 JSON 结构定义，可以通过两种方式实现：

内联脚本：将 JSON 包含在 `<script type="speculationrules">` 标签中，放置在主 HTML 文档的 `<head>` 或 `<body>` 中。
HTTP Header：使用文档响应中的 `Speculation-Rules` HTTP header 来传递规则。该 header 指向包含规则的 JSON 文件，便于 CDN 部署而无需直接修改 HTML 内容。

JSON 结构使用 "prefetch" 和 "prerender" 数组来包含每种推测加载类型的规则。每个规则可以使用不同的来源：URL 列表或 document rules

urls（URL 列表）一个要 prefetch 或 prerender 的 URL 数组。
where（document rules）一个使用条件来确定页面上哪些链接应被 prefetch 或 prerender 的对象。

每个规则定义为一个对象，包含以下属性：

requires 一个字符串数组，用于设置 speculation 的限制。目前，唯一有效的字符串是 "anonymous-client-ip-when-cross-origin"，表示跨域 prefetch 应该匿名化客户端的 IP 地址。
target_hint 一个字符串，提供关于可导航目标名称的提示，允许用户代理优化加载过程。除了作为提示之外，没有任何规范性含义。
referrer_policy 应用于 prefetch 或 prerender URL 的引荐来源策略。
relative_to（仅适用于 "list" 来源）指定 "urls" 数组中提供的 URL 是相对于文档的 base URL（"document"）还是 speculation rules JSON 文件的位置（"ruleset"）。
eagerness 控制浏览器 prefetch 或 prerender 的积极程度。可用的设置有 "immediate"、"eager"、"moderate" 和 "conservative"，各有不同的触发条件。
expects_no_vary_search 一个字符串，用于提供 URL 搜索差异提示，允许开发者指示推测的 URL 是否预期根据搜索参数具有不同的响应。

最后，每个规则都有一个 eagerness 设置，允许您定义何时运行 speculation，将何时进行 speculation 与对哪些 URL 进行 speculation 分离开来。eagerness 设置适用于 list 和 document 来源规则，有四个选项：immediate、eager、moderate 和 conservative。

immediate：用于尽快进行 speculation，一旦观察到 speculation rules 就立即执行。
eager：目前行为与 immediate 设置完全相同，但将来它将被定位在 immediate 和 moderate 之间。
moderate：当您将鼠标悬停在链接上 200 毫秒时执行 speculation（或在 pointerdown 事件更早触发时执行，以及在没有 hover 事件的移动设备上）。
conservative：在指针或触摸按下时进行 speculation。

Prefetch 还是 Prerender

Speculation Rules API 支持两种主要的推测加载形式： prefetching 和 prerendering。尽管两种技术都能带来更快的页面加载，但它们在复杂性和资源消耗方面有所不同。

Prefetching，是推测加载的"轻量级形式"。它下载并缓存目标 URL 的 HTML，而不渲染页面或其子资源。这种方法主要改善 Time To First Byte。改善的 Time to First Byte 将带来更好的绘制指标，如 Largest Contentful Paint 和 First Contentful Paint。
Prerendering 所做的远不止下载 HTML。它下载 HTML、所有子资源，并在隐藏的不可见标签页中渲染整个页面。当导航到该页面时，将产生近乎瞬时的显示效果。这种技术不仅通过改善 Time to First Byte 来提升 Largest Contentful Paint，还下载并渲染 LCP 元素。Prerendering 还可以消除 Cumulative Layout Shift，因为在 prerendering 后资源尺寸已经是已知的。

那么哪个更好？Prerendering 还是 Prefetching？这取决于页面和"普通访客"。虽然 prerendering 在设计上可能更快，但它也消耗更多资源，包括客户端和服务器端。prerendering 和 prefetching 的选择取决于：

用户的设备能力：如果大比例的访客使用内存有限的设备访问， Prerendering 可能不是最佳选择
Prerender 或 prefetch 规则的特定性。"某些链接更可能被点击，某些页面更可能产生转化"。这些页面是 prerender 规则的完美候选。其他页面可能更适合使用 prefetch。

CoreWebVitals.io 提醒应避免过度 prerendering，因为其资源需求较高，特别是在移动设备或较慢的网络连接上。 prerendering 的潜在收益必须与性能下降和资源浪费的风险进行权衡。

设置合适的 'Eagerness' - 平衡之道

使用哪个 eagerness 设置取决于您的网站。对于非常简单的静态网站，更积极地进行 speculation 可能成本很低且对用户有益。具有更复杂架构和更重页面 payload 的网站可能更倾向于通过减少 speculation 频率来减少浪费，直到获得用户更明确的意图信号。

Speculation Rules API 中的 eagerness 设置影响浏览器何时应基于预测的用户导航 prefetch 或 prerender 内容。该设置提供了在最大化预加载收益和最小化资源浪费之间的权衡。

list rules 的默认 eagerness 为 immediate。 moderate 和 conservative 选项可用于将 list rules 限制为用户在特定列表中交互的 URL。在许多情况下，带有适当 where 条件的 document rules 可能更为合适。

document rules 的默认 eagerness 为 conservative。鉴于一个文档可能包含许多 URL，对 document rules 使用 immediate 或 eager 应谨慎。

eagerness 的选择取决于网站的结构、用户行为模式以及开发者对潜在资源消耗与 user experience 收益的评估。例如，一个简单的静态网站可能从 "eager" 设置中受益，带来更快的加载时间。相反，具有复杂架构和高要求页面 payload 的网站可能选择较不激进的 "moderate" 或 "conservative" 方式，以限制资源使用，直到检测到更明确的用户意图。

在配置 eagerness 时，开发者应考虑 user experience、资源成本和浏览器限制。过度 speculation 可能会消耗用户的带宽、内存和 CPU，可能导致性能下降，尤其是在受限的网络或设备上。Chrome 对并发 prefetch 和 prerender 的页面数量实施了限制以缓解过度使用。此外，用户配置的 Data Saver 模式、低电量状态或浏览器扩展等因素可能会覆盖 speculation rules，优先考虑资源节约。

检查和调试 speculation rules

要检查页面上的任何 speculation rules，请打开 Chrome DevTools，转到 Application 面板，然后导航至 Background Services > Speculative Loads > Speculations。（在加载要调试的页面之前打开 Speculations 窗格）此面板提供以下信息：

成功的 speculation 数量。
正在被 prerender 或 prefetch 的各个 URL。
每个 speculation 的状态。

Performance 面板中的 Network 轨道显示与 prerender 资源相关的网络活动，无需切换 DevTools 上下文。此外，您可以将 DevTools 上下文切换到 prerender 页面，像检查普通页面一样检查它。

speculative loads inspector devtools

监控和分析 Speculation Rules

Real User Monitoring (RUM)：利用 RUM 工具衡量实际的 user experience。观察 Largest Contentful Paint (LCP) 等指标来评估 speculation rules 对页面加载时间的影响。寻找 prerender 页面与非 prerender 页面相比 LCP 的改善。
A/B Testing：进行 A/B 测试来比较不同的 speculation rule 配置，并为您的特定网站和用户群找到最优设置。

speculation rules rum tracking table coredash

注意事项 - 不利因素

资源消耗：过度使用 speculation 可能会对带宽、内存和 CPU 使用产生负面影响。

浏览器兼容性：并非所有浏览器都完全支持 Speculation Rules API，因此在实施前请检查浏览器兼容性。

隐私：开发者应注意 speculation rules 可能如何暴露用户浏览模式，并实施适当的隐私措施。

Speculation Rules API 提供了一种强大的方法来增强 Web 应用的性能和 user experience。通过理解其工作原理、优势和注意事项，开发者可以利用该 API 构建更快速、更具吸引力的网站。

Speculation Rules WordPress 代码

WordPress Core Performance 团队创建了一个 Speculation Rules 插件，使向任何 WordPress 网站添加 document rule 支持变得一键即可。该插件提供两组设置：

Speculation Mode：在 prefetch 和 prerender 之间选择。Prerendering 将比 prefetching 产生更快的加载时间。然而，对于交互式内容，prefetching 可能是更安全的选择。
Eagerness：选择 conservative（通常在点击时）、moderate（通常在悬停时）或 eager（在最轻微的提示时）之间。eagerness 设置决定了推测加载触发的速度。

Core Web Vitals 使用 Speculation Rules 实现页面即时加载