🚀 6 行 HTML，让应用瞬间“起飞”：Speculation Rules API 全解析

本篇依然来自于我们的《前端周刊》项目！

由团队成员 掘金安东尼 翻译，欢迎大家进群持续追踪全球最新前端资讯!!

原文：medium.com/@fireprogra...

过去几年，我们写前端应用时，动不动就加骨架屏、loading 动画、励志文案，生怕用户在等待中流失。可问题是：用户仍然讨厌等待。

Chromium 内置的 Speculation Rules API 给了一个更优雅的答案：只要写 6 行 HTML，浏览器就能提前预取（prefetch）、甚至预渲染（prerender）下一页。

结果就是：用户点下去的一瞬间，页面已经准备好了。

没有 hack，没有复杂框架，就是浏览器原生能力。

🔑 核心观点

Speculation Rules API 是声明式的

你只需用 JSON 写规则，告诉浏览器"哪些页面值得提前准备"，不用写一堆悬停/点击事件的黑魔法。浏览器会根据网络状况、CPU、设备电量来决定何时执行，比你凌晨 2 点写的自定义逻辑靠谱多了。
Prefetch 与 Prerender 的区别
- Prefetch：提前下载 HTML，便宜安全，就像把菜先切好。
- Prerender ：在后台完整跑一遍页面（脚本、数据都加载），就像把整顿饭做好盖在钟罩下。
  一旦用户点击，切换是"秒开"的。

三档"渴望值" (Eagerness)
- Conservative（保守）：强意图才触发（点下鼠标）。
- Moderate（默认）：中等信号触发（悬停）。
- Eager（急切）：弱信号也触发（链接出现在视口）。
  这决定了浏览器多早"下注"，相当于你的 CFO 在管带宽和 CPU 投资。
规则可以写死，也可以动态下发
- HTML 内联：直接 <script type="speculationrules">。
- HTTP Header：Speculation-Rules: /speculationrules.json，适合 CDN、A/B 测试。
注意护栏与坑点
- 预渲染会触发页面逻辑，副作用要避免。
- 登录态要准备好，否则预渲染会卡死。
- 数据上报、埋点要延迟到激活时执行，避免重复计数。
- 敏感信息不要提前暴露。
Chrome DevTools 已有支持

打开 Preloading 面板，就能看到哪些预取/预渲染生效，哪些被取消。

你会看到 Speculation Rules 条目、当前的 Prefetch/Prerender 尝试，以及任何被取消的原因（例如缺少标头、CPU 被限速、处于后台标签页等）。

可以加一个调试，只在 document.prerendering 为 true 时显示，当页面真正激活（触发 prerenderingchange）时消失。

css 复制代码

if ("prerendering" in document) {
  // 测试时的简易视觉标记
  const t = document.createElement("div");
  t.textContent = "(prerendered)";
  t.style.cssText =
    "position:fixed;inset:auto 8px 8px auto;background:#000;color:#fff;padding:4px 6px;font:12px monospace;z-index:99999;opacity:.7";
  document.body.appendChild(t);
  document.addEventListener("prerenderingchange", () => t.remove());
}

🛠️ 代码实战

最小可运行 Demo（6 行 HTML）：

xml 复制代码

<script type="speculationrules">
{
  "prerender": [{ "source": "document", "eagerness": "moderate" }]
}
</script>

更细粒度控制（只对结账页启用 eager 预渲染）：

xml 复制代码

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": { "href_matches": "/checkout" },
    "eagerness": "eager"
  }]
}
</script>

跨源页面想支持预渲染？目标服务需返回：

makefile 复制代码

Supports-Loading-Mode: credentialed-prerender

性能：不只是 Lighthouse 分数，而是真正减少了用户在页面间的 首次交互延迟。
业务：更少的"愤怒点击"，更高的结账完成率，更长的阅读时长。

简单说：页面"秒开"，就等于少一个流失点。

🤔 什么时候不要用？

页面初始化成本过高（Prerender 会浪费资源）。
页面有副作用（加载时改写数据库/状态）。
第三方脚本 fragile（后台加载就崩溃）。
这些场景用 Prefetch 就够了。

🎯 TL;DR 给程序员的落地指南

从 Prefetch（moderate） 开始，降低网络负担。
对高可信度流程（例如 产品详情 → 结账 ）加上 Prerender。
用 Header 配置规则，方便 CDN / 运维做实验。
打开 DevTools → Preloading，修红线。

无需新框架，无需第三方库，这是浏览器和你的一次成熟合作。

------ 但这里，本瓜友情提醒：caniuse 情况如下 - 2025.8.28

✍️ 总结

Speculation Rules API 的价值在于------它让"性能优化"变得声明化，而不是一堆事件监听和 hack。

在项目里加六行 HTML，就能让体验拉满；
结合业务流程（文章阅读、商品结账、后台仪表盘），你可以按需选择预取还是预渲染；
它不仅是性能优化，更是 转化率优化 的利器。

下次有人提"再加个加载屏幕"，你只要甩出这六行代码，又一个新思路？！