配了三年移动端加载，今天发现 Chrome 自己会把下一页提前跑完——用户点击到页面出现的等待彻底变了

用户从列表页点到详情页，这中间有几秒的白屏等待——移动网络上更慢，体感更明显。你以为是网络的问题，今天发现根子在浏览器根本不知道用户下一步要去哪。

Chrome 悄悄上了一个 API，往 head 里塞 6 行 JSON，浏览器就会自动把用户即将访问的下一个页面提前跑完。不是预加载，是预渲染——后台把整个页面跑起来，包括执行 JS、加载图片。用户一点击，页面直接出现，延迟几乎为零。

这件事为什么现在值得说

以前想做页面预热，要么自己写 JS 监听 hover 事件，要么靠 CDN 的 prefetch 能力，效果一般还增加维护成本。Speculation Rules API 把这件事变成了浏览器原生能力，你只需要声明规则，浏览器自己会判断什么时候该预跑、预跑哪些页面。

更关键的是它对移动端特别友好：自动遵守电池保护模式和流量节省模式，用户省电省流量，你不用额外写一行代码。

具体怎么用

最简单的方式，往 head 里塞这段：

eagerness moderate 的意思是：浏览器自动扫描当前页面所有链接，当用户悬停或聚焦某个链接 200 毫秒后，后台就开始预渲染。整个过程不需要你监听任何事件。

想要更精准的控制，可以指定具体路径：

这样只预渲染商品详情页，eagerness conservative 只在用户真正点击时才预跑，对资源更保守。

哪些情况要排除

预渲染会把整个页面的 JS 全跑一遍，以下场景不适合开：

• 登录页、登出页：用户状态变了，预跑出来的页面内容是错的
• 有副作用的操作类页面：比如加入购物车，预跑就会真的把商品加进去
• 依赖实时数据的页面：股价、库存，页面内容可能过时

MDN 建议的排除写法：

Prefetch 还是 Prerender？

还有一个经常被搞混的选项——Prefetch。区别在于：

• Prefetch：只下载页面 HTML，不渲染，不执行 JS，加载速度快但不等于瞬开
• Prerender：完整跑完页面，包括 JS 执行、资源加载，激活时接近零延迟

MDN 的建议是：Prefetch 成本低，可以大范围推广；Prerender 成本高，只预跑高概率访问的页面。两者可以同时配置：

对移动端意味着什么

移动端用户最敏感的指标不是 Lighthouse 分数，是点一下等几秒这个体感。Prerender 把这个等待几乎归零，同时：

• 省电模式/流量节省模式下浏览器会自动降低预跑频率，不用你操心
• 预渲染的页面继承当前页面的隐私上下文，Cookie 和登录状态不会乱
• 跨站预渲染有限制（防止追踪），同站完全没问题

对于内容型 App（电商、资讯、社区）和移动端首屏加载优化，这个方案是目前成本最低、效果最直接的选项之一。

下一步

如果你现在就在做移动端优化，把这 6 行代码加到你的列表页/首页 head 里，试跑一周看数据变化。如果你的站点用了 CSP，还需要把 inline-speculation-rules 加到 script-src 指令里，否则浏览器会忽略这些规则。

Chrome 是目前支持最完整的浏览器，移动端覆盖率已经足够高，值得上了。