Speculation Rules API是什么？预渲染让站内翻页秒开的机制实战

摘要：用户点开你的下一页要等一两秒，这段等待其实可以提前偷偷做掉——趁他还在当前页浏览，浏览器悄悄把最可能点的那一页整个渲染好，等他真点，页面瞬间就在眼前。这就是Speculation Rules API干的事：用一段声明式规则告诉浏览器该预取或预渲染哪些页、什么时候动手。这篇我把它和老式资源提示的区别、prerender与prefetch怎么选、eagerness四个档位怎么配、会不会浪费流量、对SEO到底有没有用、以及统计数据为什么会虚高，一次讲透，配一个服饰站把翻页做到秒开的实操。

先问个扎心的问题：你花了那么大力气优化首屏，把LCP压进绿区，可用户点进第二页、第三页时，那一两秒的白等，你管了吗？大多数站根本没管——首屏优化到牙齿，页间跳转却还是老样子，一点一等。

我是保哥，做SEO二十多年。这几年我越来越觉得，站内的“下一页体验”是个被严重低估的洼地。而Speculation Rules API恰好就是填这个洼地的新工具，还是浏览器原生支持、几乎零成本的那种，写几行规则就能让站内翻页快得像本地应用。今天专门讲讲它。

Speculation Rules API到底是什么？为什么说它是预渲染的新一代方案？

一句话：它让你用一段声明式的规则，告诉浏览器“这些页面用户接下来很可能会访问，你提前准备一下”。浏览器据此在后台悄悄把这些页面预取甚至整页预渲染好，等用户真的点过去，几乎是瞬间呈现。

为什么说是“新一代”？因为预渲染这个想法并不新，老早就有个 <link rel='prerender'> 的写法，但它能力弱、控制粗、还被各家浏览器陆续废弃。Speculation Rules是把这套能力重做了一遍：控制更细、语义更清、还能预渲染整页而不只是预取资源。WICG的nav-speculation提案就是这套新机制的出处，它把“预测导航”这件事标准化成了一套可声明的规则，而不是过去那种零散的、半吊子的提示。

它和preload、prefetch这些资源提示是一回事吗？

这是最该分清的一点，很多人一上来就搞混。preload、preconnect、prefetch这些资源提示，操作的对象是单个资源——某个字体、某张图、某个脚本，让浏览器早点发现、早点下载它们。它们服务的是“当前这一页”加载得更快。

Speculation Rules操作的对象是整个页面——它预取或预渲染的是一整个URL、一个完整的下一页文档。它服务的是“下一页”打开得更快，甚至瞬开。一个在优化当前页的零件，一个在提前造好下一页的整车，层级完全不同。

我知道有人会说，prefetch不也能预取下一页文档吗？确实，资源提示里的prefetch也沾点边，但它只是低优先级地把文档拉下来放缓存，不做渲染，控制粒度也粗。Speculation Rules则能一路做到整页预渲染，还能精细控制触发时机。想把preload、preconnect、prefetch这套老资源提示彻底搞明白、看清它们各自的边界，可以对照我那篇专讲五种资源提示技术对比的指南——那篇是“资源级”的地基，这篇讲的是“页面级”的新楼层，站在一起看才完整。

怎么写一条speculation rules？prerender和prefetch有什么区别？

写法是往页面里塞一段JSON，放在一个特定类型的script标签里。大致长这样：一条规则声明动作是prerender还是prefetch，再声明对哪些URL生效。MDN上Speculation Rules API的文档把完整语法和字段列得很齐，照着抄改即可，门槛不高。

指定URL有两种方式，值得一提。一种是直接列一串具体地址，叫列表规则，适合你明确知道要预备哪几个页面。另一种更灵活，叫文档规则，你写一段匹配条件，浏览器自动去页面里挑符合条件的链接下手——比如把所有指向站内文章页的链接一网打尽。对内容站、电商站这种链接海量的场景，文档规则配上后面要讲的急切度，几乎不用你逐个维护，省心得多。

关键是分清里面两个动作。prefetch 只预取文档本身，不取它的子资源，也不渲染——省资源，但用户真点过去时，子资源还得现下、页面还得现渲染，所以是“快一点”。prerender 则是把整个页面连同子资源全部提前渲染好，用户一点几乎瞬间呈现，代价是它更吃资源。

