网页秒开?都是套路
DTC和GenAI让Web在整个互联网中的地位再次巩固了。从“There’s an app for that”,到ChatGPT一下,互联网重新回到了开放的氛围中。人人都在说体验,说网页浏览体验,我们喊了那么多年,带宽提升到了5G,网页秒开都还是奢望。然后,我们发现,就连APP和小程序也是一样,只不过先扔一个view给你,里面的东西还要慢慢填充。于是,天才的交互攻城狮们这样想-如果能够预先猜到用户下一步要点什么链接,然后预先加载,不是能够“笨鸟先飞”吗?
于是,谷歌在Chrome和Chromium的浏览器中加上了这么一个API。
Speculation Rules API
以往我们进行预加载的时候都会用<link rel=”prefetch”>指引,对Chrome浏览器来说还有个<link rel=”prerender”>,现已不再可用了。这些指引用起来麻烦,而且门槛比较高。为了解决这一问题,Speculation Rules API应运而生。这个“推断规则API”非常直观-你只要提供哪些是你想要“预加载”或者“预渲染”的页面URL即可。
比如,如果你安装了WordPress官方的Speculative Loading插件,你会在你的代码中看到下面的json。
<script type="speculationrules">
{
"prerender": [
{
"source": "document",
"where": {
"and": [
{
"href_matches": "/*"
},
{
"not": {
"href_matches": [
"/wp-login.php",
"/wp-admin/*"
]
}
},
{
"not": {
"selector_matches": ".no-prerender"
}
}
]
},
"eagerness": "moderate"
}
]
}
</script>
马老师带你解读一下上面的代码。
- 首先它告诉浏览器这段json数据是推断规则(Speculation Rules)。
- 这段规则仅使用了prerender,即预渲染。也可以是prefetch,仅下载一个HTML文件,不带文件中的其他资源。
- source的值可以是document或者list。如果urls属性出现,而where属性不出现,那么source应该是list。此处是document,代表要预加载或预渲染的URL从这个页面上找。Chrome 122版本后source属性不是必须的,因为可以通过urls和where属性来判断。
- where中定义了什么页面应该包含在预渲染的范围内,而什么页面被排除。可以用URL或者CSS Selector来定义。此处是定义了所有在本域名下的URL,除了那些CSS class为no-prerender的链接,也排除了登录和管理的链接。
- eagerness为中等。可以是immediate,eager,moderate,conservative四个值之一。
- immediate:顾名思义马上就进行预加载或预渲染。站长必须相信这么做很值,并且也可能预计需要大量的准备时间才能完成。浏览器通常应在可行的情况下尽快制定候选方案,仅考虑用户偏好、设备条件和资源限制等因素。另外,如果source我们用的是list,那么默认的行为将会是immediate,除非eagerness另有设定。
- eager:一有苗头就开始预加载或预渲染。浏览器应该根据用户将来可能导航到该URL的轻微建议来制定候选方案。例如,用户可能已将光标移向链接或将其悬停,甚至是短暂的,或者当该链接是视口中较突出的链接之一时暂停滚动。站长正在寻求尽早捕获尽可能多的导航。当前版本中immediate和eager的行为一致。
- moderate:比较有可能时才进行预加载或预渲染。如果用户行为表明用户可能在不久的将来导航到此 URL,则用户代理应指定候选者。例如,用户可能已将链接滚动到视口中并将光标在其上移动一段时间。或者站长在eager和conservative之间寻求平衡。当前版本中仅用于鼠标移动到链接上超过200毫秒,在移动设备上,并不存在这个行为。
- conservative:十分确定时才进行预加载或预渲染。仅当用户很可能随时导航到该 URL 时,用户代理才应指定候选。例如,用户可能已经开始与链接交互。站长试图通过相当小的资源权衡来获得加载的一些好处。另外,如果source我们用的是document,那么默认的行为将会是conservative,除非eagerness另有设定。
需要补充的是eagerness不同,Chrome浏览器能配给的资源也不同
eagerness | Prefetch | Prerender |
---|---|---|
immediate / eager | 50 | 10 |
moderate / conservative | 2 (FIFO) | 2 (FIFO) |
50代表最多预加载50个资源,10代表最多预渲染10个页面。FIFO指先进先出,第三个被预处理时,第一个会被清出缓存。
研究哪些页面被预加载了?
当我们部署了Speculation Rules的预加载之后,一定想了解如何如何体现在网站统计中。为此我们可以利用document.prerendering属性,以及performanceNavigation的activationStart属性。马老师在此也提供GTM的部署方法。
第一步,我们将建立一个Custom JavaScript变量并命名为Prerendered。
function pagePrerendered() {
if(document.prerendering ||
performance.getEntriesByType("navigation")[0].activationStart > 0){
return 1;
}else{
return 0;
}
}
复制以上代码到该变量定义中并保存。如果页面正在被预渲染或者是被预渲染的,那么该变量为1,否则值为0。
第二步,找到你的GA4 Tag,并在Configuration Parameter中添加prerendered参数,其值为{{Prerendered}},即我们刚才定义的变量。至此每次推送Page View事件的时候,都会同时推送是否被预渲染。
第三步,回到GA4,在Custom definitions的Custom metrics中新建一个新指标,其中Event parameter填我们刚才给的prerendered。

至此我们就完成了部署,你可以在不久后看到有多少被预加载的PageView。
总结
我们稍微总结一下,本篇马老师介绍了一种简单地让网页预加载从而实现网页秒开的方法,在页面端我们需要部署的工作量非常少,甚至能用Tag Manager快速部署。
但是要想做好预加载和预渲染还是要花一些心思的,这关系到如何优化客户端的资源和服务器端的负载,我们也可以通过研究用户的访问路径或者通过AI来预判动态地进行预加载预渲染添加,方法同添加动态脚本。
目前Speculation Rules API还在实验阶段,暂时不支持打开新标签的情况,仅支持在当前标签的浏览行为。同时对跨域名的预加载和预渲染因为安全考虑还没有完整的解决方案,这在未来也会被解决。