周涛博客在进行网页性能优化的时候，使用预加载是提高站内导航的注意方法，其本质都是让浏览器 “提前动手”，把用户可能访问的页面准备好，实现点击链接时 “即时响应”
WordPress 在 6.8 版本的时候已将 推测规则 API（Speculation Rules API） 功能内置为核心特性，让全球数百万 WP 站点无需复杂开发，就能直接享受这一性能优化方案。
传统预加载方案：能用但限制多
早期为了优化多页面应用（MPA）的导航体验，浏览器推出了两类核心预加载方案，但在 WordPress 生态中暴露出诸多不适配问题：
1. prefetch（预获取）：
通过 声明，让浏览器提前下载目标页面的 HTML 文档主体，存储到缓存中。
特点是资源消耗低，但仅能加载 HTML，JS、CSS、图片等子资源需等待用户实际点击后才会加载。
但是在 WordPress 站点中易被 Cache-Control 缓存规则拦截，且不支持跨站场景，对于依赖多插件、多页面导航的站点来说，优化效果有限。
2. prerender（预渲染）：
通过声明，让浏览器在 “隐藏标签页” 中完整加载目标页面 ，包括所有子资源、执行 JS、渲染 DOM/CSS。
特点是体验极致，点击即展示，但资源消耗极高，相当于提前开了一个隐形页面。
但是该功能长期是 Chrome 私有特性，不兼容 Firefox、Safari，而 WordPress 站点用户浏览器分布广泛；且无法动态适配设备状态（如省电模式下仍全速预渲染），容易导致移动端用户流量浪费。
传统方案的共同短板
动态触发缺失：仅支持 “静态声明”，无法根据用户行为（如鼠标悬停链接）动态触发，易出现 “预加载了用户没点” 的无效消耗，不适配 WordPress 站点的高频交互场景；
配置维护繁琐：每一个预加载页面都需手动或通过程序添加单独 标签，WordPress 站点的导航栏、分类页等大量链接需重复配置，后续路径调整或新增链接时，维护工作量巨大。
推测规则 API：标准化的预加载接口
为解决传统方案的痛点，W3C 标准化的 推测规则 API（Speculation Rules API） 应运而生，而 WordPress 6.8 已将其深度整合进核心，成为 WordPress 站点的 “性能优化标配”。
该 API 专为多页面应用（MPA）设计，它摒弃了传统 “一个页面一个标签” 的零散配置方式，改用JSON 格式的声明式规则，只需一段代码就能批量定义所有预加载策略，让开发者能精准告诉浏览器：哪些页面需要预处理、用哪种方式处理、在什么条件下触发。
与负责图片、CSS 等资源的 link rel="preload" 不同，推测规则 API 是 “文档级预加载标准”，专注解决 “页面导航” 的性能问题，同时大幅降低配置和维护成本。数据显示，启用该功能的 WordPress 站点，中位数 LCP（最大内容绘制）通过率提升约 1.9%，对单一性能特性而言是显著突破。
规则配置方式
推测规则可通过内联的标签:
<script type="speculationrules">或 Speculation-Rules 响应标头引用的外部文本文件定义，适配不同开发场景。
1. 内联脚本配置（推荐，适合页面级定制）：
<script type="speculationrules">
{
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "href_matches": "/*\\?*(^|&)add-to-cart=*" } },
{ "not": { "selector_matches": ".no-prerender" } },
{ "not": { "selector_matches": "[rel~=nofollow]" } }
]
}
}
],
"prefetch": [
{
"urls": ["next.html", "next2.html"],
"requires": ["anonymous-client-ip-when-cross-origin"],
"referrer_policy": "no-referrer"
}
]
}
</script>2. HTTP 标头配置（适合 WordPress 全站统一规则）
在服务器响应头中添加 Speculation-Rules，传递 JSON 字符串，实现全站规则统一：
Speculation-Rules: "/rules/prefetch.json"
注：包含推测规则 JSON 的文本资源可以使用任意有效的命名和扩展名，但必须以 application/speculationrules+json MIME 类型来提供，WordPress 站点可通过插件或主题函数.php 配置该响应头。
配置验证方法
配置成功之后，在 Chrome 浏览器，按 F12 打开开发者模式之后，在「应用」标签的「推测规则」中就可以看到：
这时候在页面上触发某个链接，在「网络」就可以看到有多一条请求，类型是 prefetch：
查看其请求头有「Sec-Purpose: prefetch 」：
出现这条，就代表预加载已经真正生效，大家也可以在我博客上试试。
核心预处理模式
推测规则 API 延续了 prefetch 和 prerender 的核心逻辑，但做了标准化升级，预处理请求会携带 Sec-Purpose: prefetch 或 Sec-Purpose: prerender 请求头，服务器可据此返回轻量化内容（如预获取时不加载广告 JS、统计代码）：
prefetch（预获取）
资源消耗低，提前下载目标页面的 HTML 文档主体，存储在专用内存缓存，不加载子资源；用户点击时，直接复用缓存的 HTML，再加载子资源。
适用于导航栏链接、首页推荐文章、分类页等中概率访问页面，不受 Cache-Control 缓存规则拦截；支持跨站无 Cookie 预获取；可批量配置 URL。
prerender（预渲染）
在不可见的 “隐形标签页” 中，完整加载目标页面（含所有子资源、执行 JS、渲染 DOM/CSS）；用户点击时，直接激活该标签页，实现 “零延迟”。
适用于电商结算页、分页 “下一页”、登录后的首页等极高概率访问页面，跨源预渲染需目标服务器通过 Permissions-Policy: prerender=* 授权；支持动态行为触发；可批量配置 URL。
触发时机
开发者通过设置 eagerness 值，告知浏览器 “何时触发预加载”，帮助浏览器根据用户行为信号（如 hover、点击）和资源状况（如省电模式）智能决策，避免无效预加载导致的带宽 / 内存浪费，同时确保高优先级页面的预加载效果。
1. immediate（触发时机：立即）：
规则解析后立即启动，无需用户行为，仅受设备资源限制；WordPress 底层代码不允许将其用于全局配置，避免无差别预加载导致资源浪费。
2. eager（触发时机：积极）：
检测到轻微用户行为即触发（鼠标靠近链接、短暂 hover 等）；适合电商类 WordPress 站点，比如批量预加载产品列表页链接。
3. moderate（触发时机：适度）：
明确用户意向时触发（链接进入视窗 + hover 一段时间）；适合博客类站点的文章列表页，平衡优化效果与资源消耗。
4. conservative（触发时机：保守）：
用户点击瞬间触发（mousedown/pointerdown 事件）；加上 prefetc（prefetch+conservative），这也是 WordPress 默认配置， 与 Cloudflare “Speed Brain” 配置一致，最小化无效预加载风险，且用户登录或未启用固定链接时，默认禁用该功能，避免冲突。
浏览器支持与使用建议
浏览器兼容（2026 年最新），Speculation Rules API 已脱离纯实验阶段，进入主流浏览器逐步适配期，核心支持情况如下，适合作为 “渐进式增强” 功能使用：
完全支持（可生产使用）：Chrome 113+、Edge 113+（桌面端、移动端均支持），这两大浏览器占据全球主流市场份额，是目前该 API 的核心落地场景。
实验性支持（仅测试用）：Firefox Nightly 版本（需手动开启 dom.speculation_rules.enabled 开关），尚未进入稳定版。
暂未支持：Safari（WebKit 内核已将其纳入开发计划，暂无正式支持时间表）。
总结一下
推测规则 API 不仅解决了传统预加载 “配置繁琐、兼容性差” 的通用痛点，更通过和 WordPress 的深度整合，成为 WordPress 站点的 “性能优化利器”—— 既无需复杂开发，又能通过灵活的钩子和 UI 配置适配不同场景，平衡导航速度与业务安全。
对于 WordPresss 站长来说，这是一项 “零成本、高回报” 的性能优化方案，无论是个人博客还是企业站点，都能通过它让站内导航快到 “无感”。
评论前必须登录！
注册