了不起的Chrome浏览器（10）：2021年，Chrome哪些变化最值得关注？
Posted 寒雁Talk
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了了不起的Chrome浏览器（10）：2021年，Chrome哪些变化最值得关注？相关的知识，希望对你有一定的参考价值。
2008年9月2日，Chrome浏览器终于发布了，长达2年的秘密开发没有白费，出道即巅峰：
当年主管Chrome项目的Sundar Pichai，在发布Chrome时是这样说的：
We hope to collaborate with the entire community to help drive the web forward.
这种吹牛的话一般没人相信，不过Chrome真的做到了，而Pichai也因为领导Chrome项目所展现的出色的远见和能力，后来出任谷歌CEO，走向人生巅峰。
Chrome不仅市占率第一，并且直接以及间接推动了一系列Web技术的进步：V8、ECMASCript 2015、HTTP/2、HTTP/3、QUIC、HTTPS、WebAssembly、WebGPU。。。
并不夸张地说，了解Chrome的发展可以帮助我们理解整个前端行业的发展趋势，因为浏览器的能力就是前端行业的边界所在，而主要推动浏览器进步的就是Chrome。
那么，2021年，Chrome有哪些值得关注的变化呢？
关于《了不起的Chrome浏览器》
2021年，我开始写《了不起的Chrome浏览器》，这是我写得最长的一个系列博客，一共9篇：
为了写这篇博客，我把《了不起的Chrome浏览器》博客全部阅读了一遍，发现自己真的写了好多知识点：从简单的ECMAScript新特性（Top-level await、Array.prototype.at）、到复杂的安全漏洞（NAT Slipstream 2.0、ALPACA、Sweet32）、再到有意思的Web API（Web NFC、Web Serial API、Secure payment confirmation）、以及一些重要的技术创新（WebAssembly SIMD、WebGPU、WebCodecs）。其实，很多知识细节我都有点忘了，再看一遍也挺有收获的。这也是写作的好处之一，可以作为学习笔记，以便需要的时候查阅。
写Chrome博客花费了我大量的业余时间，持续更新其实挺难的。不过，写作本来就是我的兴趣，也是最重要的学习方式之一，所以我还是坚持下来了。
《了不起的Chrome浏览器》的累计阅读量还不错，平均每篇博客的全网阅读量在5000以上，每篇博客的具体阅读量如下图所示：
我的长期目标是在2025年出版一本关于Chrome的书，毕竟出书是很多热爱写作的人最高的追求。这本书首先要有一定的技术深度，同时可读性要足够好，并且能讲清楚技术发展背后的原因，包括技术和商业动机。所以，写《了不起的Chrome浏览器》博客对我来说，相当于积累写书的素材和灵感。当然，写技术书其实并不怎么赚钱，我也不是为了赚钱，更加不会为了赚钱去写一些没有价值的内容。
Chrome 2021
2021年，Chrome一共发布了9个版本，从Chrome 88到Chrome96：
| 日期 | Chrome版本 | 亮点 |
|---|---|---|
| 2021-01-19 | Chrome 88 | 移除Flash |
| 2021-03-02 | Chrome 89 | WebNFC |
| 2021-04-13 | Chrome 90 | AV1 Encoder |
| 2021-05-25 | Chrome 91 | WebAssembly SIMD |
| 2021-07-20 | Chrome 92 | |
| 2021-08-31 | Chrome 93 | Error Cause |
| 2021-09-21 | Chrome 94 | WebGPU |
| 2021-10-19 | Chrome 95 | WebAssembly Exception Handling |
| 2021-11-16 | Chrome 96 | WebAssembly Reference Types |
我是从Chrome 89开始写《了不起的Chrome浏览器》博客的，所以错过了Chrome 88。另外，Chrome 92实在没有发现什么特别大亮点，大概是其他版本太卷了。。。整体来看，Chrome在2021年的表现相当让人惊艳。
2021年，Flash停服了。Chrome也彻底告别了Flash，结束了一代人对于Flash游戏、动画、视频的记忆，比如开心农场、QQ空间。据传，此事还导致某地铁路系统出现故障，相当尴尬。Flash弥补了早期Web能力的不足，但是本身存在严重的安全风险，随着Web技术的迅速进步，Flash早就没那么重要了。Adobe在2017年就给Flash宣判了死刑，这一天还是来了。
图片来源：Goodbye Flash, goodbye FarmVille
2021年，WebAssembly更强了。Chrome相继支持WebAssembly SIMD、WebAssemblyException Handling以及WebAssemblyReference Types，这些都是非常重要的WebAssembly特性。大名鼎鼎的Photoshop终于迁移到了Web，是通过将C++编译为WebAssembly来实现的，其中WebAssembly Exception Handling与WebAssembly SIMD发挥了重要的作用。
图片来源：Photoshop\'s journey to the web
2021年，QUIC协议发布了。这将有助于提升网络通信的性能、安全性以及灵活性。这是计算机网络发展的革命性里程碑，未来TCP将有可能会逐步退出历史舞台（这个过程会应该比较长，甚至像IPv6一样时间拖很久）。作为发明者，Chrome是最早部署QUIC协议的浏览器，再一次用技术改变世界。
2021年，WebGPU要来了。Chrome 94开始了WebGPU试用，预计将于2022年上半年正式发布。WebGPU是WebGL的继承者，它们的目标类似，不过WebGPU提供了更加底层的GPU能力。因此，WebGPU的图像渲染能力更强，性能更好，更易用，也更加适用于数据并行计算以及机器学习。
Flash停服了
亨利福特曾经说过：
If I had asked people what they wanted, they would have said faster horses.
在马车时代，人们只会希望马车能跑得更快一点，而不会想到马车会被汽车取代。
类似的，虽然Flash也曾辉煌过很长一段时间，但是依然还是被时代抛弃了，2021年是它的终点。
Flash在中国的高光时刻大概是全民偷菜？这个简单的游戏曾经让企鹅赚得盆满钵满。
图片来源：2021年1月1日，是Flash的葬礼日
我没玩过偷菜，但是我也曾用过QQ空间（暴雷年龄了）。那些杀马特的QQ空间，当年靠的就是Flash，把页面整的花里胡哨的。
图片来源：2021年1月1日，是Flash的葬礼日
对Flash怨念最深的莫过于乔布斯了，iPhone从一开始就不支持Flash。乔帮主还亲自写了一篇文章Thoughts on Flash抨击Flash不安全、BUG多、封闭、费电、对触屏不友好，有理有据有节。从这篇文章也能看出来，乔帮主绝非不懂技术，反而技术视野还不错，对Flash存在的技术问题分析得非常到位，切中要点。与乔布斯、盖茨以及马斯克这些美国企业家相比，中国的互联网大佬其实大多都是技术出身，但是都不怎么聊技术，这大概是因为中国互联网过去的发展主要靠的是应用层以及商业模式的创新，而不是技术层面的创新。
那么问题来了，是乔帮主封杀Flash导致Flash衰落，还是Flash自己毛病太多导致乔帮主不得不封杀Flash呢？我想更多是后者，人不自救，孰能救之。
当然，苹果并非没有私心，它更希望将开发者控制在苹果的生态系统中。苹果扯着html5的大旗封杀Flash，不过后来对Web技术远不如谷歌来的热情。
早期，Flash被用于播放视频、制作动画、展示广告等。后来，Web技术的不断进步，比如video标签、Canvas、WebGL、SVG，逐步替代了Flash的作用，Flash也就失去了市场。
怀旧的人们大概会有些伤感，但是事实上，没有Flash之后的Web会更加安全、更加流畅，这就更加扎心了。。。
WebAssembly更强了
2021年无疑是WebAssembly的大年。
在技术方面，Chrome相继支持了WebAssembly SIMD、WebAssemblyException Handling以及WebAssemblyReference Types这3个重磅特性。
在应用方面，宇宙级图片处理工具Photoshop通过使用WebAssembly迁移到了Web，另外基于WebAssembly实现的设计工具Figma估值达到惊人的100亿美元，两者都证明了WebAssembly的巨大价值。
对WebAssembly感兴趣的同学，欢迎阅读我的博客《十年磨一剑，WebAssembly是如何诞生的？》，了解WebAssembly的发展历史。
WebAssembly SIMDChrome 91默认开启了WebAssembly SIMD。
SIMD是Single Instruction Multiple Data的缩写，中文术语为“单指令多数据流”，顾名思义，就是可以使用单条指令同时处理多个数据。
SIMD是一种特殊的CPU指令，它可以实现数据层面的并行处理。如下图，当我们需要对两个长度为4的数组做加法时，使用普通的指令，则需要执行4次普通加法指令；如果使用SIMD指令的话，则只需要执行1次向量加法即可：
SIMD常用于视频、音频、图像、加密、动画、游戏、AI等需要处理大量数据的应用场景，可以极大地提高向量类型的数据处理性能。主流的CPU都有SIMD指令，比如x86的SSE、ARM的Neon。
WebAssembly SIMD为WebAssembly新增了一个变量类型v128及其一系列v128的运算符，这些运算符就是SIMD指令。另外，由名字可知v128类型的长度是固定的，为128比特。
SIMD的指令非常多，而且不同CPU的SIMD是不一样的，WebAssembly SIMD只选取了各个CPU都支持的部分最常用的SIMD指令。因此，可以将WebAssembly SIMD理解为各个CPU的SIMD指令的子集，同时将各个CPU的SIMD指令进行了一层抽象和统一，开发者只需要学习WebAssembly SIMD，而不需要了解底层CPU的SIMD。
目前，Emscripten仅支持将WebAssembly SIMD指令编译为x86 SSE/AVX指令以及ARM Neon指令。
在计算机领域，貌似没有什么问题是用分层解决不了的，如果有的话，可以再分一层。
目前，WebAssembly SIMD这个提案已经进入WebAssembly提案流程的Phase 4（Standardize the Feature），尚未完全完成，不过离最后完成也只有1个Phase了，可以理解为基本完成了。V8（Chrome、Node.js）、Firefox以及Emscripten都已经实现了WebAssembly SIMD。
Google Meet借助WebAssembly实现了视频的实时背景虚化以及背景替代，这样可以让参加线上会议的人把注意力集中在人而不是他所在的环境。对视频数据进行实时处理的话，对计算能力的要求非常高，使用WebAssembly SIMD使其性能提升了至少2倍。
2021年，Photoshop终于迁移到了Web，是通过将C++编译为WebAssembly来实现的，其中，WebAssembly SIMD发挥了重要的作用，将性能平均提升了3到4倍，有些场景下甚至达到惊人的80到120倍。
WebAssembly Exception HandlingWebAssembly Exception Handling于Chrome 90开始试用，Chrome 95正式发布，为WebAssemly增加了异常处理语法，具体指令如下表所示：
| Name | Opcode | Description |
|---|---|---|
| try | 0x06 | begins a block which can handle thrown exceptions |
| catch | 0x07 | begins the catch block of the try block |
| catch_all | 0x19 | begins the catch_all block of the try block |
| delegate | 0x18 | begins the delegate block of the try block |
| throw | 0x08 | Creates an exception defined by the tag and then throws it |
| rethrow | 0x09 | Pops the exnref on top of the stack and throws it |
WebAssembly/exception-handling提案由Google的开发者负责，当前处于WebAssembly提案流程的Phase 3，并且得到了Firefox、Safari以及Edge的支持，因此预计将会成为正式标准。
WebAssembly自诞生以来就没有异常处理语法，这是个挺大的问题。在浏览器环境下，WebAssemly的异常是通过JavaScript的try/catch来"模拟"的，这继承了Asm.js的处理方式。
基于JavaScript的WebAssembly异常处理方式如下图所示：
根据初步的测试结果，基于WebAssembly原生的异常处理方式，代码量降低了30%左右，同时性能提升了30%左右，这个结果可以说非常理想了，用更少的代码实现了更好的性能，用更少的代码实现了更好的性能。从原理上来讲，这个结果并不让人意外。不过，由于目前测试数据还非常少，因此WebAssembly Exception Handling的真实效果还有待于进一步验证。
Photoshop移到了Web的过程中，WebAssembly Exception Handling也非常重要，因为C++中的异常处理代码非常场景。因此Photoshop也参与了WebAssembly Exception Handling标准的制定过程。
WebAssembly Reference TypesChrome 96正式发布了WebAssembly Reference Types，Reference Types即引用类型，用externref关键词表示。
之前，WebAssembly仅支持32位及64位的整数和浮点数，这样使得处理复杂数据比如String和Object时非常麻烦。
以字符串为例，如果我们需要从JavaScript传入一个字符串给WebAssembly函数使用，则需要这样处理：
虽然这些步骤由编译工具比如wasm-bindgen来处理，我们不需要操心，但是这样做会生成大量胶水代码，损耗了编译和执行性能。
支持Reference Types之后，WebAssembly也可以愉快地处理整数及浮点数之外的数据类型了。
WebAssembly/reference-types提案已经被纳入WebAssembly标准，Firefox和Safari之前已经支持了。WebAssembly Reference Types使得其他WebAssembly提案成为可能，例如GC（Garbage collection）、Interface Types以及type Imports等。
WebAssembly/reference-types提案的负责人是Andreas Rossberg，他是Google前员工，参与了WebAssembly最初的设计，现在是WebAssembly核心规范的编辑。除了Reference Types，Andreas Rossberg还负责了WebAssembly的很多其他非常重要的提案，比如GC（Garbage collection）、Type Imports、Tail call等。
QUIC协议发布了
2021年，QUIC协议成为IETF的RFC，它是新一代传输层网络协议，是HTTP/3协议的基础：
由上图可知，QUIC协议相当于同时承担了TCP、TLS以及HTTP/2的职责：
TCP是一个伟大的网络协议，但是它有很多问题，其最大的问题是TCP协议已经僵化了，基本没法改了。QUIC最大亮点不在于解决了TCP头部阻塞的问题或者提供1-RTT甚至0-RTT的连接时长，而是一系列保障可部署性、更快地迭代、避免协议僵化的设计，比如基于UDP、加密、脱离操作系统内核等。
QUIC协议的设计思想有点像React 17，在架构设计上简化未来的更新，保障长期发展。
对QUIC协议兴趣的同学，推荐看看QUIC 101视频以及The QUIC Transport Protocol: Design and Internet-Scale Deployment论文，讲得挺好的，我就赘述了。
总之，QUIC是一个大胆、激进、巧妙的网络协议。正如所有其他改变世界的技术（比如WWW）一样，QUIC也是站在巨人的肩膀上，吸取了数十年TCP协议的各种经验和教训。
QUIC协议在今年5月成为IETF的RFC，这是计算机网络发展的革命性里程碑，未来TCP将有可能会逐步退出历史舞台（这个过程会应该比较长，甚至像IPv6一样时间拖很久）。也就是说，面试者们以后就不用了解3次握手和4次挥手了？
QUIC已经成为正式标准了，那HTTP/3成为正式标准也就指日可待了。
WebGPU要来了
2021年，Chrome 94新增了试用特性WebGPU，提供了使用GPU的Web API，可以用于图像渲染（比如3D渲染）以及进行数据并行计算（比如机器学习）。
WebGPU对于Web来说无疑是一个革命性的特性，计算机行业本质上是通过摩尔定律（摩尔为CPU厂商Intlel的创始人之一）以及黄氏定律（黄氏即黄仁勋，GPU厂商英伟达的创始人，别号核弹教父）所推动的，芯片计算能力的提升为我们带来历次计算机行业革命：个人电脑、互联网、移动互联网。当GPU的计算能力越来越强，越来越重要时，Web却不能很好地利用，这显然是不合理的。
WebGPU这个特性所对应的是WebGPU和WebGPU Shading Language这2个提案，由Google、Mozilla以及Apple的工程师负责。WebGPU和WebGPU Shading Language提案都是由W3C的GPU for the Web工作组起草的，该工作组成立于2017，经过4年的努力，WebGPU终于开始试用了，也是不容易啊！WebGPU提案定义了Web中使用GPU的API，WebGPU Shading Language（WGSL）提案定义了GPU代码的编程语言。WebGPU得到了4大浏览器巨头（Safari，Firefox、Edge）的支持，因此WebGPU成为正式的W3C标准只是时间问题。
WebGPU于Chrome 94开始试用，预计将于Chrome 102正式发布，时间大概是明年5月份。如此重要的特性，可能大家还没来得及学会怎么使用，只试用8个月时间就正式发布的话，似乎有点太仓促了。
WebGPU是WebGL的继承者，它们的目标类似，不过WebGPU提供了更加底层的GPU能力。因此，WebGPU的图像渲染能力更强，性能更好，更易用，也更加适用于数据并行计算以及机器学习。
根据Safari的测试结果，WebGPU的性能在各种设备上都远高于WebGL：
图片来源：WebGPU and WSL in Safari
前端机器学习库TensorFlow.js也测试了一下WebGPU，结果发现WebGPU的性能更好，但是差距与WebGL并不是特别明显，有待进一步研究：
图片来源：Fast client-side ML with TensorFlow.js
如下图，WebGPU是基于各种GPU API（例如DirectX 12、Metal、Vulkan）实现的。
图片来源：Access modern GPU features with WebGPU
WebGPU提供的是底层API，非常强大，同时也非常复杂。使用WebGPU实现向量乘法的代码长达200行，目测社区将会出现第三方库封装WebGPU，提供更简单的使用方式用于不同的应用场景。
根据测试，使用WebGPU进行向量乘法计算时，随着向量长度增加，其性能远优于使用CPU：
图片来源：Get started with GPU Compute on the web
Chrome番外篇
2021年，Chrome之外的前端娱乐圈也相当精彩，还是有很其他值得关注的变化，我这里聊一些我比较关注的事情。
Chrome核心开发者之一Alex Russell（今年跳槽去Edge了）写了一篇非常详尽的檄文Progress Delayed Is Progress Denied，指责Safari及其浏览器引擎Webkit严重落后，App Store要求所有浏览器在ios端必须使用Webkit引擎的政策严重制约了Web技术的发展，导致大量Web新技术无法即时应用到iOS端。出于维护App Store的商业利益，Apple不太可能主导放弃对iOS端Web技术的控制，竞争对手只能付诸法律手段。游戏厂商Epic Game正在和Apple打官司，试图绕开App Store，允许第三方支付，这事虽然和Webkit没啥关系，但是也算是在挑战苹果对于iOS端的控制吧。是的，Web技术能否在移动端得到突破性的发展，取决于苹果是否放开对iOS端浏览器引擎的限制，这事得靠打官司，代码写得再好也没有，得靠律师的口才。谷歌大概率不会为了Chrome和苹果打官司，因为安卓面临同样的垄断指控，那不是搬起石头砸自己的脚吗？所以这事目前是无解的。Chrome有时会不管Safari是否支持就发布一些浏览器特性，也是不得已而为之吧，如果等Safari那黄花菜都凉了。
前端领域的明星公司Vercel于11月获得1.5亿美元融资，估值25亿美元，前端框架居然这么值钱了？Vercel的愿景是"make the Web. Faster." 这个愿景还是很赞，想象空间也很大。事实上，它们做的确实也不错，通过使用Rust将构建速度提升了5倍，让人印象深刻，值得关注。另一个值得关注的公司是Figma，融资2亿美元，估值100亿美元。Figma不只是把Sketch搬到了Web，而是改变了设计方法以及设计流程，同时建立了设计师社区。Figma的商业模式还是非常清晰，有对标的巨头Adobe，国内也有对标的公司比如蓝湖、稿定设计、即时设计等，前途无量。随着Web技术的不断进步，大前端的商业价值越来越大，这对于从事这个行业的人无疑是有利的。
Rust在Web生态系统中的应用也值得关注。Rust由Mozilla开发，并且常用于WebAssembly场景，算是血统非常纯正的"前端语言"。明星项目Deno和Next.js都在用Rust，甚至Chrome也在实验用Rust开发。不过，Rust的学习曲线比较陡峭，目前仅应用于前端基础设施的开发，未来大概也会是这样，对这一块感兴趣的同学可以卷起来了！
总结
2021年，我最大的收获之一就是开始写《了不起的Chrome浏览器》博客，学到了很多知识，也加深了自己对整个前端行业的理解。
其实，我在2019年就写过一篇Chrome是如何成功的？，对Chrome的产品理念印象非常深刻：Speed、Security、Stability、Simplicity，我也将4个S作为我自己开发产品的一个原则。
经过这一年的观察，我深刻地体会到Chrome依然在践行最初的理想：drive the web forward，增加浏览器的能力，提高浏览器的速度，拓展浏览器的应用场景，确实非常了不起！因此，我们有理由相信，Chrome会越来越好，Web会越来越好。
当然，这个系列的博客，我还是会继续写下去，继续分享自己对于Chrome的思考，欢迎关注。
才疏学浅，我所写的内容难免有错误之处，欢迎批评指正，感兴趣的同学可以微信交流：KiwenLau。
欢迎关注寒雁Talk公众号，关注《了不起的Chrome浏览器》系列博客！
参考资料
招聘
阿里巴巴业务平台事业部长期招聘P6及以上前端大佬，参与建设最前沿的阿里前端生态系统，推动行业技术发展，内推地址：hanyan.lk@alibaba-inc.com
欢迎大家关注我的微信公众号寒雁Talk。
了不起的Chrome浏览器：Chrome 94开始WebGPU试用，Web的图像渲染及机器学能
9月21日正式发布的Chrome 94，带来了哪些有意思的新特性呢？
背景
十多年来，Web技术突飞猛进，其中Chrome功不可没，了解Chrome可以帮助我们理解前端行业的发展趋势。
因此，我将以《了不起的Chrome浏览器》为题，对Chrome的每一个版本的重要特性进行详细解读，同时分享一些自己的一些思考：
- 了不起的Chrome浏览器（1）：Chrome 89开启Web应用的物联网时代
- 了不起的Chrome浏览器（2）：Chrome 90将默认使用HTTPS，Web更安全了
- 了不起的Chrome浏览器（3）：Chrome 91支持WebAssembly SIMD，加速Web在AI等领域的应用
- 了不起的Chrome浏览器（4）：Chrome 92新增at和randomUUID方法，Canvas支持Display P3色域
- 了不起的Chrome浏览器（5）：Chrome 93支持Error Cause，我国首个ECMAScript提案可以用了
通过专注于Chrome的写作，既可以可以提高我的专业能力，也可以提高个人影响力。我的长期目标是在2025年出版一本关于Chrome的书，毕竟出版自己的书每一个写作者最高的追求。
我是寒雁，一个热爱写代码和写文章的程序员，欢迎关注我的微信公众号寒雁Talk。
TL;TR
- Chrome 94最大的亮点是什么？全村最靓的仔无疑是WebGPU，它为Web应用提供了直接使用GPU的能力，可以用于加速3D渲染以及数据并行计算，为Web应用在游戏以及人工智能领域打开了另外一扇窗。WebGPU得到了各个主流浏览器的支持，因此成为W3C标准只是时间问题。不过，Chrome 94只是开始试用（origin trial），正式发布要等到Chrome 98，时间大概是明年2月份。
- Chrome 94是哪天发布的？2021-09-21
- Chrome 94更新了多少个特性？13个，具体有哪些特性可以查看Chrome Platform Status
- Chrome 94将使用哪个版本的V8引擎？v9.4
- 我感兴趣的正式特性有哪些？
- 我感兴趣的试用（origin trial）特性有哪些？
详细解读
WebGPU
Chrome 94新增了试用特性WebGPU，提供了使用GPU的Web API，可以用于图像渲染（比如3D渲染）以及进行数据并行计算（比如机器学习）。
WebGPU对于Web来说无疑是一个革命性的特性，计算机行业本质上是通过摩尔定律（摩尔为CPU厂商Intlel的创始人之一）以及黄氏定律（黄氏即黄仁勋，GPU厂商英伟达的创始人，别号核弹教父）所推动的，芯片计算能力的提升为我们带来历次计算机行业革命：个人电脑、互联网、移动互联网、人工智能。当GPU的计算能力越来越强，越来越重要时，Web却不能很好得利用，这显然是不合理的。
WebGPU这个特性所对应的是WebGPU和WebGPU Shading Language这2个提案，由Google、Mozilla以及Apple的工程师负责。WebGPU和WebGPU Shading Language提案都是由W3C的GPU for the Web工作组起草的，该工作组成立于2017，经过4年的努力，WebGPU终于开始试用了，也是不容易啊！WebGPU提案定义了Web中使用GPU的API，WebGPU Shading Language（WGSL）提案定义了GPU代码的编程语言。WebGPU得到了4大浏览器巨头（Safari，Firefox、Edge）的支持，因此WebGPU成为正式的W3C标准只是时间问题。
WebGPU于Chrome 94开始试用，预计将于Chrome 98正式发布，时间大概是明年2月份。如此重要的特性，可能大家还没来得及学会怎么使用，只试用3个月时间就正式发布，似乎有点太仓促了。
WebGPU是WebGL的继承者，它们的目标类似，不过WebGPU提供了更加底层的GPU能力。因此，WebGPU的图像渲染能力更强，性能更好，更易用，也更加适用于数据并行计算以及机器学习。
根据Safari的测试结果，WebGPU的性能在各种设备上都远高于WebGL：
图片来源：WebGPU and WSL in Safari
前端机器学习库TensorFlow.js也测试了一下WebGPU，结果发现WebGPU的性能更好，但是差距与WebGL并不是特别明显，有待进一步研究：
图片来源：Fast client-side ML with TensorFlow.js
如下图，WebGPU是基于各种GPU API（例如DirectX 12、Metal、Vulkan）实现的。
图片来源：Access modern GPU features with WebGPU
WebGPU提供的是底层API，非常强大，同时也非常复杂。使用WebGPU实现向量乘法的代码长达200行，目测社区将会出现第三方库封装WebGPU，提供更简单的使用方式用于不同的应用场景。
根据测试，使用WebGPU进行向量乘法计算时，随着向量长度增加，其性能远优于使用CPU：
图片来源：Get started with GPU Compute on the web
WebCodecs
Chrome 94正式发布了WebCodecs，使得我们可以直接使用Chrome所提供的图像、音频以及视频的编码/解码能力。
WebCodecs为W3C提案，由Google、Mozilla以及Microsoft的工程师负责，于Chrome 86开始试用。来自Firefox和Edge的工程师共同起草了WebCodecs提案，因此预计该提案将最终成为W3C标准。
Codec为coder和decoder合成词，即编解码器，它可以是硬件，也可以是软件，用于编码以及解码特定的数据格式，比如MP3/AAC/VP9/H264等。
浏览器器支持各种格式的图片、音频以及视频，但是之前我们并不能直接调用相应的编解码器。WebCodecs就是为了解决这个问题，让Web开发者可以直接使用各种编解码器。
为了优化性能同时保持一致性，Google Docs在今年5月份宣布将迁移至基于Canvas的渲染方案。不过，之前Google Docs在处理GIF时，仍然使用了HTML的<img>标签。后来，Google Docs使用了WebCodecs的图片编解码器ImageDecoder将GIF解码，然后再使用Canvas渲染，这样做优化了性能，同时简化了代码架构。
Zoom在其Web Meeting SDK和Web Video SDK中使用了WebCodecs，由于源代码并未开源，因此具体怎么使用的不得而知，应该是用到了视频相关的编解码器。值得一提的是，由于Chrome 93的对WebCodes的更新有Breaking changes，导致Zoom的Web Meeting SDK和Web Video SDK出现了BUG，看来在第三方SDK中直接使用并未正式发布的特性，还是有挺大风险的。
Scheduling APIs: Prioritized scheduler.postTask
Chrome 94正式发布了Scheduling APIs: Prioritized scheduler.postTask特性：
- 新增了scheduler.postTask方法，支持根据优先级调度任务，并支持指定延时调度任务;
- 定义了3个任务优先级，从高到低依次为：user-blocking、user-visible、background;
- 新增了TaskController，支持动态修改任务优先级以及取消任务;
Prioritized Task Scheduling为WICG提案，由Google工程师负责，于Chrome 86开始试用。由于该提案暂未得到其他浏览器厂商的参与和支持，因此该特性最大的风险在于能否成为通用标准。
当我们用Lighthouse检测页面时，其中一个检测项为"Minimize main-thread work"，它将主线程的工作分为了下图所示的7个分类，可知主线程所承担的任务异常繁重：
由于主线程需要负责执行的任务过多，如果主线程被低优先级任务或者耗时任务（Long Task，即执行时间超过50ms的任务）过度占用，则会导致浏览器对用户操作的响应过慢，比如点击按钮长时间没有反应，这样会极大地损害用户体验。
用一个最极端的例子来举例，如果JavaScript代码陷入死循环，则页面将基本上完全卡顿，无法响应用户操作。感兴趣的话，可以在控制台执行以下代码：
while (true) {
console.log("hello, Chrome!");
}
如果非关键JavaScript任务（比如日志）过多占用主线程或者关键的JavaScript任务（比如响应用户操作）等待太久，都会伤害用户体验。为了优化主线程的调度，requestIdleCallback和isInputPending等特性相继诞生，requestIdleCallback可以利用主线程渲染页面的空闲时间执行低优先级任务，isInputPending可以用于避免耗时任务阻塞响应用户操作。与requestIdleCallback和isInputPending相比，Prioritized Task Scheduling提案的调度功能更加完备和强大，支持根据优先级调度任务，支持指定延时调度任务，支持动态修改任务优先级以及取消任务。
通过使用scheduler.postTask，Aribnb的工程师将耗时任务拆分为小任务、推迟非关键任务、预下载图片。从优化效果来看，搜索结果页的Total Blocking Time（TBT）从16s降低到了6s，大幅优化了用户体验。不过，Total Blocking Time的最佳值是300ms以内，因此Airbnb所做的优化看起来还不算太理想。当然，这个值应该与具体应用相关。
Aribnb的工程师使用Scheduling APIs实现了图片预下载：
- 当用户滑动到第2个搜索结果时，提前下载了第2张图片；
- 当用户滑动到第2个搜索结果的第2张图片时，依次提前下载了第3、4、5张照片；
- 我们可以在Network控制台中看到4个图片下载请求，根据瀑布图（Waterfall），4个请求是按照时间顺序依次请求的；
图片来源：Building a Faster Web Experience with the postTask
Scheduler
随着Web应用越来越复杂，主线程所承担的任务越来越多，如何减轻主线程负担将成为浏览器以及Web开发者所面临的重大课题，按照优先级调度任务将可能成为Web应用以及Web框架的最佳实践之一。另外，类似的减轻主线程负担的提案将不断涌现，这也会进一步强化Web应用的能力。
Idle Detection API
Chrome 94正式发布了Idle Detection API，用于检查用户是否活跃，其判断依据是用户是否使用键盘、鼠标、触摸屏等。
Idle Detection API为WICG提案，由Google工程师负责，于Chrome 84开始试用，Chrome 94正式发布。目前看来这个特性也只有Chrome支持，Firefox和Safari出于保护用户隐私，都明确表示反对该特性。
Apple对于用户的隐私及安全的坚持已经成为其企业文化的一部分，影响了它很多产品和技术上的决策，这是它不依赖广告赚钱的商业模式所决定的。根据statcounter的最新数据，Chrome和Safari的市场份额分别为64%和18%，因此Safari是Chrome最大的竞争对手。有Safari这样强大的对手制约Chrome，有利于保证Web的健康发展。
个人也反对这个特性Idle Detection API（虽然我的反对没啥用啊哈哈），它涉嫌侵犯了用户隐私，可以用于追踪用户的日常行为习惯，可能会用于比较变态的场景。
为了保护用户的隐私和安全，调用Idle Detection API需要得到用户的授权：
// 获取Idle Detection API授权
const state = await IdleDetector.requestPermission();
if (state !== "granted") {
// Need to request permission first.
return console.log("Idle detection permission not granted.");
}Idle Detection API可以用在以下场景：对于即时聊天、社交媒体、在线游戏，检查用户是否活跃，可以帮助用户判断他们的联系人是否在线。事实上，聊天应用Slack和Google Chat都表达了对该特性的兴趣。
当年PC版的QQ可以根据用户的鼠标键盘操作自动将状态切换至"离开"，然而移动互联网时代的聊天应用默认用户24小时在线。移动互联网给用户带来便利的同时，也绑架了大家的时间和精力，你能做到24小时不用手机吗？
Google工程师提供了一个非常直观的Demo应用Ephemeral Canvas，我们可以用它画图，当我们60秒内不操作电脑时，所画的图形会自动被擦除掉。
JS Self-Profiling API
Chrome 94正式发布了JS Self-Profiling API，用于获取JavaScript执行时的性能数据。
JS Self-Profiling API为WICG提案，由Facebook的工程师负责，于Chrome 78开始试用，Chrome 94正式发布。
并不意外的是，Safari反对该特性，原因在于性能和安全问题。性能问题比较好理解，收集JavaScript执行过程中的性能数据会损耗性能。至于安全问题，Safari工程师担心的是黑客获取JavaScript的编译时长从而造成可能遭受时序攻击（Timing attack）。
看来，对于如何发展Web技术，Chrome与Safari有着非常不一样的观点，前者要激进很多，后者则相对保守。从我写的《了不起的Chrome浏览器》系列博客也可以看出来，Google工程师开发了非常多浏览器新特性，作为一个跟踪Chrome特性的写作者我都有点学不过来了，而对于大部分沉迷于写代码的开发者来说，很多特性可能都没听说过（此处不妨广告一下，如果你对Chrome的最新特性感兴趣，不妨关注我的微信公众号寒雁Talk）。这是Google和Apple不同的商业模式所决定的，Apple打造了封闭而完备iOS/macOS/iPadOS/watchOS生态系统，对Web技术的热情没有自家亲儿子那么高；而Web技术对于Google，是其安身立命的根本，网页都没了，搜索引擎还搜个球啊？所以，Chrome对于Google来说，远远不只是一个流量入口那么简单和无聊，Chrome致力于推动Web技术向前发展不是一句空话，Chrome当年的产品负责人成为Google的CEO也并非巧合，关于这一点，详见我2年前写的博客《Chrome是如何成功的？》。
虽然Safari对于JS Self-Profiling API不感兴趣，不过，来自Facebook和Microsoft的工程师都表示通过JS Self-Profiling API定位到了一些非常严重的性能问题，说明这个API应该还是有两把刷子的。因为JS Self-Profiling API并不影响产品功能，所以Safari不支持也没什么太大问题。反正苹果自研的芯片足够快，大概不会有性能问题？
Canvas color management
Chrome 94支持在创建2D canvas时，使用Display P3色域，这将增强2D canvas的颜色还原能力。
canvas.getContext(\'2d\', { colorSpace: "display-p3"} );Canvas color management于Chrome 90开始试用，Chrome 94正式发布。这个特性我在《了不起的Chrome浏览器（4）：Chrome 92新增at和randomUUID方法，Canvas支持Display P3色域》博客中介绍了，不过尴尬的是我搞错了，它并不是Chrome 92正式发布的特性。该特性得到了Firefox和Safari的支持，因此将成为通用标准。
之前，2D canvas仅支持陈旧的sRGB色域，但是现在的屏幕和相机早就支持更大的色域了。
色域是什么呢？它的英文名是Color Gamut或者Color Space，是设备（显示器、投影仪、打印机）可以表达的颜色范围。人眼可见的颜色范围是有限的，而设备能表达的颜色范围是人眼可见的颜色范围的子集，而不同色域标准比如sRGB和Display P3能表达的颜色范围也不一样。
Display P3的色域比sRGB的色域大25%，当我们对比两者时，会发现Display P3要比sRGB明亮很多，区别非常明显：
图片来源：Get Started with Display P3
对于图像、视频、设计、游戏、地图、美食等应用，颜色准确性的重要性不言而喻。
一些貌似与颜色无关的应用，如果我们的应用不能准确还原物体的颜色，也是会影响业务的。大多数情况下，买家秀和卖家秀的明显差异是由于卖家过度PS导致的，但是也有可能是颜色没有得到准确还原导致的。
103 Early Hints for Navigation
Chrome 94新增了试用特性103 Early Hints for Navigation。
103 Early Hints for Navigation所对应的IETF提案为RFC 8297: 103 Early Hints，它本质上是对HTTP协议的更新，该提案由云服务商Fastly的工程师Kazuho Oku所提出。103 Early Hints for Navigation于Chrome 94开始试用，正式发布的Chrome版本还不确定。
值得一提的是，Fastly的CDN服务在今年6月份的时候出了一次故障，导致Amazon、Hulu、Reddit、Shopify等知名服务宕机，可见其影响力之大。Fastly提出103 Early Hints也不是完全用爱发电，这个特性也帮助其CDN服务。其CDN节点收到源站点的103状态码之后，可以根据其Header中是否包含Cache-Control: private，来提前决定是否复用CDN节点缓存的资源，提高响应速度。由这个简单例子也可以看出，有时候一些技术问题是没法在现有的技术标准体系内得到很好的解决，需要改变标准本身。由此推断，中国的程序员应该更多地参与国际技术标准的制定，这是有现实意义的。当然，这么做短期来看投入产出比可能没有那么高，但是长远来看，也是必由之路吧。
下图非常直观地展示了103 Early Hints for Navigation的作用，它可以在前一个HTTP请求Header以及response都还没有返回的时候preload后续资源，从而将后续的HTTP请求大幅提前，从而减少整体的请求时间，提高网络的利用率。
- 第1种情况：body返回之后，解析HTML，再去发起请求获取css以及js资源：
图片来源：Towards ever faster websites with early hints and
priority hints
- 第2种情况：header返回之后，body返回之前，根据Header中的preload信息，发起请求获取css以及js资源：
图片来源：Towards ever faster websites with early hints and
priority hints
- 第3种情况：103状态码返回之后，根据Header中的preload信息，发起请求获取css以及js资源：
图片来源：Towards ever faster websites with early hints and
priority hints
显然，第3种情况下，整体的响应时间要快很多，对网络的利用率也提高了。我们不妨看一下第3种情况下，具体的请求过程。
浏览器发起访问example.com的请求：
GET / HTTP/1.1
Host: example.com
服务端返回103，Header中包含preload信息，这时浏览器就可以发起style.css以及script.js请求了：
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
服务端返回200，Header中包含preload信息，并且html文本中也包含所需要的css以及js文件（这不是废话吗？）。
HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
<!doctype html>
[... rest of the response body is omitted from the example ...]总结
从Chrome 94开始，Chrome将加快其更新频率，由每6周更新一个版本改为每4周更新一个版本。对于一个全球拥有26亿用户的产品，加快发布频率可以为用户提供更好体验，同时也会为研发团队带来巨大的挑战。Chrome能够一直保持稳定的迭代频率，同时提供保持透明，提供丰富的文档，这为Chrome生态系统内的开发者提供了便利，这一点非常值得我们学习。
本篇是《了不起的Chrome浏览器》的第6篇，创造了个人写专题系列博客的记录，之前的《JavaScript深入浅出》系列只写了5篇。Chrome加快更新频率之后，我也必须调整自己的写作计划，与Chrome的版本迭代保持同步。
细心的同学可能会发现，我这篇博客有一些细微的不同点，以后我也会坚持这样做：
- 开始介绍每一个Chrome特性所对应的标准提案，最顶级的技术公司掌握技术标准，了解这些提案也非常有必要。这些提案来自不同的标准化组织，比如W3C、WICG、IETF，目前来看，Chrome掌握了各种Web技术标准的主导权，这事有利有弊；
- 开始介绍Safari、Firefox、Edge以及其他大公司对于各个提案的态度以及背后的商业原因，技术可以推动商业进步，商业可以影响技术发展，两者是无法分开的，如果只了解技术，而不理解背后的商业逻辑，也是不够的；
- 开始对Chrome的某些做法表达负面看法，正如我这个系列博客的标题，整体上我对Chrome是持正面态度，因为它确实彻底改变了前端生态系统，改变了我所在的行业，影响了我个人的职业发展，但是，这并不意味着我对Chrome所做的所有事情都是支持的，我会要求自己更加客观一点；
- 开始介绍试用（origin trial）特性，Chrome的每个版本都会发布一些试用特性，而这些试用特性往往比正式特性更重要，不容错过，这样也可以让大家第一时间了解Web技术的最新发展趋势；
本文介绍7个特性，其中6个特性都涉及到新的Web技术标准，可见Chrome是真的致力于Make Web Gread Again（MWGA），Google程序员为了OKR也是挺拼的。相比之下，Firefox和Safari看起来要佛系很多，这与各个公司的商业模式以及投入程度有关。不过，Chrome在掌握Web技术的主导权之后，有点为所欲为了，有些特性不顾同行的反对，推进速度也有点太快了，这就不太妙了。Web与其他平台不一样的地方在于，它是开放的，是属于所有人的，也有向后兼容的问题，因此Web技术标准不能一家说了算，也不能太随意，否则对Web技术的长远发展并不利。可惜的是，现在Web技术标准和国内的程序员没有什么太大关系，我们无从置喙，只能当吃瓜群众。。。等哪天国产浏览器拥有更大的话语权再说吧。
还有一点，对于每一个特性，我都花了大量时间阅读各种资料来理解其原理，然后根据个人理解来写的，很多特性我也没有时间去写代码测试，因此我的说法难免有错误的地方，欢迎各位大佬批评指正。感兴趣的同学可以添加我的个人微信交流：KiwenLau。
欢迎关注寒雁Talk公众号，关注《了不起的Chrome浏览器》系列博客，与我一起见证大前端的星辰大海！
参考资料
- 了不起的Chrome浏览器（1）：Chrome 89开启Web应用的物联网时代
- 了不起的Chrome浏览器（2）：Chrome 90将默认使用HTTPS，Web更安全了
- 了不起的Chrome浏览器（3）：Chrome 91支持WebAssembly SIMD，加Web在AI等领域的应用
- 了不起的Chrome浏览器（4）：Chrome 92新增at和randomUUID方法，Canvas支持Display P3色域
- 了不起的Chrome浏览器（5）：Chrome 93支持Error Cause，我国首个ECMAScript提案可以用了
- Chrome 94 Beta: WebCodecs, WebGPU, Scheduling, and More
- [New in Chrome 94: Color management for canvas, WebCodecs, WebGPU, and more!]()
- V8 release v9.4
- Intent to Ship: Scheduling APIs: Prioritized scheduler.postTask
- Building a Faster Web Experience with the postTask Scheduler
- Zoom on Web: getting connected with advanced web technology
- Intent to Ship: WebCodecs
- Chrome 93 Breaking Changes for Web Meeting/Video SDK
- Benefits of using ImageDecoder when rendering using WebCanvas in Docs
- Intent to Ship: VirtualKeyboard API
- Full control with the VirtualKeyboard API
- HTTP/2 Push is Being Removed, let us discuss
- Intent to Remove: HTTP/2 and gQUIC server push
- Detect inactive users with the Idle Detection API
- Get Started with Display P3
- Improving Color on the Web
- Pixar in a Box: Color science
- Access modern GPU features with WebGPU
- Fast client-side ML with TensorFlow.js
- Get started with GPU Compute on the web
- RFC 8297: 103 Early Hints
- Towards ever faster websites with early hints and priority hints
关于Fundebug
Fundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了40亿+错误事件，付费客户有阳光保险、达令家、核桃编程、荔枝FM、微脉等众多品牌企业。
以上是关于了不起的Chrome浏览器（10）：2021年，Chrome哪些变化最值得关注？的主要内容，如果未能解决你的问题，请参考以下文章
内部函数在 Firefox 中不起作用，但在 chrome 中可以
jQuery .hover 在 Safari 或 Chrome 中不起作用
2021 年适用于包括 safari 在内的所有浏览器的 pwa javascript 视频录制应用程序