怎么选？我的经验是：把握极大、几乎笃定用户会去的页面（比如分页的下一页、结账流程的下一步），值得上prerender求极致瞬开；只是有一定可能、但不那么确定的一批链接，用prefetch更稳妥。如果你的站是React、Next.js这类框架搭的，还得注意预渲染和框架自身的路由预取别打架，这块的坑我在讲框架站渲染模式怎么选的文章里带过，框架层和浏览器层的预取要理清各管一段。

eagerness那四个档怎么选？immediate和conservative差在哪？

Speculation Rules有个特别好用的设计叫eagerness（急切度），它把“对哪些URL动手”和“什么时候动手”拆成了两件事。同样一批URL，你可以配不同的动手时机。它有四个档。

immediate：规则一加载就立刻动手，最激进。eager：比immediate稍缓，但也很早。moderate：用户在某个链接上悬停约200毫秒（或移动端按下的一瞬）才动手——相当于“看你有点想点了，我才准备”。conservative：等到用户真的按下链接那一刻才动手，最保守。

按 DebugBear那篇讲Speculation Rules的文章的归纳，这几档背后其实是“命中率”和“资源消耗”的权衡：越急切，瞬开体验越好，但预测错了就白烧资源；越保守，浪费越少，但抢跑的时间也越少。我的默认打法是：确定性极高的少数关键跳转用immediate或eager，大面积的普通链接用moderate，让用户的悬停行为帮你筛掉大部分不会点的，性价比最高。

我那个服饰站怎么用预渲染把翻页做到秒开？

去年一个做女装的独立站找我，痛点很具体：他们的列表页做了分页，用户逛得挺勤，但每翻一页都要白等一秒多，数据显示很多人翻到第二页就没耐心走了。这一秒的等待看着不起眼，实打实在一页一页地漏人。

我给的方案是给“下一页”这个动作上Speculation Rules。逻辑很清楚：用户在看第一页时，翻到第二页的概率相当高，那就趁他还在浏览，把第二页整个prerender好。eagerness用moderate，等用户鼠标往分页按钮上一凑就开始准备。

上线后的效果肉眼可见：用户点“下一页”，页面几乎是瞬间就在了，那种翻页的顿挫感没了。更妙的是，从用户感知看，第二页的TTFB、LCP全都像归零了——因为页面早在他点之前就渲染好了，点击只是把它推到台前。这里插一句，预渲染是把感知层面的等待消灭掉，但它不改服务器那一端真实的响应速度；真要治本，服务器和缓存那一层还得单独优化，这块我在讲TTFB与多层缓存怎么治理的文章里拆得很细。预渲染和TTFB优化不冲突，一个改感知、一个改根本，叠着用最香。

预渲染会不会白白浪费流量和内存？Chrome怎么控制？

这是最实际的顾虑：万一预渲染了一堆用户根本没点的页面，那流量和内存不就白烧了吗？确实有这风险，但Chrome做了不少约束来兜底。

首先是数量限制。那几个依赖用户交互的档位（eager、moderate、conservative），预渲染是按先进先出管理的：到了上限，新的预渲染会把最老的那个挤掉、取消回收，避免无限堆积吃爆内存。这一点 Web Performance Calendar上那篇讲投机加载的文章解释得挺透，本质是拿一个有限的预算池去博命中率。

其次，某些情况浏览器会主动放弃预渲染，比如用户开了省流量模式、设备内存吃紧、或者目标页面带了不适合预渲染的东西。所以别把它想象成毫无节制地狂预渲染——它更像一个带预算、会自我克制的机制。你要做的是别贪，把eagerness配合理，把预渲染留给真正高概率的跳转，让每一发都尽量打中。

预渲染对SEO有用吗？Googlebot会触发这些规则吗？

先泼盆冷水：Speculation Rules不是一个直接的排名信号，Googlebot也不会去触发你的预渲染规则。这些规则是为真实用户的浏览行为服务的，爬虫抓取走的是另一条完全不同的路，它不会因为你写了预渲染就多抓几页。想搞清爬虫到底怎么对待各种渲染策略、什么才真正影响抓取，可以看我那篇讲JS渲染与爬虫引用率的实测文章——预渲染动的是用户侧，不是爬虫侧，这条界线得先划清。

那它对SEO到底有没有价值？有，但是间接的。预渲染让站内跳转变得极快，用户逛得更顺、翻得更深、跳出更少、停留更久——这些真实的行为改善，恰恰是当下搜索引擎越来越看重的体验信号的养料。你不是在骗排名，你是在实打实地让用户更愿意留下来。这条路虽然绕，但走的是正道，也更耐久。

