配了三年预加载，每次用户点链接都要等半天——今天发现 Chrome 会替用户提前跑完这件事

你有没有这种感觉：明明 Lighthouse 分数很漂亮，但用户就是抱怨「点链接要等半天」。

根子不在服务器，在浏览器还没拿到用户点击这件事。

Chrome 从版本 121 开始原生支持 Speculation Rules API，允许开发者声明「下一页可能会被访问」，浏览器在用户Hover或Press的时候就提前把页面跑完，等用户真正点击时，体验就是「秒开」。

这件事彻底变了移动端性能优化的逻辑。

预加载不是新概念，但以前你配得不对

以前做预加载，大多数人的做法是监听 mouseenter，在里面塞个 fetch() 预拉资源。或者用 <link rel=”prefetch”> 声明静态资源。但这些方案有两个根本问题：

第一，预判不准。 你不知道用户是真的要点击还是只是划过。预判错了就是浪费流量，还可能把关键资源的带宽抢了。

第二，只预取资源，不预渲染页面。 预fetch 只下载 HTML，但页面的 JS 执行、React/Vue 初始化、接口请求，这些才是用户等待的大头。

Chrome 的 Speculation Rules API 把这件事彻底重新定义了。

Speculation Rules API 的三种预加载模式

这个 API 的核心是一个 JSON 配置，写在 <script type=”speculationrules”> 里面：

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

三种预加载模式，从轻到重：

Prefetch（预获取）：只下载 HTML 和静态资源，不执行 JS。

适合列表页→详情页这类确定性高的场景。用户点击之前先把资源拉下来，点击瞬间直接用缓存。

Prerender（预渲染）：完整执行整个页面，包括 JS 运行、数据请求。

适合转化路径固定的场景，比如电商结算页、活动落地页。用户在点击之前页面已经在后台「跑完」了。

Prerender with speculation-conditions：条件预渲染。

通过 eagerness 配置预判激进程度：

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": {
        "selector_matches": ".article-card a"
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

eagerness 有四个档位：

移动端电池保护模式：Chrome 自动降级

有一个细节很多人不知道：Chrome 在移动端的电池保护模式（Low Power Mode / Data Saver）下会自动禁用 prerender，只保留 prefetch。这是 Chrome 的内置保护机制，防止预渲染消耗过多电量和流量。

你的代码不需要特殊处理，Chrome 自己会处理降级。但如果你想确认当前状态，可以监听 Document Speculation Rules 状态：

if (document.speculationRules) {
  console.log('Speculation Rules API supported');
}

性能收益怎么量化

Google 内测数据：开启 prerender 后，移动端页面从点击到可见的时间（Navigation Time）降低 40-50%。在 4G 弱网环境下，这个差距更明显，因为预渲染把 JS 执行那部分时间「提前消化」了。

但要注意：不是所有页面都适合预渲染。Chrome 官方建议：

• 预渲染数量控制在 10 个以内
• 避免 prerender 带副作用的页面（比如支付页会自动扣款）
• prerender 的页面如果用户最终没访问，浏览器会丢弃，但已经执行的 JS 产生的 API 请求已经发出去了

怎么判断预加载是否生效

Chrome DevTools 的 Application 面板有 Speculation Rules 标签页，可以看到哪些规则被激活、哪些预渲染正在进行。另外，打开 chrome://inspect 里的 Speculation Rules 调试面板，能看到每个 URL 的预渲染状态。

迁移路径：渐进增强

这个 API 是渐进增强的——不支持的浏览器完全忽略这段 JSON，不影响现有功能。你只需要：

1. 梳理站内高概率的下一页路径（列表→详情、首页→栏目页）
2. 加上 Speculation Rules 声明
3. 用 DevTools 验证预渲染是否触发
4. 上线后用 CrUX（Chrome User Experience Report）观察真实用户的 Navigation Timing 变化

整个迁移不需要改一行 JS，两行 HTML 配置搞定。

现在你知道了：用户点链接要等半天，不一定是服务器慢，是浏览器还不知道「用户已经决定要点了」。这件事，Chrome 自己会处理。