如果你也厌倦了页面里无穷无尽的 loading 动画，那 Chrome 的这个新能力你真的可以了解一下。
最近，Chrome 引入了一个名为 Speculation Rules API 的内置功能。它不需要任何前端框架，甚至无需编写 JavaScript 代码，更不用改动现有业务逻辑。你只需要在页面中添加几行声明式的 HTML，就能显著改善用户在页面间跳转时的加载体验。
核心：让浏览器提前做判断
我们熟悉的传统页面跳转流程通常是这样的：
用户 点击链接 → 浏览器开始请求 → 下载资源 → 执行脚本 → 页面渲染完成
Speculation Rules API 并没有改变这个流程的本质，它只是巧妙地将这条链路 往前挪了一点点。当浏览器通过一些线索（如用户悬停）判断用户 “很可能” 会点击某个链接时，它不会被动等待点击发生，而是提前开始准备工作。等到用户真正点击下去的时候，目标页面要么已经安静地躺在 缓存 里，要么干脆已经在后台完整地渲染好了。
6 行代码，直接生效
Speculation Rules API 的使用方式，比你想象中简单得多。你只需要把下面这段代码放进页面的 <head> 标签内即可：
<script type="speculationrules">
{
"prerender": [{ "source": "document", "eagerness": "moderate" }]
}
</script>
添加这短短几行之后，浏览器便会 自动扫描 当前页面中的所有链接。当用户 悬停 或 聚焦 到某个符合条件的链接上时，浏览器后台就会 开始预渲染 对应的目标页面。于是在很多跳转场景下，点击之后的切换几乎是 “秒切”，流畅得让你甚至会怀疑是不是哪里少了一个 loading 动画。
两种模式，理解清楚就够了
这个 API 本质上只提供两种核心的预加载策略，理解它们的区别至关重要。
-
第一种是 prefetch（预获取）：
浏览器会提前将目标页面所需的 HTML、JS、CSS 等静态资源下载下来并放入缓存，但不会执行任何页面逻辑。这种方式 资源消耗很低，几乎没有副作用，非常适合用来为整个站点的链接跳转做性能兜底。
-
第二种是 prerender（预渲染）：
这是更彻底的模式。浏览器会在后台像一个真实标签页一样，完整地加载并运行目标页面，包括执行 JavaScript、发起网络请求等。当你真正点击链接时，浏览器只是把已经在后台“热身”完毕的页面瞬间切换到前台。正因为如此，prerender 能带来最佳的即点即现体验，但使用时需要更加谨慎，避免对后台服务造成不必要的压力或触发非预期的副作用。
实际落地时，可以按三步来
在实际项目中应用这个 API，建议遵循一个渐进式的策略：
-
第一步，先广撒网，用 prefetch 打底：
对站内所有同域链接启用 prefetch。这种方式网络开销极小，但能显著减少用户首次跳转时的等待时间，基本没有业务风险，可以作为性能优化的基础步骤。
-
第二步，只对高价值路径用 prerender：
识别出用户行为确定性高的关键路径，例如从商品详情页到购物车结算页、从当前文章到“下一篇”等。在这些路径上使用 prerender，其带来的体验提升收益会非常明显。
-
第三步，跨域场景别忘了配响应头：
如果你需要预加载或预渲染其他域名下的页面，目标站点的服务器必须在响应中返回 Supports-Loading-Mode: credentialed-prerender 这个 HTTP 头，否则浏览器出于安全考虑不会生效。
eagerness 不用纠结，选对就行
API 中的 eagerness 参数决定了预加载行为触发的时机，一共只有三档：
eager：链接一旦进入可视区域（viewport）就开始预加载。moderate：当用户鼠标悬停（hover）或键盘聚焦（focus）到链接上时开始（这是默认值，也是最均衡通用的选择）。conservative：直到用户按下鼠标按键（mousedown）时才开始，最为节省资源。
对于绝大多数场景，直接使用默认的 moderate 即可，无需过度调优。
关于 Vue / React 单页应用，必须说清楚
需要明确的是，Speculation Rules API 针对的是 浏览器级的页面导航，即加载一个全新的 HTML 文档。而 Vue、React 等框架构建的单页应用（SPA），其内部路由切换本质上是前端路由库管理下的组件状态变化，并不会触发浏览器真正的文档加载（Navigation）。
因此，这个 API 并不能直接加速 SPA 应用内部的路由跳转。但是，如果你的项目存在 多入口页面，或者会从 SPA 应用跳转到其他独立的页面、其他子系统，那么这些 “真实的页面跳转” 场景，依然是 Speculation Rules API 大显身手的绝佳舞台。
使用时需要注意的几个点
在享受性能提升的同时，也需要注意一些边界情况：
- 避免副作用：如果目标页面一加载就会执行
写数据库、发送消息 或对关键业务状态产生影响的逻辑，那就不适合使用 prerender，改用 prefetch 会更安全。
- 处理权限：对于强依赖登录态的页面，建议在服务端或页面逻辑中提前做好
权限判断，避免后台预渲染直接触发 401 未授权错误。
- 区分统计：如果你的页面有
埋点 或 PV 统计代码，需要记得区分预渲染访问和真实用户访问。可以通过监听 document.prerenderingchange 事件来进行相应的处理。
- 验证生效：配置是否生效，可以直接在 Chrome DevTools 的 Preloading 面板（Application -> Frames -> Preloading）里查看，状态一目了然。
写在最后
Speculation Rules API 的核心思想其实并不复杂：它把用户感知的等待时间，从“点击之后”，巧妙地转移到了“浏览器空闲的时候”。
它当然不是解决所有性能问题的万能钥匙，但在合适的页面跳转场景下，它确实能以极低的改造成本（几行声明式配置），换来非常直观的用户体验提升。如果你也在寻找优化页面跳转速度的方法，可以到 云栈社区 与更多开发者交流实践心得。下次当有人讨论是否需要添加更多 loading 动画时，你至少拥有了一个更优雅、更高效的技术选择。 | 
发表于 昨天 05:12
|
查看: 9|
回复: 0