我更愿意换个角度看这件事：与其纠结它算不算排名因素，不如问它有没有让你的站变得更好用。答案是显然的。一个翻页顿挫、点哪都要等的站，和一个点哪都秒开的站，用户用脚投票的结果天差地别。而用户的选择，最终会以各种信号的形式回流到搜索引擎那里。把体验做扎实，排名是水到渠成的副产品，这个因果顺序别搞反了。

预渲染最容易踩的坑是什么？统计数据为什么会虚高？

最阴的一个坑，是分析统计。页面被预渲染时，如果你的统计脚本不管三七二十一就上报了一次页面浏览，那问题就来了：用户可能根本没点进来，你却记了一次PV。结果就是浏览量虚高、跳出率失真，数据全乱。

正确的做法是，让统计脚本感知“预渲染”这个状态，等页面真正被用户激活（也就是真的呈现到眼前）时才上报。现代分析工具和浏览器都提供了判断激活状态的能力，Chrome官方那篇讲预渲染的文档专门提醒了这一点，还给了怎么正确处理的建议。上预渲染之前，务必先把你的埋点改造好，不然你会对着一份被污染的数据做决策，越看越糊涂。

另一个小坑是别对带副作用的页面用prerender。如果某个URL一被打开就会触发下单、扣款、发通知这类动作，那预渲染它就是灾难——用户还没点，那些动作就先执行了。这类页面要么直接排除在规则之外，要么退到只做prefetch不做整页预渲染，切记别图一时的快把它们也卷进去。

现在能用了吗？浏览器支持怎么样？

坦白讲，Speculation Rules目前主要是Chromium系浏览器（Chrome、Edge等）支持，Safari和Firefox还没跟上。所以它不是一个全平台都能吃到的能力，这点得如实告诉你，具体支持范围可以查 caniuse上speculation rules的兼容性表。

但这不妨碍现在就用。它是纯粹的渐进增强：支持的浏览器，用户享受瞬开；不支持的浏览器，直接忽略这段规则，页面和跳转都照常，一点不受影响、不会出错。考虑到Chromium系的市场份额，等于你花很小的代价，就让相当大一批用户的站内体验上了一个台阶——这买卖怎么算都划算，没有理由等到全平台支持才动手。

常见问题解答

Speculation Rules和老式的link rel=prerender有什么区别？

老式的link rel=prerender能力弱、控制粗，已被主流浏览器陆续废弃。Speculation Rules是它的替代者：能预取也能整页预渲染、能用eagerness精细控制触发时机、还能批量匹配URL。简单说，前者是被淘汰的旧方案，后者是重做过的新一代，新项目直接用后者即可。

prerender和prefetch到底该用哪个？

看把握。几乎笃定用户会去的页面（如分页下一页、结账下一步）用prerender，整页提前渲染好，点击瞬开。只是有一定可能、不那么确定的一批链接用prefetch，它只预取文档不渲染，更省资源。把prerender留给高概率跳转，prefetch覆盖面上的可能性，是比较稳的搭配。

预渲染会拖垮用户的流量和设备吗？

可控。Chrome对依赖交互的档位做了先进先出的数量限制，超上限会取消最老的预渲染回收内存；用户开省流量模式或设备内存紧张时，浏览器还会主动放弃预渲染。你要做的是把eagerness配合理、只预渲染高概率跳转，别无差别地全站狂预渲染，就不会浪费。

用了预渲染，我的统计数据会不会不准？

不改造就会。页面被预渲染时如果统计脚本立刻上报PV，会导致浏览量虚高、跳出率失真。正确做法是让埋点感知预渲染状态，等页面真被用户激活时才上报。上预渲染前务必先改造好统计脚本，否则数据会被污染。

Googlebot会触发我的speculation rules吗？对收录有帮助吗？

不会。这些规则服务的是真实用户的浏览行为，爬虫抓取走另一条路，不会因为你写了预渲染就多抓页面，它也不是直接排名信号。它的SEO价值是间接的：让站内跳转极快，改善用户停留和浏览深度这些体验信号，从而间接利好排名。

Safari和Firefox不支持，还值得做吗？

值得。它是渐进增强，不支持的浏览器会直接忽略规则，页面和跳转照常，不会出错。考虑到Chromium系浏览器的市场份额，你用很小的代价就能让相当大一批用户的站内体验提速，不支持的用户也毫发无伤，没有理由不做。

权威参考资料