了不起的Chrome浏览器（14）：Chrome 101发布Priority Hints，可以控制资源优先级了

2022年4月26日发布的Chrome 101，有哪些新特性呢？

TL;TR

Chrome 101正式发布了Priority Hints，用于指定页面资源的加载优先级，即fetchpriority属性，帮助浏览器根据优先级优化加载顺序，从而优化页面加载体验。

Chrome 101开始在安卓端试用Federated Credentials Management API，旨在不使用第三方Cookie的情况下，实现第三方登录，为全面禁用第三方Cookie做准备。

详细解读

Priority Hints

Chrome 101正式发布了Priority Hints，用于指定页面资源的加载优先级，即fetchpriority属性，帮助浏览器根据优先级优化加载顺序，从而优化页面加载体验。

试用Priority Hints的时候，当时使用的属性名称是importance，正式发布的时候HTML属性名改成了fetchpriority，fetch的参数名改成了priority。命名确实变好了，重要性（importance）和优先级（priority）本来就不是同一个概念，这里用priority更加合适，特性的名称不正是Priority Hints嘛。同时，HTML属性名称在priority之前添加了fetch前缀，更加清楚表达了属性的含义，缺点是命名有点长，有点费流量。至于fetch的参数，不加前缀也是正确的，但是问题是两处名称不一致。我觉得命名确实变好了，但是不如两处都用priority，既保持一致，也节省字符。

改个命名有啥好聊的？那这里就有学问了！

从这个细节可以看出，Google的Code Review机制非常严格，变量命名也不放过，花了不少心思。虽然我并不完全赞同这个命名，但是我非常欣赏Code Review这种做法和态度。

浏览器全局API的命名当然应该慎重，因为这会影响整个Web生态系统。而我们自己在写代码的时候，也应该仔细思考一下命名，不能随便乱来，否则大概率是坑自己，也会坑队友。

但是，命名是一件挺难的事情，有句话是这样说的：

There are only two hard things in Computer Science: cache invalidation and naming things.

命名的问题按下不表，继续聊Priority Hints特性。

浏览器下载页面资源的顺序由众多因素所决定，比如资源的类型、位置及顺序、是否在可视窗口、是否指定defer、async、preload等。浏览器根据规则确定资源的优先级，从而确定下载顺序。

一般来讲，浏览器可以很好地决定资源下载顺序，但是由于缺乏对具体应用及具体页面的深入理解，浏览器下载资源的顺序很难是最优的。这时，如果我们就可以利用规则来调整资源的优先级，从而影响下载顺序，比如为页面统计/监控脚本指定async。不过这种方法有点隔山打牛的感觉，既复杂又不一定能达到效果。

Priority Hints则非常简单直接，通过fetchpriority属性指定资源的优先级，其取值为high、low、auto，其中auto为默认值，使用方式如下：

`<!-- 通过fetchpriority属性指定图片的优先级 -->   <img src="/images/test.png" fetchpriority="high" />      <!-- 使用fetch的时指定优先级 -->   <script>  fetch("https://example.com/", { priority: "low" }).then((data) => {});</script>   `

不过，fetchpriority属性作为浏览器确定资源加载顺序的重要参考，但是并不具备决定性作用。这样设计，应该是为了防止fetchpriority被滥用。

如下图所示，通过使用Priority Hints提高背景图片的下载优先级，Google Flight将Largest Contentful Paint（简称LCP，即最大内容绘制）从2.6s降低到了1.9s：图片来源：Optimizing resource loading with Priority Hints

从视频可以很明显看出来，背景图片的加载明显提前了，用户所感知的体验提升了很多：

视频来源：Optimizing resource loading with Priority Hints

Google Flight的案例很好地说明了Priority Hints的作用，但是它也只是一个非常简单、刚好合适的案例，并不具备普遍的说服力。Priority Hints在实际应用场景的真实效果以及最佳实践，需要更多数据来进行验证。

Priority Hints为WICG提案，由Google的开发者负责，目前并未得到其他浏览器的支持。

Priority Hints这个特性还是很有意思的，可以用作页面性能优化。但是，使用Priority Hints还是有一些问题的。

一方面，如果需要手动控制各个资源的优先级的话，感觉有点麻烦，页面这么多这么复杂，变化那么快，开发者也很难确定如何设定资源优先级。所以，这个特性最好是前端框架或者工具来进行自动控制。否则，有可能大部分资源的fetchpriority属性都被设为high了，那就相当于TypeScript写成了AnyScript了，用了等于没用。举个大家更加熟悉的例子，看电影的时候，如果第一排的观众站起来了，然后第二排的观众也站起来了，最后大家一起站起来看电影，这样既锻炼身体，又欣赏了电影，是不是很开心。。。

