WordPress 6.8 引入了一个新功能，叫做推测性加载（Speculative Loading）。这个功能可以在用户点击链接之前，提前加载页面内容，从而实现几乎瞬间的页面加载速度。它依赖于 Speculation Rules API，这是一个 Web 平台的功能，允许开发者定义规则，决定哪些 URL 应该被预取或预渲染，以及提前多久进行这些操作。如果你想了解更多关于 Speculation Rules API 的信息，可以查看 推测性加载公告文章。
背景
在 WordPress 核心引入这个功能之前，它已经通过 Speculative Loading 功能插件 在超过 50,000 个 WordPress 站点上成功使用了。现在，这个插件被移植到了 WordPress 核心中，并做了一些调整。根据从 HTTP Archive 和 Chrome 用户体验报告（CrUX）数据集中收集的数据，启用推测性加载的站点，其 最大内容绘制（LCP） 通过率中位数提高了约 1.9%。虽然这个数字看起来不大，但对于一个单一功能来说，这是一个非常显著的提升，尤其是考虑到这些数据来自各种性能表现不同的站点。
Speculation Rules API 在 2023 年初首次推出，之后使用率一直在增长。如今，超过 8% 的 Chrome 导航依赖于 Speculation Rules。几个月前，Cloudflare 通过其 Speed Brain 功能大规模启用了推测性加载，这也是一个重要的里程碑。目前，Speculation Rules API 在 Chrome、Edge 和 Opera 中得到支持，这意味着绝大多数用户都可以享受到它的好处。对于不支持该 API 的浏览器，推测性加载不会产生任何负面影响，因为它是一种渐进增强功能。不支持该 API 的浏览器会直接忽略它，站点会保持原有的行为。
默认行为与自定义
WordPress 核心在所有站点的前端默认启用了推测性加载，除非用户已登录或站点禁用了漂亮的永久链接（pretty permalinks）。URL 的预取行为是保守的：这意味着当用户开始点击链接时，才会触发预取。虽然这通常只是在实际导航发生前的几分之一秒，但这仍然足以带来显著的性能提升。这种默认的保守预取行为是 WordPress 大规模启用推测性加载的合理起点。它与 Cloudflare 在其推测性加载功能中使用的配置一致，并最大限度地减少了在没有后续导航的情况下进行推测性加载的可能性。
Speculative Loading 插件默认使用中等积极性的预渲染，这由于推测性加载更早触发以及预渲染 URL 而带来了更大的性能提升，但也存在一些权衡，例如即使用户最终没有导航到该 URL，某些客户端行为也可能被无意中触发。
通过操作和过滤器进行自定义
从推测性加载中排除 URL 模式
当 URL 被预取时，服务器响应会在用户导航到该 URL 之前加载。在大多数情况下，这不是问题，因为前端 URL 的服务器响应通常不会改变站点的状态。然而，某些插件可能使用所谓的“操作 URL”模式，即仅通过导航到特定 URL（使用 GET 请求）就会发生状态更改——例如，在电子商务 WordPress 站点上，可能是将产品添加到购物车或将商品标记为收藏。值得注意的是，这是一种反模式，因为状态更改通常应该仅由 POST 请求触发，例如通过表单提交，而 GET 请求应该是“幂等”的。尽管如此，使用这种模式的插件应确保此类 URL 被排除在预取和预渲染之外。在保守积极性的情况下，这应该不是问题，因为几乎可以保证用户也会导航到该 URL。但对于使用更积极配置的站点，导航可能永远不会发生，这就是为什么排除此类 URL 很重要。
默认情况下，任何包含查询参数的 URL 都会自动从预取和预渲染中排除，这应该可以满足大多数此类操作 URL 的需求。然而，如果插件为这些 URL 实现了自己的重写规则而不是使用自定义查询参数，它们可以使用 wp_speculation_rules_href_exclude_paths 过滤器来提供要排除的 URL 模式。以下示例确保任何路径以 /cart/ 开头的 URL 都将被排除在推测性加载之外，无论是预取还是预渲染：
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $href_exclude_paths ) {
$href_exclude_paths[] = '/cart/*';
return $href_exclude_paths;
});所有提供的 URL 模式都应遵循 URL Pattern Web 规范，并且它们都将被视为相对于站点的前端。对于主页 URL 位于子目录中的站点，WordPress 会自动添加相应的路径段，因此插件开发者无需担心这一点。
虽然 WordPress 核心的默认行为是预取 URL，但站点可以选择预渲染 URL。这会带来显著的性能提升，但也对推测性加载的 URL 有额外的影响，因为它们的客户端代码也会被加载。如果站点包含任何仅在用户实际导航到 URL 时才应运行的客户端逻辑，则需要首先检查站点是否正在被预渲染，并仅在导航发生后触发此类逻辑（请参阅 “在 JavaScript 中检测预渲染”文档）。一个常见的用例是分析工具（请参阅 “对分析的影响”文档）。许多流行的提供商已经支持预渲染，因此无需更改。但如果你的站点或插件在某些 URL 上包含此类功能，并且你尚未更新 JavaScript 逻辑以支持预渲染，你可以暂时将相关 URL 从预渲染中排除。以下示例确保任何路径以 /personalized-area/ 开头的 URL 仅被排除在预渲染推测性加载之外：
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $href_exclude_paths, $mode ) {
if ( 'prerender' === $mode ) {
$href_exclude_paths[] = '/personalized-area/*';
}
return $href_exclude_paths;
}, 10, 2);修改默认的推测性加载配置
如前所述，WordPress 站点能够修改默认的推测性加载配置。为了进一步提高性能，你可能希望配置更具积极性或利用预渲染。这可以通过 wp_speculation_rules_configuration 过滤器实现，该过滤器接收一个包含 mode 和 eagerness 键的关联数组来控制配置，或者接收 null 以禁用当前请求的推测性加载。该过滤器的默认值为 array( 'mode' => 'auto', 'eagerness' => 'auto' )，除非用户已登录或站点禁用了漂亮的永久链接，在这种情况下，默认值为 null。对于这两个配置参数，auto 值表示 WordPress 核心将决定配置，截至今天，这实际上会导致 mode 为 prefetch，eagerness 为 conservative。根据 Speculation Rules API 和生态系统支持的状态等各种标准，行为可能会在未来的 WordPress 版本中发生变化。
以下示例使用过滤器将积极性提高到 moderate。这将提高性能优势，同时增加没有后续导航的推测性加载的权衡：
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
if ( is_array( $config ) ) {
$config['eagerness'] = 'moderate';
}
return $config;
});mode 值可以是 auto、prefetch 或 prerender，eagerness 值可以是 auto、conservative、moderate 或 eager。Speculation Rules API 还定义了另一个 eagerness 值 immediate，但强烈不建议将其用于推测性加载任何 URL 的文档级规则，因此 WordPress 核心 API 不允许将其用于其整体配置。
如果你希望获得更大的性能提升，以下示例使用过滤器选择 prerender 和 moderate 积极性。这与 Speculative Loading 功能插件的实现类似，可以带来显著的性能提升。在启用预渲染之前，请务必考虑上一节中解释的预渲染对客户端 JavaScript 逻辑的影响。
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
if ( is_array( $config ) ) {
$config['mode'] = 'prerender';
$config['eagerness'] = 'moderate';
}
return $config;
});如前所述，对于不使用漂亮永久链接的站点，默认情况下禁用推测性加载。这是因为如果 WordPress 核心的参数也使用查询参数，那么上述排除带有查询参数的 URL 的规则将不再可靠地适用。然而，在某些情况下，作为没有漂亮永久链接的站点所有者，你可能确信你的站点没有使用任何导致此排除的问题模式，或者你已经识别出它们并明确排除了带有特定查询参数的 URL 被推测性加载。在这种情况下，你可以使用过滤器启用推测性加载，如下所示：
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
if ( ! $config && ! get_option( 'permalink_structure' ) ) {
$config = array( 'mode' => 'auto', 'eagerness' => 'auto' );
}
return $config;
});请谨慎选择启用推测性加载。WordPress 核心的默认设置经过仔细考虑，以安全的方式满足大多数站点的需求，因此只有在确信不会对你的站点产生不利影响的情况下才使用此代码片段。
包含额外的推测规则
Speculation Rules API 允许定义多个规则来配置浏览器应如何推测性加载 URL。默认情况下，WordPress 核心仅包含一个处理上述所有行为的规则。通过提供全新的推测规则，可以在核心的主规则之上实现更高级的自定义，这可以通过使用 wp_load_speculation_rules 操作来实现。该操作接收一个新的 WP_Speculation_Rules 类的实例，该类内置了验证机制，可以根据需要进行修改。通过添加新规则，你可以实现完全自定义的配置，这些配置将应用于 WordPress 核心的主规则之上。
以下示例与前面的示例直接相关，该示例将默认配置更改为 prerender 和 moderate 积极性。你可能不希望更改默认配置，但可能在某些特定 URL 上希望启用 prerender 和 moderate 积极性。你可以为此添加自定义的 URL 级推测规则：
add_action( 'wp_load_speculation_rules', function ( WP_Speculation_Rules $speculation_rules ) {
$speculation_rules->add_rule( 'prerender', 'my-moderate-prerender-url-rule', array(
'source' => 'list',
'urls' => array(
'/some-url/',
'/another-url/',
'/yet-another-url/',
),
'eagerness' => 'moderate',
) );
} );进一步扩展这个示例，可能没有简单的方法来提供 URL 列表，例如在 URL 经常更改或需要定期添加更多 URL 的情况下。在这种情况下，你可以考虑使用文档级推测规则，该规则适用于所有标记有特定类的链接，或者父元素具有特定类的链接：
add_action( 'wp_load_speculation_rules', function ( WP_Speculation_Rules $speculation_rules ) {
$speculation_rules->add_rule( 'prerender', 'my-moderate-prerender-optin-rule', array(
'source' => 'document',
'where' => array(
'selector_matches' => '.moderate-prerender, .moderate-prerender a',
),
'eagerness' => 'moderate',
) );
} );有了这个规则，用户可以将 moderate-prerender 类添加到任何支持添加类的块中，这样他们就可以手动按需选择任何链接。有关规则定义的具体内容，请参阅 Speculation Rules API 规范。
通过 UI 进行自定义
前面的示例已经暗示了如何通过 UI 自定义推测性加载。虽然像 Speculative Loading 功能插件中存在的专用 UI 超出了 WordPress 核心的范围，但许多块类型在块侧边栏的“高级”面板中提供了“附加 CSS 类”字段。WordPress 核心内置了对 CSS 类 no-prefetch 和 no-prerender 的支持。你可以将这些类添加到任何块中，以便该块内的链接分别选择退出预取或预渲染。请注意，no-prefetch 选择退出两者，即完全选择退出推测性加载，因为预取是预渲染的一部分。有关何时可能有用从预取或预渲染中排除 URL 的指导，请参阅排除 URL 模式的部分。这种机制使高级用户可以轻松地对特定块的推测性加载进行精细控制。
总结与进一步阅读
WordPress 6.8 中的推测性加载功能是 WordPress 和整个 Web 性能的一大胜利，它甚至在用户导航发生之前就开始了页面加载过程。通过根据你的站点需求进一步微调它，你可以实现比默认配置更大的性能提升。请参阅以下链接以获取更多信息：
- 阅读 Trac #62503 和 changeset [59837] 以获取有关核心实现的更多背景和讨论。
