长亭百川云 - 文章详情

了不起的Chrome浏览器(14):Chrome 101发布Priority Hints,可以控制资源优先级了

寒雁Talk

63

2024-07-13

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浏览器》系列博客,与我一起见证大前端的星辰大海!

参考资料

招聘

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

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

相关推荐
关注或联系我们
添加百川云公众号,移动管理云安全产品
咨询热线:
4000-327-707
百川公众号
百川公众号
百川云客服
百川云客服

Copyright ©2024 北京长亭科技有限公司
icon
京ICP备 2024055124号-2