另一方面，Priority Hints的所配置的值本身不是绝对生效的，它只是个参考值，就算生效，它对于页面性能的优化同样很难进行度量、监控和优化，因为影响前端页面性能的因素太多了。当然，前端页面性能的度量本身就是一个难题，这也不是Priority Hints特性本身的问题。

总之，Priority Hints非常值得尝试，但是最佳实践还需要大家进一步探索。

Federated Credentials Management API

Chrome 101开始在安卓端试用Federated Credentials Management API（简称FedCM），旨在不使用第三方Cookie的情况下，实现第三方登录，为全面禁用第三方Cookie做准备。

根据FedCM提案，有3个不同的角色参与了第三方登录的操作：

• Relying Party：需要进行第三方登录的站点，比如知名复制粘贴站点Stack Overflow可以使用Google、GitHub以及Facebook的账号进行登录，其中Stack Overflow就是Relying Party；

• User Agent：指的就是浏览器，处于Relying Party和Identity Provider之间，给Relying Party提供登录接口的同时，保护用户隐私，避免跨站定位分析用户行为；

• Identity Provider：提供登录服务的站点，比如Stack Overflow可以使用Google、GitHub和Facebook账号进行登录，其中Google、GitHub、Facebook就是Identity Provider，用户的账号信息，比如登录ID和密码是保存在Identity Provider那里；

如下图，Relying Party和Identity Provider不能进行之间交互，需要通过User Agent间接进行交互。

第三方登录状态可以使用第三方Cooike来记录，FedCM相当于让User Agent替代第三方Cookie的作用，保存登录状态。

Chrome 102将在桌面端开始试用FedCM，于Chrome 105正式发布。

对于FedCM这个提案，Safari和Firefox都不感兴趣，反正它们早就全面禁用第三方Cookie了，又不是不能用。更重要的是，也没有什么其他登录服务提供商参与，比如水果公司应该没兴趣给浏览器提供登录接口，所以这事目前看起来前景暗淡。理想很丰满，现实很骨感。到时候可能就只有Chrome浏览器支持FedCM，并且只有Google自己家的登录服务，自己给自己的登录服务添加了一层转发，Youtube和Gmail可以用FedCM共享登录状态了，不过看着还是有点多此一举....

第三方登录到底怎么实现，取决于Identity Provider怎么思考这个问题，谁掌握了用户就听谁的，浏览器厂商并没有主导权。即便不用第三方Cookie也不是不可以，也不是非得用FedCM。如果每个Identity Provider提供的登录接口都不一样，对于Web工程师来说，确实有点麻烦，如果大家都使用浏览器提供的统一接口也挺好的，不过这事太难办了。

登录是最危险的操作之一，验证手机号已经是最基本的安全防范方式，运营商以前靠短信赚得盆满钵满，现在短信的主要功能之一不就是接收验证码了吗。。。为了保证安全，不同站点还有各种奇奇怪怪的验证码、语音识别、指纹识别、人脸识别、双重验证、密保问题等安全验证机制，Identity Provider有责任保护用户的数据安全和数据隐私，因此它们不太可能轻易将这么重要的接口统一交给浏览器托管，改起来不方便，万一出了安全漏洞怎么办？

根据Chrome最新的计划，第三方Cookie将会在2023年中旬开始逐步禁用第三方Cookie，这样将会影响一些依赖第三方Cookie的登录服务。为了全面禁止第三方Cookie，Chrome已经提出了N个提案来解决由此导致的问题，FedCM其中之一。当然，Google最关心的事情是没有第三方Cookie之后，网页广告还怎么玩。但是，这些提案Safari和Firefox都不怎么感兴趣，因为它们的商业模式不像Google那样依赖网页广告。所以，现在Chrome的处境非常尴尬，需要在保护用户隐私的情况下，寻找广告的替代方案，这事还得在1年之内完成，监管机构还未必同意新方案。

2023年，也就是明年，第三方Cookie完全失效之后，将会是Web历史上关键的转折点。

一方面，如果没有及时进行技术改造的话，不少依赖第三方Cookie的站点和服务出问题。这个问题当然很严重，但是这只是个纯粹的技术问题，是可以花时间解决的，所以并不是最大的问题。Safari和Firefox早就全面禁止第三方Cookie了。

另一方面，依赖第三方Cookie的广告的商业模式将会被颠覆，这有利于保护用户隐私，但是同时也动摇了Web免费开放的生态系统根基：广告。对于平台型的互联网公司来说，本身拥有海量的用户数据，可以继续通过个性化广告赚钱。对于缺乏用户数据同时依赖广告生存的中小型站点来说，这就不是什么好消息了，因为它们没法推送精准广告了，收入有可能会大幅降低。假设你是男生，同时是女装大佬，站点只给你推荐男装广告，想必这个广告的转化率会比较低。

