即时导航：如何使用 Speculation Rules API 实现接近零的加载时间
发布: (2026年1月8日 GMT+8 02:41)
7 min read
原文: Dev.to
Source: Dev.to
请提供您希望翻译的完整文本内容，我将为您翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。谢谢！
为什么页面加载仍然感觉慢
不管你优化得多好，都有一个硬性限制：页面只能在用户点击之后开始加载。
你仍然要等待 DNS 查询、服务器响应和渲染——即使在一个快速站点上，也会有数百毫秒的等待。
如果浏览器能够预测用户下一步要去的页面，并在他们点击之前就开始加载该页面，会怎样？
这正是 Chrome 的 Speculation Rules API 所做的。使用它，你可以实现 0 ms 的加载时间——页面会直接出现。
两种策略
| 策略 | 功能 | 适用场景 |
|---|---|---|
| Prefetch | 只下载 HTML 文档。当用户点击时，浏览器已有初始加载，但仍需获取 CSS、JS 和图片。 | 资源占用低，适合对可能访问的页面进行“预热”。 |
| Prerender | 在隐藏的后台标签页中加载所有内容，执行 JavaScript 并渲染完整页面。当用户点击时，浏览器直接切换标签页——瞬间完成，无加载画面。 | 速度最高，适用于高置信度的预测。 |
注意： 该 API 替代了旧的 “ 标签（因隐私原因已弃用）。新 API 更智能，提供了更多控制。
即使 Lighthouse 得分完美，也不能保证站点感觉快速。即使是优化过的页面仍需 DNS 查询、TCP 握手、TLS 协商、服务器响应以及渲染——至少需要数百毫秒。
投机规则通过在用户决策期间工作来消除感知等待时间。 当用户将鼠标悬停在链接上 200 ms 时，你可以利用这段时间预加载或预渲染目标页面。等他们点击时，工作已经完成。
好处
- 页面之间零白屏
- 交互瞬时（JS 已解析并执行）
- 更好的 Core Web Vitals —— 对于 prerendered 页面，LCP 常常达到 0 ms
- 潜在收入提升——体验如同魔法般
实际示例
1. 当用户开始点击时进行预渲染（资源浪费最小）
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "href_matches": "/*\\?*(^|&)add-to-cart=*" } }
]
},
"eagerness": "conservative"
}]
}2. 200 ms 悬停时预渲染 – 在性能和资源成本之间取得平衡
(这是 Google Search 对前两条结果之外的策略。)
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } }
]
},
"eagerness": "moderate"
}]
}3. 两层策略：页面加载时进行积极预取 + 悬停时进行适度预渲染
{
"prefetch": [{
"urls": ["/products", "/pricing", "/docs"],
"eagerness": "eager"
}],
"prerender": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}4. 对外部链接进行预取并提供隐私保护
{
"prefetch": [{
"urls": [
"https://example.com/article",
"https://partner-site.com/page"
],
"requires": ["anonymous-client-ip-when-cross-origin"],
"referrer_policy": "no-referrer"
}]
}5. 按 CSS 类定位链接
{
"prerender": [{
"where": { "selector_matches": ".prerender-this" },
"eagerness": "eager"
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch-this" },
"eagerness": "moderate"
}]
}急切度设置
| 设置 | 触发时机 | 典型用法 |
|---|---|---|
| 保守 | pointerdown（mousedown / touchstart） | 最小浪费，最小收益 – 安全的起点 |
| 适中 | 桌面：200 ms 悬停或 pointerdown移动端：视口启发式 | 推荐用于大多数站点；Google 搜索使用 |
| 积极 | 桌面上 10 ms 悬停（Chrome 141+） | 激进但仍由用户发起；适用于高流量页面 |
| 立即 | 规则加载后立即 | 如果用户不点击会产生大量浪费；仅在非常有信心的预测时使用（例如分页、主要 CTA） |
Speculation Rules API 是 仅限 Chromium，但作为渐进增强工作——不支持的浏览器会直接忽略 “ 标签。
浏览器支持
| 浏览器 | 支持 | 备注 |
|---|---|---|
| Chrome / Edge | ✅ 完整 | 自 Chrome 109 / Edge 109 起支持（2023 年 1 月） |
| Brave / Opera | ✅ 完整 | 通过 Chromium 引擎实现完整支持 |
| Safari | 🟡 需要开启标志 | 在 Safari 26.2 及以上可用，需要开启标志（默认未启用） |
| Firefox | ❌ 不支持 | 当前不支持 Speculation Rules API |
资源与隐私保护
- 资源限制 – Chrome 限制并发预渲染：最多 50 个即时/积极预取（移动端），10 个预渲染，以及 2 个中等/保守预渲染（FIFO）。达到上限时，较旧的预渲染会被取消。
- 延迟 API – 侵入式 API（摄像头、麦克风、通知、地理位置）在用户实际查看页面之前保持休眠状态。
- 尊重用户设置 – 如果用户启用了数据节省、节能模式，或在设置中关闭了“预加载页面”，则不会进行预渲染。
- 跨源 iframe – 第三方 iframe 在预渲染期间不会加载；它们会等到激活时才加载，从而防止跟踪并减少资源浪费。
最终思考
说实话，我很惊讶之前竟然没有听说过这件事。既然所有主流 Chromium 浏览器都已支持该 API，确实值得使用。我们常常会被复杂的性能优化所牵绊，而忽视了更简单的收益——比如用于 SEO 的语义化 HTML，或是性能优于庞大框架的原生 CSS。
Speculation Rules API 正好属于这一类：强大、直接、且内建于平台。我迫不及待想继续对它进行实验！
e how far it can go.
- 在 Chrome 中预渲染页面 – 完整 API 参考
- 复杂站点的实现指南 – 高级模式和最佳实践
- 调试 speculation rules – DevTools 指南
- Google Search 如何使用 speculation rules – 实际实现与结果
- MDN: Speculation Rules API – Web 标准文档