广告是个双刃剑，我们能够免费使用各种各样的网络服务，从搜索、新闻、博客、视频到各种小工具，正是因为广告，是广告主出的钱，最终买单的是购买产品或者服务的消费者。同时，我们的个人数据被过度甚至无节制地收集、分析、利用甚至贩卖，也是因为广告。你在新闻站点看了一下关于某款千万豪车的新闻，然后你就在购物网站收到了5块钱的购车优惠券，你是应该开心还是难过呢？反正我有点想删APP。。。

天下没有免费的午餐，所谓的免费，只不过是“羊毛出在狗身上，猪来买单”。

不过，第三方Cookie被全面禁用基本上板上钉钉了，这事已经没有讨论的空间了。我们的个人数据会得到更好的保护，也挺好的。我也讨厌广告，用了各种AI算法之后广告其实还是很傻，某博经常给我推送植发广告，可是我的技术还没到需要植发的程度啊。。。

至于个性化广告的问题，影响肯定会有的，应该会有替代方案，但是究竟会变成什么样，我也不知道了。。。大家拭目以待。

总结

Chrome 101没有什么特别大的亮点，Priority Hints使用场景和效果还不确定，Federated Credentials Management API的前景更加不明朗。尴尬的是，这2个特性都没有其他浏览器积极参与。并且，这2个特性都涉及到了对全局API的修改，Priority Hints给HTML标签添加了一个fetchpriority属性，Federated Credentials Management API给全局接口FederatedCredential拓展了好几个方法。Chrome这样子自作主张其实不太合适，但是，Web这么些年就是这样发展的，技术方案和细节由极少数掌握规则制定权的人来决定：

• 互联网之父Tim Berners-Lee很后悔他给网页链接添加了2个莫名其妙没有作用的斜线"//"，这个确实挺浪费电的；

• Mosiac浏览器的作者以及网景公司创始人之一Marc Andreessen没什么理由偏要把图片标签命名为img而不是image，这个无伤大雅，还省电；

• JavaScript之父Brendan Eich设计了2个实质含义差不多但是又不一样的空值：null和undefined，这个也还好；

• Node.js之父Ryan Dahl对于node_modules的复杂度也感到很遗憾，并且无能为力，只能再造新轮子，JavaScript生态系统最成功同时最失败的也就是NPM了；

我们没有资格指责这些改变世界的天才们，他们写的代码成为了标准，而不是先制定标准再写代码，他们也会犯错。从来就没有完美的技术，技术都是在一点一点变好。没有标准会阻碍技术进步，标准限制太多同样也会阻碍技术进步。整体来看，Chrome极大促进了Web技术进步，也没有作恶，但是它们可能会犯错，这是技术发展的代价吧。你敢说自己写的代码是完美无缺的吗，除非你不写代码。

Chrome最近的很多新的特性和Breaking Change都和保护用户隐私相关，包括本文介绍的Federated Credentials Management API、之前介绍的Reduce User Agent string information、User-Agent Client Hints、之前提及过的SameSite以及尚未介绍过的Privacy Sandbox，这些改变主要是由于监管及法律方面的要求，同时也要归功于Safari和Firefox两个强大的竞争对手的压力。对于开发者来说，Breaking Change是最让人痛苦的事情之一，但是长远来看，一个更加保护隐私的Web生态系统会更加健康，更容易获得用户的信任，整个生态会越来越好。如果用户觉得Web应用没有安全感，那Web开发者就可以提前改行了。Apple的生态系统的之所以更加成功，其中一个原因是它家的产品和系统更加安全，更加注重隐私保护，FBI都拿它们都没办法。

才疏学浅，我所写的内容难免有错误之处，欢迎批评指正，感兴趣的同学可以微信交流：KiwenLau。

欢迎关注寒雁Talk公众号，关注《了不起的Chrome浏览器》系列博客，与我一起见证大前端的星辰大海！

参考资料

• Chrome 101: Federated Credential Management Origin Trial, Media Capabilities for WebRTC, and More

• 了不起的Chrome浏览器（8）：Chrome 96也支持WebAssembly引用类型了！

• 第三方cookie马上就不让用了，互联网广告还怎么玩？

• An updated timeline for Privacy Sandbox milestones

• Full Third-Party Cookie Blocking and More

• Today's Firefox Blocks Third-Party Tracking Cookies and Cryptomining by Default

• Google delays blocking third-party cookies in Chrome until 2023

• 当浏览器全面禁用三方 Cookie

• Berners-Lee 'sorry' for slashes

• The Origin of the IMG Tag

• Javascript的10个设计缺陷

• 10 Things I Regret About Node.js - Ryan Dahl - JSConf EU

• TwoHardThings

招聘

阿里巴巴业务平台事业部长期招聘P6及以上前端大佬，参与建设最前沿的阿里前端生态系统，推动行业技术发展，内推地址：hanyan.lk@alibaba-inc.com

欢迎大家关注我的微信公众号寒雁Talk。